|
Posted by on January 25, 2008, 1:45 am
If you were Registered and logged in, you could reply and use other advanced thread options >
>
>
>
> > 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 ;)
| 
XML site map