In the access-list applied to your interface, you need to block icmp time-exceeded. This will not stop your router from responding to a trace probe, but it will revent further replies. So if you create and access-list with the following entry:
access-list 110 deny icmp any any eq time-exceeded
and apply that access-group to your interface it will block traceroutes. To test this put it as an outbound access-list facing the windows PC you are running the traceroute from. The last response you should get is the one from that router. Any responses beyond that will get blocked.
In practice, you need to apply the access-list outbound on your external facing interface, which will prevent anyone from tracing into your network any further than your external router. The last reachable hop on the traceroute from the outside should be the router. None of your internal infrastucture will be revealed. This will also still allow you to do traceroutes out of your network, but keep people on the outside from tracing in.
My mistake. It doesn't look like TTL exceeded is one of the ICMP type 3 unreachable messages.
Apparently it's an ICMP type 11 message.
As i understand you just want to decrease the number of hops in traceroute. It can be done by opennig a GRE tunnel end-to-end or on the path you want to hide. And than just do necessary routing and the user will see only tunnel ip addresses nothing more.
Hope this is what you are looking for.
I setup the GRE tunnel. However when its assigned to my core router, Pings stop.
ip address 22.214.171.124 255.255.255.252
tunnel source x.x.x.x (my core)
tunnel destination x.x.x.x (my public outside)
access-list 111 deny icmp 10.200.78.0 0.0.0.255 any
access-list 111 deny icmp any 10.200.78.0 0.0.0.255
access-list 111 deny icmp 10.200.81.0 0.0.0.255 any
access-list 111 deny icmp any 10.200.81.0 0.0.0.255
access-list 111 permit icmp any any
access-list 111 permit udp any any gt 33434
route-map GRE permit 20
match ip address 111
set ip next-hop 126.96.36.199
show route GRE
route-map GRE, permit, sequence 20
ip address (access-lists): 111
ip next-hop 188.8.131.52
Policy routing matches: 10555 packets, 996642 bytes
I have on my firewall permitting GRE and it shows tons of hits. The outside router shows this:
ip address 184.108.40.206 255.255.255.252
tunnel source x.x.x.x (my public outside)
tunnel destination x.x.x.x (internal core)
I dont have anything else assigned to this router other than this command. I was told that this was all that needs to be done. But Im assuming at this point that I have to build an access-list and assign it to the tunnel too right? This access-list is going to be more complicated if thats the case..
Well this got extremely complicated with my NAT/PAT I do on some firewalls. So scrapped that with the GRE tunnel and was able to do this:
access-list 110 permit icmp any any time-exceeded
route-map NULL permit 10
match ip address 110
set interface Null0
ip local policy route-map NULL
All I need to do now is just add a deny to the access list on the networks that need to see trace routes...
Your best bet to deny traceroute and pings into your network would be to put and access-list outbound on your external router which blocks outbound icmp echo-reply and time-exceeded messages. That will prevent people from pinging in or tracing into your network, but will still allow you to ping out and trace out.
The other thing, I would like to say be very careful running a GRE tunnel through a firewall. You pretty much defeat the purpose of the firewall since the traffic matching the GRE rule is passed through the firewall, preventing any kind of filtering that is normally done by the firewall. It provides another backdoor into your network.
Try this, it will stop your router responding to traceroute requests.
ip local policy route-map NO_TRACEROUTE
ip access-list extended no_traceroute
permit icmp any any time-exceeded
permit icmp any any port-unreachable
route-map NO_TRACEROUTE permit 10
match ip address no_traceroute
set interface Null0
But the problem with that approach is it does not allow you to perform a traceroute out of your network as it applies to your traces as well. I still think the best option is to block outgoing time-execeeded messages and outgoing echo replies. Additionally, you could block incoming icmp echo requests, and incoming udp packets with ports above 33000
Actually it does work. What I listed was just for everything. I have gone back and added denies before the permit on the access list for the networks I do not want to be affected by this policy map.
Outside of using MPLS, and using the MPLS propagate ttl feature, I think Ekiriakos suggestion is the best.
Like you mentioned, applying the access-list to the interface implies that all icmp ttl exceeded packets are dropped. Hence, the traceroutes can not proceed beyond the router.
However, by creating a local policy, which applies to packets originating from the router, you can deny icmp ttl exceeded messages from being originated by the router, while the router will start route the icmp packets. Hence, in your traceroute, you get asterisks, rather than the ip address and the trace continues.
As said before, the MPLS will be the best, and I think a number of service provider are using this. It hides the entire core, because you do not even see the asterisks. Hence you do not even know the number of hops along the service provider.
This is an old thread and I would have thought that in 11 years Cisco would be able to emulate what Unix does with the IPSTEALTH flag which basically allows to the TTL to not be decremented - which helps to make a router truly invisible. Is there some new IOS trick similar to IPSTEALTH, so that the TTL is not decremented?