[c-nsp] PIX and FWSM not decreasing TTL (was RE: Weird traceroutes through Firewall Services Module (FWSM))

[Sam Stickland]

Yup, tried that. It's not that we can't ping, or get responses from the PIX
interfaces. Here's another example:

  1    <1 ms    <1 ms    <1 ms  172.20.111.250
  2    <1 ms    <1 ms    <1 ms  192.168.20.101
  3    <1 ms    <1 ms    <1 ms  10.20.1.4
  4     2 ms     4 ms     4 ms  a.b.c.d
  5     4 ms     2 ms     4 ms  e.f.g.h

There's a PIX between hops 3 and 4. 10.20.1.4 has a static default route
pointing to the PIXes inside interface 10.134.64.12 (not visible in the
traceroute)
 
If we ping the inside interface we get a TTL of 252:
 
Reply from 10.134.64.12: bytes=32 time<1ms TTL=252
Reply from 10.134.64.12: bytes=32 time<1ms TTL=252
 
If we ping the router just beyond we get the same:

Reply from a.b.c.d: bytes=32 time=3ms TTL=252
Reply from a.b.c.d: bytes=32 time=2ms TTL=252

There isn't any asymmetric routing happening here. We can see this affect
another way by crafting a packet with a TTL just big enough to reach the PIX
interface 10.134.64.12.

C:\>ping -i 3 10.134.64.12
Pinging 10.134.64.12 with 32 bytes of data:
Reply from 10.20.1.4: TTL expired in transit.

C:\>ping -i 4 10.134.64.12
Pinging 10.134.64.12 with 32 bytes of data:
Reply from 10.134.64.12: bytes=32 time<1ms TTL=252

And then we can use this TTL value of 4 to reach the nexthop, a.b.c.d and
not a bit less!

C:\>ping -i 4 a.b.c.d
Pinging a.b.c.d with 32 bytes of data:
Reply from a.b.c.d: bytes=32 time=2ms TTL=252

C:\>ping -i 3 a.b.c.d
Pinging a.b.c.d with 32 bytes of data:
Reply from 10.20.1.4: TTL expired in transit.

As you can see, the PIX doesn't decrease the TTL for traffic that passes
through it. We wish to stop this behaviour.

Sam

> -----Original Message-----
> From: <Name Removed As Received Off List>
> Sent: 18 May 2006 15:49
> To: Sam Stickland
> Subject: Re: [c-nsp] PIX and FWSM not decreasing TTL (was RE: Weird
> traceroutes through Firewall Services Module (FWSM))
> 
> Have you tried allowing ICMP unreachabled from the pix itself?
> 
> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdr
> ef/gl.htm#wp1026574
> 
> -Brandon
> 
> On 5/18/06, Sam Stickland <sam_mailinglists at spacething.org> wrote:
> > Hi,
> >
> > Some more research basically brings this all down to what I suspect more
> of
> > you already know:
> >
> > A PIX or FWSM does not decrease the TTL of traffic passing through it,
> even
> > though it is a Layer3 device. Therefore, they NEVER show up in
> traceroutes.
> >
> > You can verify this by pinging the outside interface of the PIX or FWSM,
> and
> > then one hop beyond it and see that the same TTL is returned for both
> > interfaces.
> >
> > I need these devices to show up in traceroutes. Is this configuration
> > possible? Google turns up surprisingly little on this.
> >
> > Sam