Type: VPN Subtype: encrypt Result: DROP - asymmetric ACLs on Cisco IPsec VPN ASA edges

Intro


I have recently encountered some strange issue as for the Cisco IPsec VPN between two sites of my organization. I had the VPN SAs established and proper ACLs permitting a desired subset of a traffic attached to the crypto map, but the traffic was not able to pass anyway. Finally, it has been revealed that this was happening because of asymmetric ACLs on the neighboring Cisco ASAs.

Lets now have a look on a simplified configuration I had. On the site A I had subnets from 10.0.0.0/8 network. On the site B I had subnets from 172.16.0.0/12 network. Cisco ASA on the site A was running Cisco Adaptive Security Appliance Software Version 8.2(5) while Cisco ASA on the site B was running version 7.2.(4) (I suppose that the issue might be related to software versions incompatibility, a bug in a certain software version, etc.). Related part of configuration on each of the Cisco ASA instances was as follows:
  • site A:
...
object-group network A-site-subnets
 network-object 10.0.0.0 255.255.0.0
 network-object 10.1.0.0 255.255.0.0
 ...
 network-object 10.255.0.0 255.255.0.0
object-group network B-site-subnets
 network-object 172.16.0.0 255.240.0.0
...
access-list A2B extended permit ip object-group A-site-subnets object-group B-site-subnets
...
crypto map A-map 1 match address A2B
...
  • site B:
...
object-group network B-site-subnets
 network-object 172.16.0.0 255.255.0.0
 network-object 172.17.0.0 255.255.0.0
 ...
 network-object 172.31.0.0 255.255.0.0
object-group network A-site-subnets
 network-object 10.0.0.0 255.0.0.0
...
access-list B2A extended permit ip object-group B-site-subnets object-group A-site-subnets
...
crypto map B-map 1 match address B2A
...

Troubleshooting


To quickly test whether the communication issues are caused by asymmetric ACLs on the neighboring Cisco ASA edges, run the packet-tracer command on any instance specifying the parameters that should result in an ALLOW decision:

A-site-ASA# packet-tracer input inside icmp 10.0.0.1 0 0 172.16.0.1
...
Phase: 11     
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

If the command results in an output like the above, you can safely move to the following section.

How to fix the issue


To get rid of the above errors redesign A-site-subnets and B-site-subnets object groups, and as a result the A2B and B2A ACLs, that they either include the particular subnets or the whole network summary. To save my time I have chosen the second approach:
  • site A:
object-group network A-site-subnets
 network-object 10.0.0.0 255.0.0.0
  • site B:
object-group network B-site-subnets
 network-object 172.16.0.0 255.248.0.0

A this point the traffic should be able to pass between Cisco ASA instances.

6 comments:

  1. Informative article but i would suggest you to look into all best vpn encryption method addressed below:
    http://www.bestvpnservice.com/blog/vpn-encryption-128-256-1024-2048-bit-aes-encryption/

    ReplyDelete
  2. This helped me with an issue I was facing with a Site-to-site from a Cisco ASA and Amazon AWS/VPC. Traffic was either going to one subnet or the either, but not both. After I changed the site-to-site profile in my ASDM for my local networks to be 10.0.0.0/8 instead of individual subnets, traffic seemed to flow properly amongst all the subnets. Not sure why that would make a difference, but it did, Thanks!

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Is this a bug defect? I am running 9.6.(1) on a Cisco 5516 and experiencing the same issue

    ReplyDelete
    Replies
    1. I don't know to be honest. I haven't checked it. I was happy with the workaround I found.

      Delete
  5. Thanks it worked for me after a day of troubleshooting

    ReplyDelete