Traceroute through Firepower Threat Defense

Nearly eight years ago, I wrote an article about configuring the ASA to permit Traceroute and how to make the device show up in the output. That article is still relevant and gets quite a few hits every day. I wanted to put together a similar How-To article for those using Firepower Threat Defense.

This article examines the configuration required to allow proper traceroute functionality in an FTD environment. The examples shown here leverage Firepower Management Center to manage Firepower Threat Defense. As with any configuration, please assess the security impact and applicability to your environment before implementing.

Before we get started, it is important to understand that there are two basic types of Traceroute implementations. I am using OSX for testing and it defaults to using UDP packets for the test. However, I can also test with ICMP using the -I option. I am already permitting all outbound traffic, so this is not a problem of allowing the UDP or ICMP toward the destination.

Both types of traceroute depend on sending packets with an incrementing TTL field. This is the field that each router decreases as the packet is forwarded. Any router decreasing this to zero should drop the packet and respond with an ICMP Time Exceeded (type 11). This is how that each hop in the path can be determined and displayed.

The final destination has a slightly different behavior depending on whether the outgoing packets are ICMP or UDP. In the case of an ICMP traceroute, the final destination typically responds with an ICMP Echo Reply (Type 0). In the case of a UDP packet arriving at a host not listening on the destination port, the host should respond with an ICMP Unreachable/Port Unreachable (Type 3/Code 3).

This establishes a basis of what must be permitted to make this work properly in our environment.

The Problem

//testing with UDP Method (default OSX)
Macbook:~ me$ traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *


//testing with ICMP Method
Macbook:~ me$ traceroute -I 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  google-public-dns-a.google.com (8.8.8.8)  39.033 ms  47.667 ms  32.298 ms

To solve this, we need to permit ICMP type 3 and type 11 from the outside to the inside. This is accomplished with an appropriate Access Control Policy. In this example, I have created a new rule that allows both of the ICMP types from the desired direction.

Rule applied by Zones

Ports (protocols) being allowed

At this point, it is time to Save, Deploy and Test.

Following these configuration changes, the earlier tests have a different result.

//testing with UDP Method (default OSX)
Macbook:~ me$ traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.4.1 (192.168.4.1)  2.583 ms  2.087 ms  2.542 ms
 2  142.254.154.189 (142.254.154.189)  10.907 ms  56.929 ms  17.546 ms
 3  ae63.londkyzc02h.midwest.rr.com (74.128.5.61)  36.137 ms  39.384 ms  43.293 ms
 4  be23.rcmdkyat02r.midwest.rr.com (65.29.28.206)  23.307 ms  25.573 ms  21.174 ms
 5  be27.clmkohpe01r.midwest.rr.com (65.189.140.168)  26.932 ms  30.333 ms  75.064 ms
 6  bu-ether15.chctilwc00w-bcr00.tbone.rr.com (66.109.6.68)  33.806 ms
    107.14.17.252 (107.14.17.252)  36.941 ms
bu-ether15.chctilwc00w-bcr00.tbone.rr.com (66.109.6.68)  34.465 ms
 7  bu-ether11.chcgildt87w-bcr00.tbone.rr.com (66.109.6.20)  37.185 ms  39.017 ms
    66.109.5.136 (66.109.5.136)  62.194 ms
 8  0.ae0.pr1.chi10.tbone.rr.com (107.14.17.192)  35.938 ms
0.ae2.pr1.chi10.tbone.rr.com (107.14.17.196)  35.523 ms
0.ae1.pr1.chi10.tbone.rr.com (107.14.17.194)  33.563 ms
 9  ix-ae-27-0.tcore2.ct8-chicago.as6453.net (64.86.79.97)  35.702 ms  31.795 ms  32.948 ms
10  209.85.173.6 (209.85.173.6)  37.315 ms  36.152 ms  38.961 ms
11  108.170.243.193 (108.170.243.193)  38.445 ms  36.055 ms
    108.170.244.1 (108.170.244.1)  36.048 ms
12  74.125.37.7 (74.125.37.7)  33.115 ms
    209.85.248.239 (209.85.248.239)  32.393 ms
    72.14.237.39 (72.14.237.39)  35.570 ms
13  google-public-dns-a.google.com (8.8.8.8)  35.099 ms  33.150 ms  33.238 ms

//testing with ICMP Method
Macbook:~ me$ traceroute -I 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
 1  192.168.4.1 (192.168.4.1)  18.716 ms  12.768 ms  1.417 ms
 2  142.254.154.189 (142.254.154.189)  14.117 ms
ae63.londkyzc02h.midwest.rr.com (74.128.5.61)  30.649 ms  32.653 ms
 3  be23.rcmdkyat02r.midwest.rr.com (65.29.28.206)  17.383 ms  22.524 ms  24.137 ms
 4  be27.clmkohpe01r.midwest.rr.com (65.189.140.168)  27.608 ms  23.758 ms  31.088 ms
 5  107.14.17.252 (107.14.17.252)  38.391 ms  84.604 ms  42.351 ms
 6  bu-ether11.chcgildt87w-bcr00.tbone.rr.com (66.109.6.20)  52.255 ms  37.711 ms  69.135 ms
 7  0.ae0.pr1.chi10.tbone.rr.com (107.14.17.192)  33.011 ms  48.156 ms  38.891 ms
 8  ix-ae-27-0.tcore2.ct8-chicago.as6453.net (64.86.79.97)  33.288 ms  32.492 ms  36.738 ms
 9  209.85.173.6 (209.85.173.6)  35.289 ms  35.267 ms  33.536 ms
10  108.170.243.193 (108.170.243.193)  33.531 ms  35.125 ms  32.060 ms
11  72.14.236.65 (72.14.236.65)  33.723 ms  33.018 ms  48.554 ms
12  google-public-dns-a.google.com (8.8.8.8)  33.652 ms  31.226 ms  39.623 ms

We can now see that traceroute works as expected. Or does it??

There is no way someone not familiar with my environment could know this, but 192.168.4.1 is not my FTD instance. My Firepower Threat Defense is at 192.168.1.251. This is the other issue that we saw with the ASA. To make the FW show up in the trace, it is necessary to configure it to decrement the TTL. This process is always on for routers but some firewalls do not perform that function.

This is configured in a policy-map via FlexConfig. To make the adjustments in Firepower Management Center, go to Devices, FlexConfig. Create a new policy and add a new policy object. I have created a policy called MyFlexConfig and applied it to FTD (my device).

The new policy object should contain the following text. I configured my example to be an appended.

policy-map global_policy
 class class-default
  set connection decrement-ttl

 

It this point, we can Save, Deploy and Test once again.

At this point, the traceroutes should succeed AND the Firepower device should show up in the path.

//testing with UDP Method (default OSX)
Macbook:~ me$ traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.1.251 (192.168.1.251)  33.693 ms *  2.875 ms
 2  192.168.4.1 (192.168.4.1)  2.887 ms  2.027 ms  2.274 ms
 3  142.254.154.189 (142.254.154.189)  11.708 ms  13.612 ms  17.083 ms
 4  ae63.londkyzc02h.midwest.rr.com (74.128.5.61)  560.464 ms  29.416 ms  30.504 ms
 5  be23.rcmdkyat02r.midwest.rr.com (65.29.28.206)  22.827 ms  24.442 ms  23.206 ms
 6  be27.clmkohpe01r.midwest.rr.com (65.189.140.168)  31.189 ms  30.715 ms  26.517 ms
 7  bu-ether15.chctilwc00w-bcr00.tbone.rr.com (66.109.6.68)  93.446 ms  39.309 ms
    107.14.17.252 (107.14.17.252)  36.954 ms
 8  66.109.5.136 (66.109.5.136)  38.169 ms
bu-ether11.chcgildt87w-bcr00.tbone.rr.com (66.109.6.20)  56.153 ms
    66.109.5.136 (66.109.5.136)  35.742 ms
 9  0.ae1.pr1.chi10.tbone.rr.com (107.14.17.194)  33.646 ms
0.ae2.pr1.chi10.tbone.rr.com (107.14.17.196)  35.222 ms
0.ae0.pr1.chi10.tbone.rr.com (107.14.17.192)  41.772 ms
10  ix-ae-27-0.tcore2.ct8-chicago.as6453.net (64.86.79.97)  44.286 ms  43.011 ms  33.783 ms
11  209.85.173.6 (209.85.173.6)  51.632 ms  36.567 ms  113.951 ms
12  108.170.243.225 (108.170.243.225)  43.326 ms
    108.170.243.193 (108.170.243.193)  45.109 ms
    108.170.243.174 (108.170.243.174)  33.266 ms
13  74.125.37.39 (74.125.37.39)  36.551 ms
    216.239.47.219 (216.239.47.219)  36.150 ms
    74.125.37.3 (74.125.37.3)  77.429 ms
14  google-public-dns-a.google.com (8.8.8.8)  35.631 ms  32.015 ms  36.133 ms

//testing with ICMP Method
Macbook:~ me$ traceroute -I 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
 1  192.168.1.251 (192.168.1.251)  3.031 ms *  2.672 ms
 2  192.168.4.1 (192.168.4.1)  1.792 ms  4.182 ms  1.743 ms
 3  142.254.154.189 (142.254.154.189)  15.566 ms
ae63.londkyzc02h.midwest.rr.com (74.128.5.61)  39.770 ms  24.967 ms
 4  be23.rcmdkyat02r.midwest.rr.com (65.29.28.206)  21.805 ms  24.120 ms  23.508 ms
 5  be27.clmkohpe01r.midwest.rr.com (65.189.140.168)  28.891 ms  27.012 ms  30.551 ms
 6  107.14.17.252 (107.14.17.252)  33.329 ms  41.946 ms  45.955 ms
 7  bu-ether11.chcgildt87w-bcr00.tbone.rr.com (66.109.6.20)  44.559 ms  38.912 ms  32.219 ms
 8  0.ae0.pr1.chi10.tbone.rr.com (107.14.17.192)  62.060 ms  31.213 ms  69.452 ms
 9  ix-ae-27-0.tcore2.ct8-chicago.as6453.net (64.86.79.97)  33.546 ms  34.491 ms  31.504 ms
10  209.85.173.6 (209.85.173.6)  35.003 ms  42.090 ms  37.075 ms
11  108.170.243.193 (108.170.243.193)  35.593 ms  91.581 ms  33.921 ms
12  72.14.236.65 (72.14.236.65)  44.597 ms  35.280 ms  34.502 ms
13  google-public-dns-a.google.com (8.8.8.8)  33.989 ms  36.632 ms  47.202 ms

At this point, we can see that this works as expected. If you found this article useful, please share it with others who work with this solution.

ASA Administrators should also check out – Traceroute Through the ASA.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

 

 

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.