When you are in need to allow traceroute for whatever reasons (which is blocked by default) you’ll see a lot of references to modify global policy on your appliance.
I’ve found that this is just the half of the puzzle and may not work for some folks. I still can’t determine if this is based on the code/hardware since global used to work for me – if you know the answer please drop a comment.
You can verify your global policy for the class by running this command:
asa/act/sec# sh run policy-map
inspect dns preset_dns_map
inspect h323 h225
inspect h323 ras
If the decrement-ttl class is not present proceed with modifying global policy which in theory should allow traceroute to go through:
asa/act/sec(config)# policy-map global_policy
asa/act/sec(config-pmap)# class class-default
asa/act/sec(config-pmap-c)# set connection decrement-ttl
If the traceroute is still not working you can grab tcp dump which should give you similar output:
8: 14:35:35.504246 802.1Q vlan#9 P0 188.8.131.52.52467 > 184.108.40.206.33438: udp 32 Drop-reason: (ttl-exceeded) ttl exceeded
9: 14:35:35.504337 802.1Q vlan#9 P0 220.127.116.11.40669 > 18.104.22.168.33439: udp 32 Drop-reason: (ttl-exceeded) ttl exceeded
10: 14:35:35.504505 802.1Q vlan#9 P0 22.214.171.124.59213 > 126.96.36.199.33437: udp 32 Drop-reason: (ttl-exceeded) ttl exceeded
I’ve noticed that adjusting your outside-in access-group is required besides policy-map. It is unclear for me at this moment why that extra step is needed but permitting time-exceeded and unreachable will allow traceroute to work.
access-list OUTSIDE_IN extended permit icmp any any time-exceeded
access-list OUTSIDE_IN extended permit icmp any any unreachable
After that you should be good to go. Let me know if that worked for you.
Lastly, I would advise to have this rule removed once done with your testing for security reasons.