PIX decreasing TTL values

[haver]

This sure does sound abnormal. Pinging PIX's external interface,

$ ping 195.x.x.x

PING 195.x.x.x (195.x.x.x): 56 data bytes

64 bytes from 195.x.x.x: icmp_seq=0 ttl=246 time=7.393 ms

However, if I ping a box in the DMZ, things look a bit wierd,

$ ping 195.x.x.x

PING 195.x.x.x (195.x.x.x): 56 data bytes

64 bytes from 195.x.x.x: icmp_seq=0 ttl=55 time=11.852 ms

I'm running 6.3(1). I don't remember seeing this behaviour on earlier releases. Did something change in the latest version.

Any pointers are welcome.

[msitzman · Accepted solution]

I don't see why the PIX would decrement the values like you have seem when the ICMP packet traverses the PIX into the DMZ segment. My first guess would be that perhaps the ICMP echo-reply packet that you see from 195.x.x.x in the DMZ network is not taking the same path as the packet that hits the PIX interface itself.

I would verify routing information on the network and the DMZ host itself. If that does not give you the answer, I would use the 'debug icmp trace' command on the PIX to verify that in fact both the echo and echo-reply are traversing the PIX. You can also verify the ICMP packet information with this debug.

Hope this helps...

Marcus

[haver]

There is no asymetric routing problem. Packets can only traverse the PIX.

debug icmp trace shows,

411: Inbound ICMP echo request (len 56 id 15034 seq 0) 195.24.x.x > 195.69.2xx.xx > 195.69.2xx.xx

412: Outbound ICMP echo reply (len 56 id 15034 seq 0) 195.69.2xx.xx > 195.69.2xx.xx > 195.24.x.x

However, it turns out, that the DMZ host sets TTL to 64, which explains why I see TTL=55 at the other end. Not only that, there are also 9 hops to the DMZ host (64 - 9 = 55).

I should've checked the default TTL values before posting here. Anyways, thanks for your help.