Cisco ASA and ICMP – Why Can’t Drops Be Seen via aspdrop?

ciscocisco-asaicmp

Pinging from one SRC to a few DST's I can see some drops happening on my captures for some attempts and none for others. Wondering how I can see what's really happening to ALL of the arriving icmp packets outlined in my tests below. Thank you!

Topology:

enter image description here

ASA config – ready to paste into GNS3:

!-- Test lab script
En

Conf t
Hostname US

Int gi0
Ip address 172.30.1.1 255.255.255.0
Nameif backend
Security-level 50
No shut

Int gi1
Ip address 10.15.99.129 255.255.255.0
Nameif data_admin
Security-level 50
No shut

Same-security-traffic permit inter-interface

Object network host_10.15.99.129
  host 10.15.99.129

Object network host_10.59.2.137
  host 10.59.2.137

Access-list backend line 1 extended permit ip any any
Access-list backend line 1 extended permit icmp any any echo
Access-list data_admin line 1 extended permit ip any any
Access-list data_admin line 1 extended permit icmp any any echo

Access-group backend in int backend
Access-group data_admin in int data_admin

route backend 10.80.55.0 255.255.255.0 172.30.1.2

Nat (data_admin,backend) source static host_10.15.99.129 host_10.59.2.137

Class-map icmp-class
  match any
Exit

Policy-map icmp_policy
  class icmp-class
    inspect icmp
Exit

Service-policy icmp_policy interface backend
Service-policy icmp_policy interface data_admin

Capture capin int backend match icmp any any
Capture capout int data_admin match icmp any any
Capture aspdrop type asp-drop all match ip any any

Packet captures:

!-- From PC to NAT IP of data_admin interface (FW)
9 packets captured

   2: 04:27:33.064129 10.80.55.50 > 10.59.2.137: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
   5: 04:27:35.046445 10.80.55.50 > 10.59.2.137: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
   7: 04:27:37.105936 10.80.55.50 > 10.59.2.137: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
   8: 04:27:39.090586 10.80.55.50 > 10.59.2.137: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
   9: 04:27:41.117944 10.80.55.50 > 10.59.2.137: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule

!-- From PC to interface IP of data_admin interface (FW)
Nothing

!-- From PC to data_admin router interface 
12 packets captured

   5: 19:24:07.343045 10.80.55.50 > 10.15.99.130: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
   6: 19:24:09.287643 10.80.55.50 > 10.15.99.130: icmp: echo request
   7: 19:24:11.370510 10.80.55.50 > 10.15.99.130: icmp: echo request
  10: 19:24:13.166022 10.80.55.50 > 10.15.99.130: icmp: echo request
  11: 19:24:15.201863 10.80.55.50 > 10.15.99.130: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule
  12: 19:24:17.262223 10.80.55.50 > 10.15.99.130: icmp: echo request Drop-reason: (acl-drop) Flow is denied by configured rule

Once we answer the question of why I can't see some of these drops. I would like to know why these are getting dropped in the first place. I've already tried things like setting the service-policy to global, setting the inspection policy in the default class, or setting inspection globally, all with the same results. Ultimately though should inspection of icmp and allowance by ACL not account for everything?

Best Answer

I have just tested your setup in GNS3 (v1.3.8) with ASA image asa842.

To answer your questions...

!-- From PC to NAT IP of data_admin interface (FW)

The reason your ICMP packets are dropped is due to RPF (anti-spoofing). The ASA checks your routing table against the ingress DST (=host_10.59.2.137) which cannot be found because there is no entry within the routing table.

To verify the cause enable logging and ping the NAT ip address again.

US(config)#logging enable
US(config)#logging console 7

Cisco Documentation - RPF

!-- From PC to interface IP of data_admin interface (FW)

You cannot ping a distant interface on ASA by design. For example you cannot ping the outside interface from the inside network.

!-- From PC to data_admin router interface

Have you pinged multiple times? Populating mapping tables in GNS3 takes more time than with real equipment. I had no issues with that one.

Related Topic