Non-Meraki VPN - Subnet Conflict

[GuiCarvalho]

Hello Team,

.

We have a VPN non-meraki with the remote subnet as 192.168.0.0/16. This VPN is working fine.

But now, we need to create another non-meraki vpn with a different customer, but in this case, the remote subnet is 192.168.20.0/24.

So, when I apply the new Tunnel, the old one failed (close the tunnel). I think it occurs because the remote subnet for VPN 2 (New), is included in the remote subnet range for VPN 1 (old).

Is there a way to workaround it?

[BlakeRichardson]

@GuiCarvalho  I am assuming you you are talking about site to site VPN and not client vpn?

If so how have you configured you MX? as a hub or spoke?

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings

Also how have you configured your static routes?

[GuiCarvalho]

@BlakeRichardson ,

That is correct, I'm talking about a VPN Site-to-Site between Meraki and 3rd Party.

The MX is configured as HUB, but I'll need to create tunnels for some Spokes too.

[AlexP]

We have to close existing tunnels when non-Meraki VPN is reconfigured on Dashboard because of how the ipsec process we use needs to be reconfigured internally.

This is likely going to be hard to make work however, because non-Meraki VPN is policy-based; if we get a packet bound to 192.168.20.0/24 when a tunnel to the remote with 192.168.0.0/16 as a subnet is defined, it will match on the existing policy; there aren't considerations for longest-prefix matching in this context.

[GuiCarvalho]

@AlexP ,

Thanks for the information.

So, if a NAT is created in the customer side, and I point the NATed address as remote subnet, it will work?

For example, translating (in the customer side) 192.168.0.0/16 to 172.16.0.0/16, and configure the remote subnet for VPN 1 as 172.16.0.0/16.

[AlexP]

Yes, that'll work

[GuiCarvalho]

@AlexP , thank you very much.

I'll ask the customer to do a NAT for their subnets and post here the results.

[GuiCarvalho]

@AlexP ,

I think that the problem is other.

I have informed a wrong ranges in this topic.

The correct remote range for the VPN 1 is 10.0.0.0/16 and the new second vpn is 10.10.0.0/24. So, in this way, I think there is not an IP overlaps.

So, the sympthon is the same. When we configure VPN 2, the VPN 1 goes down and just become UP when I delete the VPN 2.

Do you all have any clue about what can be the cause to this problem?

[PhilipDAth]

It is unlikely that the remote side using 192.168.0.0/16 really needs to use 192.156.0.0/16.  Ask them if they can narrow the scope of something smaller.

[GuiCarvalho]

@PhilipDAth ,

Thank you for your suggestion.

First, I'll ask the customer to NAT their subnets, as I was talking with AlexP. If it's not a option for the customer, I'll ask them to narrow the subnet range.

[GuiCarvalho]

@PhilipDAth ,

As I just informed to AlexP, the ranges tha I posted in this topic is incorrect.

The correct remote range for the VPN 1 is 10.0.0.0/16 and the new second vpn is 10.10.0.0/24. So, in this way, I think there is not an IP overlaps.

But, we still have the problem for VPN 1 going down when we configure the VPN 2, until we delete the VPN 2 config.

[AlexP]

That would be the sort of thing you should open a Support case over then; ideally try to demonstrate the problem as it happens to them, so that logging can be collected as it occurs to determine the cause of the conflict.