Prev: To Proxy-ARP or not to Proxy-ARP
Next: Using Sygate Security Agent to disable Wireless while on LAN
From: geemail99 on 23 Jan 2008 00:05
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
From: Arjun on 23 Jan 2008 07:04
may be route in between the networks is doing that...
From: Wayne McGlinn on 23 Jan 2008 22:36
<geemail99(a)gmail.com> wrote in message
news:0180f75d-3763-4ef4-8dfe-5a5865c1d474(a)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/quicklinks/utilities/downloadsng/utilities/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/documents/WhitePaper_fwMonitoring_Tech.pdf.

Wayne McGlinn
Brisbane, Oz

From: geemail99 on 25 Jan 2008 01:45
On Jan 24, 2:36 pm, "Wayne McGlinn" <wa...(a)brisbane.oz> wrote:
> <geemai...(a)gmail.com> wrote in message
>
> news:0180f75d-3763-4ef4-8dfe-5a5865c1d474(a)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 ;)
 | 
Pages: 1
Prev: To Proxy-ARP or not to Proxy-ARP
Next: Using Sygate Security Agent to disable Wireless while on LAN