Tidbit: Hide Routers from Traceroute
Do you have that one guy in desktop support that always blames the network? Does he constantly ask why his trace route is going through device XYZ!? Then I have a solution for you! Hide your network from that sketchy desktop support guy!
In MPLS its easy squeezy (‘no mpls ip propagate-ttl’), but what if you don’t have MPLS? Well here’s a quick way to do it:
ip access-list extended ACL_Traceroute permit icmp any any time-exceeded permit icmp any any port-unreachable
Firstly just make an extended ACL to match (permit) imcp time-exceeded and port-unreachable. The time-exceeded messages are basically the messages that the TTL is decremented (is decremented even a real word?) in and sent back to the original sender. The port-unreachable is basically what it sounds like — if the gateway does not have a route for the prefix, this message should be sent back to the sender.
So what are we doing with this ACL? Well we match it in a route-map, point it to the bit bucket, and apply it as local policy:
route-map RM_Traceroute perm 10 match ip add ACL_Traceroute set interface null0 ! ip local policy route-map RM_Traceroute
The outcome is that the devices configured with this local policy do not show up in a trace route. Below is the initial ‘baseline’ test from an OSX client to an OSX client across three routers:
Carls-MacBook-Pro:~ carl$ traceroute 10.10.200.5 traceroute to 10.10.200.5 (10.10.200.5), 64 hops max, 52 byte packets 1 10.10.100.1 (10.10.100.1) 4.144 ms 1.497 ms 2.159 ms <--- Gateway for my first laptop 2 10.10.1.2 (10.10.1.2) 8.056 ms 6.473 ms 6.217 ms <--- R1 3 10.10.1.6 (10.10.1.6) 10.247 ms 10.345 ms 10.267 ms <--- R2 4 10.10.200.5 (10.10.200.5) 12.336 ms 12.538 ms 12.312 ms <--- Final host connected to R3
Now, here is that exact same trace route after adding our local policy:
Carls-MacBook-Pro:~ carl$ traceroute 10.10.200.5 traceroute to 10.10.200.5 (10.10.200.5), 64 hops max, 52 byte packets 1 * * * 2 * * * 3 * * * 4 10.10.200.5 (10.10.200.5) 12.807 ms 11.450 ms 12.440 ms
As you can see this doesn’t ‘break’ the trace route, just kind of hides our routers. Note that a trace route TO a router will not complete since there is no message being sent back to the original sender since you are basically dropping the relevant incoming messages. As long as your destination is connected to a router that does NOT have the local policy though your traces will complete as per normal.
My understanding is that there are essentially three different ‘flavors’ of trace route — UNIX trace route (UDP), Windows trace route (tracert) which is strictly ICMP, and TCPTraceroute. So I tested this policy with a Windows host as well with basically the same results.
The baseline test:
C:\Users\Carl>tracert 10.10.200.6 Tracing route to Carl-PC [10.10.200.6] over a maximum of 30 hops: 1 3 ms 2 ms 2 ms 10.10.100.1 2 7 ms 6 ms 6 ms 10.10.1.2 3 11 ms 11 ms 10 ms 10.10.1.6 4 12 ms 11 ms 12 ms Carl-PC [10.10.200.6]
And after adding the policy:
C:\Users\Carl>tracert 10.10.200.6 Tracing route to Carl-PC [10.10.200.6] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 12 ms 12 ms 13 ms Carl-PC [10.10.200.6]
So everything worked as planned!
I’m fairly confident that this will work for TCPTraceroutes as well but I didn’t test it out as I’m not 100% how to go about doing that… perhaps thats a post for another time.
