0

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?

2

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.

| improve this answer | |
  • great feedback!! Interesting about the RPF issue, I'll need to test this later - curious it lists the reason in packet tracer as a drop... Is there any way to add a route that will allow this to work that you know of?? - Also great to know about the design of the ASA and not being allowed to hit distant interfaces! There's always more to learn isn't there? I will test these results and get back here with an upvote/answer should everything check out. – A L Oct 11 '15 at 23:33
  • A host route to the egress interface (BACKEND) should do the trick. Normally one does not ecounter is problem because most ppl only NAT on the outside interface which has a default route associated with it. :) – kaisero Oct 12 '15 at 5:56
  • Going to mark this response as the answer for the assistance kaisero - have not had time to fully test everything and probably won't have time for a while. Thank you again! I will confirm back here after testing even if that is quite some time down the line. – A L Oct 22 '15 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.