Its worth noting that from a unix machine, they are using udp based packets to obtain the timeout exceeded, whereas a windows machine is using icmp. This means you are sending udp packets out, then receiving an icmp packet trying to get back in - for which there is not a matching flow in the FW.
Try from a windows machine as the cisco device is using udp packets.
Given that you do not have any windows machines in your network, you must be sourcing your traceroutes from a unix machine, which is using udp packets for traceroute, with gradually inceasing ttl (and gradually increasing port number) to obtain the icmp unreachable inbound. So you need to allow the following range of udp ports outbound, i.e. 33434 to 33464.
And you also need to allow icmp time-exceeded inbound or icmp port-unreachable inbound on the outside interface. Because the firewall is creating a state entry which is automatically going to allow the icmp unreachables inbound based on the udp packets timing out, which originated from the inside.
If you are unsure about this - put a capture on your firewall to capture the packets generated by the source host you are tracerouting from, this will give you information on the packet types.
I'm facing the exact same problem. I'm using asa914-smp-k8.bin. I followed all the configs here and the problem still happening. I can perform traceroute FROM the firewall, but from anything behind it, I can't traceroute to internet. I'm attaching the ACL info. The policy-map is configured like that:
inspect dns preset_dns_map
inspect h323 h225
inspect h323 ras
inspect icmp error
set connection random-sequence-number disable
set connection decrement-ttl
ips inline fail-open sensor vs0
service-policy global_policy global
Can anyone please advise?
Thanks for your reply.
I'm trying from a Windows 2008 Server and from an ASA 5585, both directly connected to this 5555x. There's a fact here: On the Windows machine, the trace is completed, but I never see the hops, like this:
1 <1 ms <1 ms <1 ms 10.100.1.1 <--- inside interface of 5555x
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 42 ms 42 ms 42 ms google-public-dns-a.google.com [22.214.171.124]
In the other hand, if the source is the 5585, the trace is never completed.
With capture, I can see the ICMP requests going out trought the outside of 5555x.
Have you explicitly allowed icmp time-exceeded back in from anywhere on the outside acl of your FW?
I wonder if the final result - google - is allowed out back through because you have a rule specifically allowing this?
It is worth adding the time-exceeded rule on the outside, as although the icmp oputbound is destined for 126.96.36.199, the time-exceeded's will be sent from all the intermediate devices until the ttl is increased sufficiently to allow the packet to reach google.
Let me know how you get on
Can you post the inside-in acl?
Also can you lookup what the next hop on the FW is to reach the internet, and trying to ping that ip address?
Could you try to re-configure the ACL without using the 'object-group' command?
access-list outside_in extended permit icmp any any time-exceeded
access-list outside_in extended permit icmp any any unreachable
Do you know whether you are trying to perform traceroute from a linux or windows host?
A good way of troubleshooting this is to put a packet capture on the inside interface.