Checkpoint Firewall-1 altering packet data: - Firewalls

This is a discussion on Checkpoint Firewall-1 altering packet data: - Firewalls ; Good day all, My company has a internal firewall that divides two network segments. Users on one segment (internal LAN), and a 3rd party call center service provider (isolated DMZ). [-------------------------------] User Network | | #CP FW1# | | [--------|-------------------------------] ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Checkpoint Firewall-1 altering packet data:

  1. Checkpoint Firewall-1 altering packet data:

    Good day all,

    My company has a internal firewall that divides two network segments.
    Users on one segment (internal LAN), and a 3rd party call center
    service provider (isolated DMZ).

    [-------------------------------] User Network
    |
    |
    #CP FW1#
    |
    |
    [--------|-------------------------------]
    Call Center DMZ

    + User network switch = Cisco 3750
    + Firewall = Checkpoint R65 (enforcement module) on Nokia IPSO 380
    (version 4.2)
    + Packets are routed and _not_ NAT'd.

    Users experience hanging whilst attempting to logout of one particular
    application (other applications function as expected). The application
    is known as Altitude and uses UDP port 1500.

    So far i have removed any Smart Defense profiles from the Checkpoint
    firewall, removed the Nokia IPSO and Checkpoint clustering (only one
    node is active) and ensured that the generic service port for UDP 1500
    does not have any "protocol type" assigned to it (UDP service
    properties -> "Advanced" -> "Protocol Type:" = Blank / Unassigned).

    I proceeded to configure two sniffers - the first sniffer captured
    data generated by the user, and the second sniffer captured all data
    that had traversed the firewall onto the call center dmz.

    I filtered out the UDP 1500 data and compared it to the packets that
    had traversed the firewall - and was shocked to find that the payload
    (data) of the packet had been altered _after_ the firewall.

    I am very certain that i am viewing the _same_ packet, as the source
    port / IP address, destination port / IP address and the UDP checksum
    all match. The layer 3 / IP checksum obviously differ, as they have
    been regenerated by a different network card on a different network
    segment using the same source / destination IP.

    Has anyone experienced this before? Or do i perhaps have a misguided
    understanding that the data portion of a packet should _not_ be
    altered after being retransmitted on the other side of the firewall?

    Any advice greatly appreciated
    thanks dirk

  2. Re: Checkpoint Firewall-1 altering packet data:

    may be route in between the networks is doing that...

  3. Re: Checkpoint Firewall-1 altering packet data:

    wrote in message
    news:0180f75d-3763-4ef4-8dfe-5a5865c1d474@v4g2000hsf.googlegroups.com...
    > Good day all,
    >
    > My company has a internal firewall that divides two network segments.
    > Users on one segment (internal LAN), and a 3rd party call center
    > service provider (isolated DMZ).
    >
    > [-------------------------------] User Network
    > |
    > |
    > #CP FW1#
    > |
    > |
    > [--------|-------------------------------]
    > Call Center DMZ
    >
    > + User network switch = Cisco 3750
    > + Firewall = Checkpoint R65 (enforcement module) on Nokia IPSO 380
    > (version 4.2)
    > + Packets are routed and _not_ NAT'd.
    >
    > Users experience hanging whilst attempting to logout of one particular
    > application (other applications function as expected). The application
    > is known as Altitude and uses UDP port 1500.
    >
    > So far i have removed any Smart Defense profiles from the Checkpoint
    > firewall, removed the Nokia IPSO and Checkpoint clustering (only one
    > node is active) and ensured that the generic service port for UDP 1500
    > does not have any "protocol type" assigned to it (UDP service
    > properties -> "Advanced" -> "Protocol Type:" = Blank / Unassigned).
    >
    > I proceeded to configure two sniffers - the first sniffer captured
    > data generated by the user, and the second sniffer captured all data
    > that had traversed the firewall onto the call center dmz.
    >
    > I filtered out the UDP 1500 data and compared it to the packets that
    > had traversed the firewall - and was shocked to find that the payload
    > (data) of the packet had been altered _after_ the firewall.
    >
    > I am very certain that i am viewing the _same_ packet, as the source
    > port / IP address, destination port / IP address and the UDP checksum
    > all match. The layer 3 / IP checksum obviously differ, as they have
    > been regenerated by a different network card on a different network
    > segment using the same source / destination IP.
    >
    > Has anyone experienced this before? Or do i perhaps have a misguided
    > understanding that the data portion of a packet should _not_ be
    > altered after being retransmitted on the other side of the firewall?
    >
    > Any advice greatly appreciated
    > thanks dirk


    On the Nokia box run the following command:
    fw monitor -o problem.cap
    ftp the problem.cap file to a workstation.
    Install wireshark or ethereal (or download cpethereal from Check point
    http://www.checkpoint.com/downloads/...s/support.html )
    With normal ethereal (wireshark) you need to go to edit - preferences -
    protocols - ethernet and check the box to "interpret as firewall-1 monitor
    file"
    Open the capture file, you'll now see 4 packets for each 1 hitting the
    firewall, fw monitor captures packets at "i" pre-inbound, "I" post-inbound,
    "o" pre-outbound and "O" post-outbound.
    By following the sequence and opening each instance you will prove whether
    or not Check Point is changing any data.
    Refer to "how to use fw monitor" .pdf file on the same URL as above, or from
    Nokia's website
    http://www.nokiaforbusiness.com/docu...oring_Tech.pdf.

    Wayne McGlinn
    Brisbane, Oz


  4. Re: Checkpoint Firewall-1 altering packet data:

    On Jan 24, 2:36 pm, "Wayne McGlinn" wrote:
    > wrote in message
    >
    > news:0180f75d-3763-4ef4-8dfe-5a5865c1d474@v4g2000hsf.googlegroups.com...
    >
    >
    >
    > > Good day all,

    >
    > > My company has a internal firewall that divides two network segments.
    > > Users on one segment (internal LAN), and a 3rd party call center
    > > service provider (isolated DMZ).

    >
    > > [-------------------------------] User Network
    > > |
    > > |
    > > #CP FW1#
    > > |
    > > |
    > > [--------|-------------------------------]
    > > Call Center DMZ

    >
    > > + User network switch = Cisco 3750
    > > + Firewall = Checkpoint R65 (enforcement module) on Nokia IPSO 380
    > > (version 4.2)
    > > + Packets are routed and _not_ NAT'd.

    >
    > > Users experience hanging whilst attempting to logout of one particular
    > > application (other applications function as expected). The application
    > > is known as Altitude and uses UDP port 1500.

    >
    > > So far i have removed any Smart Defense profiles from the Checkpoint
    > > firewall, removed the Nokia IPSO and Checkpoint clustering (only one
    > > node is active) and ensured that the generic service port for UDP 1500
    > > does not have any "protocol type" assigned to it (UDP service
    > > properties -> "Advanced" -> "Protocol Type:" = Blank / Unassigned).

    >
    > > I proceeded to configure two sniffers - the first sniffer captured
    > > data generated by the user, and the second sniffer captured all data
    > > that had traversed the firewall onto the call center dmz.

    >
    > > I filtered out the UDP 1500 data and compared it to the packets that
    > > had traversed the firewall - and was shocked to find that the payload
    > > (data) of the packet had been altered _after_ the firewall.

    >
    > > I am very certain that i am viewing the _same_ packet, as the source
    > > port / IP address, destination port / IP address and the UDP checksum
    > > all match. The layer 3 / IP checksum obviously differ, as they have
    > > been regenerated by a different network card on a different network
    > > segment using the same source / destination IP.

    >
    > > Has anyone experienced this before? Or do i perhaps have a misguided
    > > understanding that the data portion of a packet should _not_ be
    > > altered after being retransmitted on the other side of the firewall?

    >
    > > Any advice greatly appreciated
    > > thanks dirk

    >
    > On the Nokia box run the following command:
    > fw monitor -o problem.cap
    > ftp the problem.cap file to a workstation.
    > Install wireshark or ethereal (or download cpethereal from Check pointhttp://www.checkpoint.com/downloads/quicklinks/utilities/downloadsng/...)
    > With normal ethereal (wireshark) you need to go to edit - preferences -
    > protocols - ethernet and check the box to "interpret as firewall-1 monitor
    > file"
    > Open the capture file, you'll now see 4 packets for each 1 hitting the
    > firewall, fw monitor captures packets at "i" pre-inbound, "I" post-inbound,
    > "o" pre-outbound and "O" post-outbound.
    > By following the sequence and opening each instance you will prove whether
    > or not Check Point is changing any data.
    > Refer to "how to use fw monitor" .pdf file on the same URL as above, or from
    > Nokia's websitehttp://www.nokiaforbusiness.com/documents/WhitePaper_fwMonitoring_Tec....
    >
    > Wayne McGlinn
    > Brisbane, Oz


    Thank you Wayne -
    much appreciated i will redo the capture using fw monitor, but this
    may take sometime.

    Have a good Australia day / long weekend

+ Reply to Thread