Traceroute through ASA

[Florin Barhala]

Hi guys,

I have this "common scenario" where ASA drops traceroute traffic.

C:\Windows\system32>tracert -d 10.22.10.63

Tracing route to 10.22.10.63 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.22.20.254
2 2 ms 2 ms 2 ms 10.22.25.4
3 * * * Request timed out.
4 1 ms 1 ms 1 ms 10.22.10.63

Obviously the * is on outside ASA interface. Here's the related config:

1. Capture on ASA for dropped traffic

capture cap4 type asp-drop acl-drop [Capturing - 774 bytes]
match icmp any any

4: 10:37:09.632840 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule

5: 10:37:13.346493 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule

6: 10:37:17.346966 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule

2. Interface config and acl-applied

show ip | i 10.22.1.62
Port-channel1.90 outside 10.22.1.62 255.255.255.240 CONFIG

access-group outside_in in interface outside

3. ACL config

sa outside_in | i icmp
access-list outside_in line 10 extended permit icmp any4 any4 log disable (hitcnt=20821163) 0xb47d85da
access-list outside_in line 12 extended permit icmp any4 any4 time-exceeded (hitcnt=0) 0xa0979724

4. ASA ICMP config

show run icmp
icmp unreachable rate-limit 10 burst-size 5

show run policy-map | i icmp
inspect icmp
inspect icmp error

Any idea is welcome!

[Ilkin]

Are you trying to traceroute directly to the ASA (to-the-box) or through ASA?
10.22.10.62 is assigned to outside, and traceroute is initiated to 10.22.10.63, which is on the same subnet as outside.
If traceroute is intended to 10.22.10.63 and ASA supposed to route this traffic, then packet should come to outside and leave outside. If so, then this is a same-security-traffic intra-interface traffic, and it should be enabled. Otherwise please explain how traffic should flow.

[Florin Barhala]

Hello,
Thanks for reviewing this. Here's my reply:
- outside uses 10.22.1.62 NOT 10.62.
- traffic goes THROUGH ASA
- traffic comes to ASA outside passes through moves to one of the inside interfaces and then reaches the host connected to the inside interface.

[Marvin Rhoads]

By default an ASA won't decrement the icmp ttl used by traceroute even if ICMP is otherwise allowed and inspected.

To get the full functionality including the ASA reporting its interface address in the path, you need to add a line to class-default as follows:

ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class class-default
ciscoasa(config-pmap-c)# set connection decrement-ttl

Source:

https://packetu.com/2009/10/09/traceroute-through-the-asa/

[Ilkin]

OK, if you want to see ASA in the output, you can enable decrementing TTL, as Marvin showed.

[Florin Barhala]

Thank you guys, but this is not about ASA showing up.

On my original post I mentioned those * * * from traceroute are on the ASA.

There's also the asp-drop acl-drop capture I also shared on the ASA. So the issue is that ASA drops the traceroute...

[Marvin Rhoads]

The decrement-ttl will fix the * * * entries assuming everything else is configured correctly.

Your original post shows the ACL entry permitting icmp inbound is currently disabled:

access-list outside_in line 10 extended permit icmp any4 any4 log disable 

[Florin Barhala]

Marvin, I have to disagree: decrement-ttl is present, had it not been present then those * * * should not show up as ASA IP will not be shown. Anyway here's the config:
show run policy-map
policy-map type inspect dns preset_dns_map
parameters
message-length maximum client auto
message-length maximum 512
no tcp-inspection
policy-map global_policy
class inspection_default
inspect ip-options
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect sqlnet
inspect sunrpc
inspect http
inspect icmp
inspect dns preset_dns_map
inspect icmp error
inspect tftp
class SFR
sfr fail-open
class global-class
flow-export event-type all destination 10.22.10.63
class class-default
user-statistics accounting
set connection decrement-ttl

As for the ACL, the ACE is on aka ENABLED; it's only logging that's disabled.

Thanks,

Florin.

[Florin Barhala]

Any idea guys?

[Rob Ingram]

Hi Florin,

"time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule"

As per this document:-

Name: acl-drop

Flow is denied by configured rule:

This counter is incremented when a drop rule is hit by the packet and gets dropped. This rule could be a default rule created when the box comes up, when various features are turned on or off, when an acl is applied to interface or any other feature etc. Apart from default rule drops, a packet could be dropped because of:

1) ACL configured on an interface

2) ACL configured for AAA and AAA denied the user

3) Thru-box traffic arriving at management-only ifc

4) Unencrypted traffic arriving on a ipsec-enabled interface

Your output of configuration are for rules line #10 and #12, could there be a rule above these rules blocking anything from the IP address you are expecting to see traffic from?

Have you tried creating/moving the icmp rule to rule position #1 and re-testing?

HTH

[Florin Barhala]

Hello RJI,

Thanks for the headsup! Ahead of rule 10 there're only Allow rules; I moved it as rule no1&2 and I got the same output.

Review other causes:

1) ACL configured on an interface - ICMP permit on 1st position

2) ACL configured for AAA and AAA denied the user = no AAA policy

3) Thru-box traffic arriving at management-only ifc = not the case, traffic arrives on WAN interface

4) Unencrypted traffic arriving on a ipsec-enabled interface = no NAT or crypto policies are existing on this firewall; both are taken care upstream.

I will open a case to TAC next week and let you all know.

[Ilkin]

4: 10:37:09.632840 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule
5: 10:37:13.346493 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule
6: 10:37:17.346966 10.22.1.62 > 10.22.20.1: icmp: time exceeded in-transit Drop-reason: (acl-drop) Flow is denied by configured rule
It is interesting that ICMP time exceed packets that are generated from Port-channel1.90 are dropped on ASP due to acl-drop, as if the packets are leaving the box and apparently coming back. Can you please check asp-drop capture with detail option to see what are the source and destination MAC addresses on these packets?