Publishing non-Meraki site-to-site VPN 'Private subnets' into Auto-VPN.

[AndyGray]

Hi Gang

My company is half way through rolling out Meraki MXs to 200 or so branch sites, replacing the previous MPLS network, using MX68s in smaller sites, MX68 HA pairs in medium sites and MX100 HA pairs in the largest handful of sites. All sites have multiple internet links, of various types and speeds.

We always had in mind to use the beefier MXs and fast, redundant fibre connectivity in those largest sites as sort of consolidation points for onward site-to-site VPN connections to 3rd parties, including in this case our own Azure presence.

(We also have some MX250s deployed purely as VPN concentrators in our legacy datacentres, which are due to be closed by the end of this year.)

I have an MX100 configured as an Auto-VPN hub, so it has routes to all our other pure-spoke branches, as well as the datacentres via hub-meshing. That device also has a non-Meraki, IPSec site to site VPN peer in Azure - just a basic Azure VPN gateway, not an appliance or virtual MX.

But to my astonishment I can't share the route to the Azure subnet, that is present in the MX100 routing table, into Auto-VPN so other sites can access it.

I can't create a static route into the IPSec site-to-site tunnel because that insists that the next hop be layer 2 adjacent. The 'Private Subnets' setting in the non-Meraki peer config does add the route to the device routing table, but there's no option there to put it 'In VPN'

I'm aware that one workaround for this is to implement separate MX gateways for the two types of VPN and use static routing between them on local interlinks, but that seems rather wasteful and I'm bound to ask, if I had a requirement for a pure IPSec VPN appliance, why would I choose a Meraki for that?

Using vMX(es) in Azure would solve these problems, but there the limitation of 250 concurrent VPN tunnels could be a problem - our 200 sites are configured as Active-Active for Auto VPN, so we'd potentially need multiple vMXes and then have to deal with balancing our sites across them, and manage return path routing from Azure.

Has anyone run more than the nominal limit of 250 VPNs on a single vMX100?

cheers

Andy Gray

[PhilipDAth]

Aaron Willette is one of the senior Cisco Meraki technical leads.  He has a blog, but specifically the below article is where he goes through sizing appliances in much greater detail.  The VMX has been tested up to 500 concurrent VPN tunnels - so it would be a perfect solution for your issue.  This would allow all the spokes to talk directly to Azure.

https://www.willette.works/meraki-mx-sizing/ 

Another [horrible] option is to build a VPN from Azure to each spoke - but that's why we have the VMX so we don't have to do horrible things like that.

If your hubs are located with server infrastructure you could spin up some Ubuntu StrongSwan instances, and use them to build a site to site VPN to Azure, and add a static route via them into the hub and redistribute that into Azure.  We use StrongSwan a lot for terminating tunnels in AWS and Azure.  This guide has most of the details you need.

http://www.ifm.net.nz/cookbooks/meraki-vpn-to-azure.html 

[AndyGray]

Thanks for the reply, Philip, much appreciated.

The ambition is to have no inside server presence, so StrongSwan probably not an option, but I'm toying with the idea of relocating our Juniper SRXs when they're no longer required in our DCs, they would offer similar functionality.

But VMX is my preferred approach, will have a read and see if I can get all the stakeholders on board, and hopefully get some endorsement from Meraki to scale up that far - thus far they've advised us to run multiple VMXs, but that sounds like a little too much engineering to me.

thanks again

Andy