Source: http://www.packetu.com/

The Cisco ASA has some interesting characteristics when dealing with traceroute.  With most traffic, including ICMP echo, outbound traffic can be inspected to allow the incoming traffic associated with the same flow.  Inspecting “ICMP” or even “ICMP Error” does not result in traceroute functioning through the ASA.

The first thing that we need to look at is how traceroute works.  Traceroute uses two different types of ICMP packets.  Windows systems use an ICMP with incrementing TTL’s to illicit an ICMP TTL exceeded message from each hop along the way.  Linux and Cisco use a UDP port with pseudorandom destination port.  With the UDP method, an incrementing TTL is still used to illicit a message from each hop along the way.  However, the message that is produced is an “ICMP unreachable port-unreachable” message.

To understand how traceroute works, it is important to understand the function of the TTL field in the IP packet header.  This field is an 8 bit value that works with routers to keep packets from looping forever as a result of network configuration issues.  The way this is accomplished is that each router along the way decreases the value by 1.  Normal traffic may start out with a TTL of 64, 128, 255 or any other non-zero value.  As the traffic traverses a router, this TTL in the IP header is reduced by one.

When a router decreases the value to zero, it drops the packet.  When this happens the device will respond with an “ICMP TTL exceeded” if it is in response to an ICMP packet.  If it is in response to a TCP or UDP packet, it will respond with an “ICMP Unreachable Port-Unreachable”.  It is worth noting that the device can usually be configured to not respond at all.

Traceroute takes advantage of this behavior and generates a series of packets.  The first packet(s) will have a TTL of one and be dropped by the first router.  The next packet(s) will have a TTL of two and be dropped by the second router.   This is used to build a map of the network.  If there is a device configured not to respond traceroute will indicate the presence of a device, but its IP address will not be identified.

With our default ASA configuration, let’s see if traceroute will work.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  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     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14    16 ms    24 ms     7 ms  208.69.36.231

Trace complete.

As we can see, there is no intermediary information.  So we know that we are not receiving the ttl exceeded messages from the routers in the network.  The ASA requires special configuration to permit the traffic.  The first challenge is to permit these TTL exceeded and port unreachables back into the network.  This can be done only by using an ACL bound to the outside interface.

ASA Config

//create an ACL that permits the incoming ICMP
access-list outside_access_in remark ICMP type 11 for Windows Traceroute
access-list outside_access_in extended permit icmp any any time-exceeded
access-list outside_access_in remark ICMP type 3 for Cisco and Linux
access-list outside_access_in extended permit icmp any any unreachable

//bind the ACL to the outside interface
access-group outside_access_in in interface outside

Now let’s test traceroute again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com
Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1     3 ms     3 ms     4 ms  71.30.192.1 <— Not My ASA
  2     3 ms     6 ms     3 ms  151.213.31.168
  3     4 ms     3 ms     4 ms  75.90.222.23
  4     4 ms     4 ms    15 ms  75.90.222.25
  5     6 ms     6 ms     5 ms  151.213.254.36
  6     7 ms    10 ms     7 ms  12.118.104.17
  7     7 ms     7 ms     5 ms  12.122.132.98
  8    36 ms     8 ms    28 ms  12.123.7.250
  9    10 ms     6 ms     6 ms  12.122.132.17
 10    26 ms    10 ms    14 ms  192.205.33.194
 11    27 ms    18 ms    12 ms  154.54.3.242
 12    26 ms    14 ms    11 ms  38.112.35.122
 13     8 ms     9 ms     6 ms  38.104.102.62
 14     7 ms     7 ms     6 ms  208.69.36.230

Trace complete.

Now that looks much better.  However, I can see that my ASA is not listed in the path.  That is very strange.  Upon investigation, I determine that the ASA itself does not decrease the TTL as it passes traffic.  Firewalls often play by slightly different rules than a router and this is one of those exceptions.  However, we can change this behavior using the set connection option in the modular policy framework (MPF).

ASA Config

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class class-default
ciscoasa(config-pmap-c)# set connection decrement-ttl

Now, let’s test traceroute again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     1 ms     *        1 ms  75.117.163.238 <— My ASA
  2     3 ms     3 ms     4 ms  71.30.192.1
  3     8 ms     3 ms     3 ms  151.213.31.170
  4    47 ms    31 ms     4 ms  75.90.222.23
  5    94 ms     4 ms     8 ms  75.90.222.25
  6     5 ms     4 ms     6 ms  151.213.254.36
  7    18 ms     5 ms     6 ms  12.118.104.17
  8     9 ms     6 ms     5 ms  12.122.133.98
  9     7 ms     7 ms     8 ms  12.123.7.110
 10     7 ms     6 ms    32 ms  12.122.133.13
 11    11 ms    11 ms    22 ms  192.205.33.194
 12    59 ms    48 ms    36 ms  154.54.3.234
 13    15 ms    12 ms    13 ms  38.112.35.122
 14    13 ms     5 ms    17 ms  38.104.102.62
 15     8 ms     6 ms     5 ms  208.69.36.231

Trace complete.

We can now see an extra hop (75.117.163.238 is an address on my ASA), but there are missing statistics (see the *). This is a result of the fact that the ASA is not responding to all of the traceroute packets.  This is due to the rate-limiting of ICMP on the ASA.  We can adjust this as well.

ASA Config

ciscoasa(config)# icmp unreachable rate-limit 10 burst-size 5

Now let’s test this one more time.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  75.117.163.238 <— My ASA
  2     6 ms     5 ms     4 ms  75.117.160.1
  3     5 ms     5 ms     4 ms  151.213.31.168
  4     5 ms     4 ms     6 ms  75.90.222.23
  5     9 ms     7 ms     7 ms  75.90.222.25
  6     6 ms     5 ms     8 ms  151.213.254.36
  7    10 ms     8 ms    14 ms  12.118.104.17
  8    19 ms     9 ms     8 ms  12.122.133.98
  9    12 ms     7 ms    30 ms  12.123.7.110
 10     8 ms    10 ms    29 ms  12.122.133.9
 11    38 ms    47 ms    14 ms  192.205.33.194
 12    12 ms    48 ms    32 ms  154.54.3.246
 13    15 ms    42 ms    14 ms  38.20.40.174
 14     8 ms     7 ms    26 ms  38.104.102.62
 15     9 ms     8 ms    11 ms  208.69.36.230

Trace complete.

Now we can see solid statistics on the first hop.  Now our ASA is working correctly with traceroute traffic.  I want to show one more example of a way to break traceroute.

Let’s set the IP Audit Attack policy on the outside interface.

ASA Config

ciscoasa(config)#ip audit name myattack attack action alarm drop
ciscoasa(config)#ip audit interface outside myattack

Now we can run our test again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.231]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2    19 ms    19 ms     4 ms  75.117.160.1
 ^C

We can see the issue has resurfaced.  If we have logging enabled, we can see the IDS engine is detecting this as a “land” attack.

ciscoasa(config)# show log | inc IDS
%ASA-4-400008: IDS:1102 IP land attack from 75.117.163.238 to 75.117.163.238 on

Let’s disable just this one signature.

ASA Config

ciscoasa(config)# ip audit signature 1102 disable

Now we can retest this once again.

Windows PC

C:\Documents and Settings\paul>tracert -d www.google.com

Tracing route to google.navigation.opendns.com [208.69.36.230]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  75.117.163.238
  2    11 ms     8 ms     4 ms  75.117.160.1
  3     9 ms    13 ms    11 ms  151.213.31.168
  4     7 ms     8 ms    10 ms  75.90.222.23 
 ^C

Now you can see that we have a successful traceroute configuration on our ASA.  So if I were to receive a lab question that says to make sure traceroute will work through my ASA, that question can mean several things.  If I get such a question on the lab and it is vague, I will verify with the proctor exactly what a successful traceroute means.  I will also keep in mind that if I enable ids on the ASA that I should probably re-check the traceroute to verify it still works.

Leave a Reply

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните ви за коментари.