02-14-2013 09:04 AM - edited 03-04-2019 07:01 PM
In regards to ACLs used to match interesting traffic for IPSec L2L VPN tunnels, let's say I have a tunnel to one site, and a tunnel to another site.
On one tunnel, the destination network defined in the crypto map is 10.35.70.0/24
On the other tunnel, the destination network defined in the crypto map is 10.0.0.0/8
If traffic is destined to the 10.35.70.0/24 network, will it always be matched and sent over that tunnel, or will the overlapping subnet on the other crypto map cause an issue?
Does this setup work similarly to routing, where the more specific route/path is taken?
Thanks
Solved! Go to Solution.
02-14-2013 11:26 AM
I have not actually done this and I am not authoritative on this. But I would think that the answer is that it depends on the order in which the crypto map uses the access lists. If the crypto map instance 10 calls the /24 ACL and if instance 20 calls the /8 ACL then I believe that it will work as you wish it would. But if instance 10 calls the /8 and instance 20 calls the /24 then I believe that all traffic will be sent to the peer in instance 10 and that is not what you want.
HTH
Rick
02-14-2013 11:26 AM
I have not actually done this and I am not authoritative on this. But I would think that the answer is that it depends on the order in which the crypto map uses the access lists. If the crypto map instance 10 calls the /24 ACL and if instance 20 calls the /8 ACL then I believe that it will work as you wish it would. But if instance 10 calls the /8 and instance 20 calls the /24 then I believe that all traffic will be sent to the peer in instance 10 and that is not what you want.
HTH
Rick
02-14-2013 11:34 AM
Thanks for the insight - that's a great point. I believe you are correct in that a connection will cycle through the crypto maps sequentially until it finds a match as I've seen this behavior before in our logs. If it doesn't then it moves to the next one. I believe your assumption is correct - I'm going to test it out.
Thanks!
02-22-2018 06:35 PM
Hey guys, I know this is an old thread - I'm exploring this very scenario today. Wondering if things worked based on the crypto map instance sequence.
05-14-2018 07:52 AM
Hello Richard,
I know it's an old thread, but I wanted to revive and see if this would help me in my case where the subnets from a 10.204.x.x/17 IP block are spread across two locations (A and B), and there is a IPSEC connectivity between these two locations.
Location A
Subnets
10.204.47.0/26
10.204.47.64/27
10.204.47.96/27
10.204.47.128/27
10.204.47.160/27
10.204.48.0/27
10.204.48.32/27
10.204.48.64/27
10.204.105.0/24
Location B
Subnets
10.204.31.0/24
10.204.32.0/21
10.204.40.0/23
This is the current VPN ACL allowing communication between these two locations over IPSEC VPN, and it's working fine. I haven't added the other end ACLs, but the access is same.
| permit ip 10.204.47.0 0.0.0.63 10.204.31.0 0.0.0.255 |
| permit ip 10.204.47.0 0.0.0.63 10.204.32.0 0.0.7.255 |
| permit ip 10.204.47.0 0.0.0.63 10.204.40.0 0.0.1.255 |
| permit ip 10.204.47.64 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.47.64 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.47.64 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.47.96 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.47.96 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.47.96 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.47.128 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.47.128 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.47.128 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.47.160 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.47.160 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.47.160 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.48.0 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.48.0 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.48.0 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.48.32 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.48.32 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.48.32 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.48.64 0.0.0.31 10.204.31.0 0.0.0.255 |
| permit ip 10.204.48.64 0.0.0.31 10.204.32.0 0.0.7.255 |
| permit ip 10.204.48.64 0.0.0.31 10.204.40.0 0.0.1.255 |
| permit ip 10.204.105.0 0.0.0.255 10.204.31.0 0.0.0.255 |
| permit ip 10.204.105.0 0.0.0.255 10.204.32.0 0.0.7.255 |
| permit ip 10.204.105.0 0.0.0.255 10.204.40.0 0.0.1.255 |
These subnets from location A and B are all carved from a bigger IP block 10.204.0.0/17. Now, the customer wants access to 10.204.0.0/18 and 10.204.64.0/18 subnets from location A.
Can I add this statement in the ACL at location A to make it work?
| permit ip 10.204.0.0 0.0.63.255 10.204.0.0 0.0.63.255 |
| permit ip 10.204.64.0 0.0.63.255 10.204.64.0 0.0.63.255 |
Appreciate your help.
Thanks
Mikey
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide