07-21-2019 11:13 AM - edited 02-21-2020 09:42 PM
Hi guys,
Please see the attached diagram. This is the network setup of one of our customers. All sites use Cisco ASA firewalls. They have an existing VPN to site A with multiple subnets & variable subnet masks. I've only shown a small number of subnets. They would like us to set up a new VPN to site B as shown. The subnets from site A and site B do not overlap. The issue is that the configuration at HQ was set up as 10.0.0.0/8 to cover all of the site A subnets and this is currently working as things stand. However, if I add site B with the 10.99.1.0 subnet, I'm concerned that VPN A is already configured to carry subnets in the range 10.0.0.0/8 and therefore traffic will never be sent down new VPN B. Is this the case, or will VPN B come up and carry 10.99.1.0/24 traffic because it is a longer match?
Thanks.
Solved! Go to Solution.
07-26-2019 07:10 AM
kane,
Make sure the crypto map for VPN-B carrying 10.99.1.0/24 has a lower sequence nos than VPN A carrying 10.0.0.0/8. Please don't make these changes while in production. you will need to disconnect the VPN, make the change and then initiate it again.
Let me know if that works.
Regards
Shikha Grover
PS: Please don't forget to rate and select as validated answer if this answered your question
07-21-2019 12:12 PM
Hi,
I assumed you are using an ASA. Yes, this should work. It will match the more specific network (10.99.1.0/24) and establish a tunnel, it will also establish a tunnel to the longer 10.0.0.0/8 network. Here is an example, which indicates successful IKEv2 SAs established for this exact scenario.
ASA-1(config-network-object)# show crypto ikev2 sa
IKEv2 SAs:
Session-id:14, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
29491833 1.1.1.1/500 2.2.2.1/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/4 sec
Child sa: local selector 10.10.1.0/0 - 10.10.1.255/65535
remote selector 10.2.0.0/0 - 10.2.3.255/65535
ESP spi in/out: 0x77490ae9/0xefb5c662
IKEv2 SAs:
Session-id:13, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
28881729 1.1.1.1/500 3.3.3.1/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/12 sec
Child sa: local selector 10.10.1.0/0 - 10.10.1.255/65535
remote selector 10.0.0.0/0 - 10.255.255.255/65535
ESP spi in/out: 0x85cde1aa/0x16108e69
HTH
07-22-2019 02:21 AM - edited 07-22-2019 02:24 AM
Edited
07-22-2019 02:21 AM - edited 07-22-2019 08:20 AM
Hi,
Thanks for your response. I am unable to get the tunnel to come up when I ping from HQ to Site B 10.99.1.0/24. I added a test subnet (172.16.1.0/24) at site B and was able to bring the VPN up by pinging this test subnet. However, pings are still failing to the 10.99.1.0/24 subnet. When I shut VPN A down, I can successfully ping 10.99.1.0/24 at site B. This obviously is not an acceptable solution. A packet capture at Site A shows that when both tunnels are up, traffic destined for 10.99.1.0/24 is received over VPN A even though 10.99.1.0/24 is configured as a more specific subnet over VPN B. Is there any Cisco documentation that states how the ASA decides which VPN to send traffic down when VPN A contains 10.0.0.0/8 while VPN B contains 10.99.1.0/24?
07-22-2019 08:41 AM
07-26-2019 02:06 AM
Hi,
The management won't allow me to upload any configs. However, someone else suggested that for IPSec VPNs, the shorter subnet mask takes priority over a longer mask. This is opposite to the standard routing decisions made by a layer 3 device.
So if VPN-A carries 10.0.0.0/8 and VPN-B carries 10.99.1.0/24, traffic for 10.99.1.1 would be carried over VPN-A. Anyone know if there is any documentation that confirms this? This is certainly the behaviour that I am seeing.
07-26-2019 07:10 AM
kane,
Make sure the crypto map for VPN-B carrying 10.99.1.0/24 has a lower sequence nos than VPN A carrying 10.0.0.0/8. Please don't make these changes while in production. you will need to disconnect the VPN, make the change and then initiate it again.
Let me know if that works.
Regards
Shikha Grover
PS: Please don't forget to rate and select as validated answer if this answered your question
08-12-2019 08:41 AM
Hi,
That is exactly what the issue was! The crypto map entries for the more specific subnets needed to be higher up in the list.
Thanks very much!
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