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

Sam Stickland sam_mailinglists at spacething.org
Thu May 18 08:04:11 EDT 2006


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

> -----Original Message-----
> From: Sam Stickland [mailto:sam_mailinglists at spacething.org]
> Sent: 16 May 2006 14:42
> To: 'Sam Stickland'; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Weird traceroutes through Firewall Services Module
> (FWSM)
> 
> Ok, found out some more information here regarding these sort of issues:
> 
> Here's a traceroute without "fixup protocol icmp error" (through another
> part of the network):
> 
> Tracing route to 10.254.189.246 over a maximum of 30 hops
> 
>   1    <1 ms    <1 ms    <1 ms  172.20.111.250
>   2    <1 ms    <1 ms    <1 ms  10.254.189.246
>   3     1 ms    <1 ms    <1 ms  10.254.189.246
>   4     1 ms     1 ms     2 ms  10.254.189.246
>   5   603 ms   496 ms   324 ms  10.254.189.246
>   6     6 ms     6 ms     6 ms  10.254.189.246
>   7   594 ms   391 ms   279 ms  10.254.189.246
>   8     6 ms     6 ms     6 ms  10.254.189.246
>   9   671 ms   415 ms   109 ms  10.254.189.246
>  10     9 ms     8 ms     9 ms  10.254.189.246
>  11   719 ms   256 ms   134 ms  10.254.189.246
> 
> Enabling "fixup protocol icmp error" gets us this:
> 
> Tracing route to 10.254.189.246 over a maximum of 30 hops
> 
>   1    <1 ms    <1 ms    <1 ms  172.20.111.250
>   2    <1 ms    <1 ms    <1 ms  10.254.252.3
>   3     *        *        *     Request timed out.
>   4     *        *        *     Request timed out.
>   5     *        *        *     Request timed out.
>   6     *        *        *     Request timed out.
>   7     *        *        *     Request timed out.
>   8     *        *        *     Request timed out.
>   9     *        *        *     Request timed out.
>  10   140 ms    50 ms     9 ms  10.254.182.253
>  11     9 ms     9 ms     9 ms  10.254.189.246
> 
> Now we see entries on the other side of the FWSM blade which have
> translation entries on the PIX?
> 
> The interesting thing is that on this traceroute the FWSM blade sits in
> between hops 1 an 2, a Layer3 device that has completely hidden itself in
> the traceroute! Surely this would require that the FWSM isn't decreasing
> the
> TTL of packets that are passing through it?!
> 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Sam Stickland
> > Sent: 16 May 2006 13:29
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] Weird traceroutes through Firewall Services Module
> (FWSM)
> >
> > Hi,
> >
> > We have some weirdness with the FWSM blades and traceroutes. If you try
> to
> > trace through an FWSM blade then from the moment it hits the FWSM all
> the
> > hopes appear to be the final one:
> >
> > For example:
> >
> > # traceroute 10.20.232.20
> > traceroute to 10.20.232.20 (10.20.232.20), 30 hops max, 38 byte packets
> >  1  10.20.1.254   1.807 ms  2.932 ms  0.279 ms
> >  2  10.20.255.21  0.387 ms  0.232 ms  0.303 ms
> >  3  10.20.232.20  0.628 ms  0.624 ms  0.638 ms
> >  4  10.20.232.20  1.038 ms  0.718 ms  0.653 ms
> >
> > Hop 3 is actually the FWSM blade. If there were more hops behind the
> blade
> > they would all show up as 10.20.232.20. The FWSM blade is NAT
> translating,
> > but why would it not show up in the traceroute? Surely it's outside
> facing
> > interface would return the ICMP TTL Exceeded?
> >
> > We can see that it doesn't manually:
> >
> > # ping -t2 10.20.232.20
> > PING 10.20.232.20 (10.20.232.20) 56(84) bytes of data.
> > >From 10.20.255.21 icmp_seq=0 Time to live exceeded
> > >From 10.20.255.21 icmp_seq=1 Time to live exceeded
> >
> > # ping -t3 10.20.232.20
> > PING 10.20.232.20 (10.20.232.20) 56(84) bytes of data.
> > >From 10.20.232.20 icmp_seq=0 Time to live exceeded
> > >From 10.20.232.20 icmp_seq=1 Time to live exceeded
> >
> > # ping -t4 10.20.232.20
> > PING 10.20.232.20 (10.20.232.20) 56(84) bytes of data.
> > 64 bytes from 10.20.232.20: icmp_seq=0 ttl=252 time=0.685 ms
> > 64 bytes from 10.20.232.20: icmp_seq=1 ttl=252 time=0.781 ms
> >
> > This strikes me as odd. Fixup protocol icmp has no effect here.
> >
> > Any ideas?
> >
> > Sam
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/




More information about the cisco-nsp mailing list