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.
Informative article but i would suggest you to look into all best vpn encryption method addressed below:
ReplyDeletehttp://www.bestvpnservice.com/blog/vpn-encryption-128-256-1024-2048-bit-aes-encryption/
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!
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteIs this a bug defect? I am running 9.6.(1) on a Cisco 5516 and experiencing the same issue
ReplyDeleteI don't know to be honest. I haven't checked it. I was happy with the workaround I found.
DeleteThanks it worked for me after a day of troubleshooting
ReplyDelete