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.