Pings using a static route versus default gateway

[gp1200x]

Here is a scenario I never encountered before and may need a packet trace to fully understand unless someone knows the issue.

Setup...a subnet with a PC in it on the core router (6509). The core router is attached to a checkpoint firewall that has a dmz.

Instead of configuring a default gateway on the PC he only configured the DMZ subnet using a static route of 192.168.1.0 /24 via the core router interface. He set no default gateway on the PC.

The PC can ping a server in the dmz  however the server in the dmz cannot ping the PC. If the PC is coded with a "route add" command for 0.0 0.0. 0.0.0.0 using the core interface or set to use a default gateway with the core interface then the server in the dmz can ping the PC. The PC can always ping the dmz server regardless of how it is set...using only a static route for the dmz, or setup with a default gateway, or configured with a 0.0.0.0 0.0.0.0 route.

If seems the PC cannot return an echo reply when it only has the static route of the 192.168.1.0 /24 via the core but no default gateway.

Any idea what the process failure is here?

[Richard Bradfield]

Hi,

just don't quite understand this bit

instead of configuring a default gateway on the PC he only configured the DMZ subnet using a static route of 192.168.1.0 /24 via the core router interface. He set no default gateway on the PC.

Was this a route add on the PC or an IP route statement on the 6509?

is the network PC>>6509> firewall inside > firewall dmz?

[gp1200x]

It was a route add on the PC itself. If the PC uses the 6509 as the gateway.....as everyone else does, this problem does not show up. He does not want to use a default gateway and wants to personally control what his PC can get do (yeh, I know!!,,no one else does this kind of thing but he wants too!)

His PC has the firewall turned off and I see the same issue a test setup I tried with two other machines since I was sure it was his device. 

RECAP

The PC connects to the core 6509 (subnet A) and the core connects to the firewall (on subnet B) and the firewall has a DMZ which allows pings into the secure network.  His PC network is 10.42.193.0 /24 and the 6509-firewall network is 10.42.196.0 /24.  The DMZ is 192.168.1.0

If the PC uses the default gateway of 10.42.193.1 (6509) pings work in both directions to the device in the DMZ.  If he codes the PC only with a static route of 192.168.1.0 /24 via 10.42.193.1 then only the PC can ping the device in the DMZ. If the DMZ retries to ping the device it fails. Even if we code a static route of 10.42.196.0 /24 via 10.42.193.1 it still fails. If we code a static route of 0.0.0.0 0.0.0.0 via 10.42.193.1 or use a default gateway of 10.42.193.1 on the PC then pings work in both directions. What am I missing here? Is there something obvious I am totally overlooking?

Thanks for even looking at this issue!

[Jon Marshall · Accepted solution]

It almost sounds like when the DMZ server initiates the connection it's IP is translated to something else and so the PC only works when you have a default route or default gateway configured.

However this wouldn't explain why with just the 192.168.1.0/24 route configured the ping works from the PC because if there was a NAT rule on the firewall I would expect it to apply even if the server was sending return traffic and not just initiating the connection.

That said I can't think of anything else because nothing else stands out ie. if it was a firewall issue on the PC then ping would not work from the server no matter what route and if it was a problem with the route on the PC I would expect it not to work both ways ie. using the route when the PC initiates the ping but not using it when the PC replies to a ping makes no sense. 

Jon

[Richard Bradfield]

This one does make you think.

we know the routing is ok. So I think Jon might have a point some funny NAT taking place in the Firewall.

[gp1200x]

I have to admit that I this one is baffling to me and I didn't want to take traces but I am going to make the firewall guy do internal packet captures and see what is going on. I don't control this firewall otherwise I would have done it already . If that doesn't resolve it I will take sniffer traces (haven't needed to do one in a long time). I have to believe the issue is some oddball  rule that they configured in the checkpoint. I didn't believe the issue when it was first mentioned to me until I actually saw it happen on my own laptop.  

The firewall guy insists it is not the firewall and he is not doing any natting from the dmz to the inside but something odd has to be happening .....like icmp echo packets initiated from dmz addresses get natted to some other IP that is out of the range of the statically configured subnets.

I will update once I get an answer. 

[milan.kulik]

Hi,

I guess running Wireshark on your PC should easily show any NAT involved/forgotten?

Best regards,

Milan

[gp1200x]

Did traces and this is what we found. Apparently our Checkpoint does a thing called BI-NAT and anytime the dmz responds to an inside address uses the alias outside address as its source, still subjected to the rules set on the dmz interface. Same holds true if the dmz device initiates a connection to an inside address - it uses the address seen on the outside of the firewall. Firewall guy didn't know it was doing that did that and no one ever before paid any attention to the receiving address when the dmz devices were accessed directly. So it is working as designed by Checkpoint...not the way I would have assumed it worked..

Thanks for all the help and feedback!

[Peter Paluch]

Dear friends,

Please allow me to join.

I may be wrong but I consider this to be an issue of the firewall on the PC itself. I assume that it is a Windows-based machine with the firewall turned on. My experience with Windows firewalls is that they like to be very opportunistic, presumptuous about packets to answer/not to answer, and often difficult to troubleshoot. Would it be possible to entirely deactivate the firewall on the PC for a moment and then try the pinging stuff?

Best regards,
Peter