Allow Traceroute through ASA ios Versio 9.1

[raghu.jrs]

Hi

We have a ASA5545 with IOS 9.1(1)  we are unable to do Traceroute to any public IP's from the inside host

raghu@mon:~$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  sw1-core-107 (10.10.4.2)  0.425 ms  0.439 ms  0.496 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *

We had a below config on ASA

object-group icmp-type icmp-allowed
 icmp-object echo-reply
 icmp-object unreachable
 icmp-object echo
 icmp-object time-exceeded
 icmp-object traceroute

access-list outside_in extended permit icmp any any object-group icmp-allowed

access-list inside_in extended permit icmp any any object-group icmp-allowed

class-map inspection_default
 match default-inspection-traffic

policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny  
  inspect sunrpc
  inspect xdmcp
  inspect sip  
  inspect netbios
  inspect tftp
  inspect ip-options
  inspect icmp
      
service-policy global_policy global

Do i need to add any other ACL to allow Traceroute Please help

[luckymike33]

Hi,

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.

Cheers

[raghu.jrs]

we not have any Windows box in this network

[luckymike33]

Hi,

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.

Cheers

Mike

[vialves]

Hi all,

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:

policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect icmp 
  inspect icmp error 
  inspect ip-options 
 class class-default
  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!

[vialves]

Hi Mike, 

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 [8.8.8.8]

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.

Any thoughts?

[luckymike33]

Hi vialves,

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 8.8.8.8, 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

cheers

Mike

[vialves]

Hi Mike!

My outside ACL is configured like this:

[luckymike33]

Hi,

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?

Best wishes

Mike

[johnlloyd_13]

Hi,

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

[luckymike33]

Hi,

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.

Best wishes

Mike