[c-nsp] Weird traceroutes through Firewall Services Module (FWSM)

[Sam Stickland]

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/