non-meraki vpn peer subnets overlap with meraki hub auto vpn

[eye]

Site A = MX hub

Site B + C = MX spokes

...

Site X + Y = MX "hubs" with only ipsec tunnels to a non-meraki vpn peer via tags in the site to site vpn page Availability column.  No meraki peers connect through these. 

Without creating separate organizations or full tunnel default routing, is there a way for identical or overlapping subnets to coexist in Site A's advertised routes and Private Subnets configured for tagged non-meraki vpn peers used by X & Y?

[PhilipDAth]

You'll be able to create the non-Meraki VPN using whatever subnets you want.

However the routing table will control where to send traffic.  If site 'A' is advertising a subnet via AutoVPN to site 'X', then site 'X' will send traffic for that subnet to site 'A' rather than any remote non-Meraki VPN.

You will need to stop advertising into AutoVPN any subnets that you want site 'X' and 'Y' to be able to access over their non-Meraki VPN.

[JonathanSwitch]

I agree with @PhilipDAth. Due to the MX's route priority defined here: https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#Route_Priority any time traffic leaves X & Y toward a subnet that belongs to both site A and a non-meraki peer, it will always send it toward the site A. Removing the advertised subnets would be the only option depending on where you need traffic to flow.

The only possible work around for this that I could come up with would be to attempt enabling vpn subnet translation for site A to a different subnet to be advertised into Auto VPN. I'm not 100% sure if this would work, and it may cause other unexpected issues. Here's the documentation for it: https://documentation.meraki.com/MX/Site-to-site_VPN/Using_Site-to-site_VPN_Translation and it would have to be enabled via support. 

I would recommend testing the above during a maintenance window though.

[eye]

nat'ing the Site A MX hub subnets would create more problems than it solves in this environment so won't be an option but the feedback is appreciated.  It's odd that non-Meraki vpn peering can be defined/restricted with tags while Meraki Auto vpn peering seemingly can't, yet the "hub" type selection which opens Auto vpn is also the only option for establishing non-Meraki vpn tunnels.  

[rhbirkelund]

While it's true that you cannot restrict which sites should join AutoVPN cloud with tags, you still have the possibilty to configure which subnets should be Enabled for VPN. 

So eventhough you cannot configure a Site to not do AutoVPN peering, you can simply disable all the sites subnets in AutoVPN. That way, no subnets will be advertised from that site.

[eye]

The hub subnets in this case still need to be advertised to the other MX's which should participate in Auto VPN.  The "hub" (spoke) vpn subnets also need to be enabled for the ipsec with non-meraki peers.  There are a handful of MX's in the organization which only connect to non-meraki peers in Site A and another site via ipsec tunnel with some identical subnets required between the Auto VPN MX hub and non-meraki ipsec peers.  The lack of Auto VPN opt out without also disabling ipsec with non-meraki peers could mean placing MX's in separate organizations is the only solution.