Meraki Auto-VPN over MPLS

Here’s a quick review of a recent Meraki MX deployment I wrapped up this week. The customer has 4 sites across Canada; one HQ with an Internet and MPLS connection, and 3 branches with only MPLS connections. We replaced their aging Juniper SSGs with MX65s.

Here’s the basic topology:

The branch MXs reach the cloud controller through the HQ internet connection – internet connections are a requirement for running the Meraki gear; but it doesn’t have to be local. The branch MX uplink ports are connected to the MPLS cloud. At HQ, the MPLS cloud connects to a LAN port – keep this in mind.

Of course, site-to-site connectivity was required. Each site has two internal subnets/VLANs: one data, one voice. Simple enough right? Auto-VPN to the rescue!

Turn on VPN at each site – we want full mesh, so every site is a hub. Then advertise the two local subnets into the VPN cloud at each site:

Done. Simple. Result:

Fancy green lines mean successfully established VPN connectivity! Auto-VPN is smart enough to realize that each branch/spoke appears on the internet at the same IP, but that the locally set uplink addresses are all reachable from spoke to spoke, so those VPNs form without a problem. But this is not what we wanted. Spoke-to-spoke traffic is good for voice calls, but all of our servers (including the call manager) are at HQ… and there are no fancy green lines to HQ.

What is going on? Well I can’t say with 100% certainty what exactly the limitation is, but I know one thing about the Meraki MX and VPNs – they won’t establish VPN SAs over non-uplink ports.

There are also some limitations with hairpinning – in this case, in order to establish an SA with the HQ uplink (Internet) port, the branches would need to exit the HQ uplink port, and do a 180° turn to form an ISAMKP SA. I have some intel that says Meraki has tested this feature, but I can’t say when it will be deployed to customers.

So in the meantime, we need another solution – and Meraki has just the feature.

Remember VPN concentrators?

We can put in another MX at the HQ in VPN concentrator mode. It’s a normal MX (in this case an MX64 because we only need the one port). We connect the uplink to another LAN port on the HQ MX, in this case, we gave it a separate subnet.

We can only use the uplink port on the MX when it is in this mode, and then it will serve as a dedicated hairpinning interface, effectively putting that uplink interface inside the HQ LAN.

When we do this, the VPN settings page changes. On the concentrator, we manually specify the subnets at HQ that should be reachable over the VPN:

No routes required – the concentrator will send everything to it’s own default gateway, which in this case is the HQ MX, where both these subnets are homed.

We then turn OFF the VPN at the HQ MX, and create static routes on the HQ MX pointing to the concentrator.

The new result:

Now we have fancy blue lines showing the VPNs between the branches and HQ, resulting in a full mesh.

Rumor has it that we’ll see two improvements in these deployments sometime in the near future – the ability to use the second uplink port without an internet connection to terminate VPNs, as long as the primary uplink can reach the cloud controller; and the ability to hairpin out the uplink as I mentioned earlier. Either of these should have replaced the need for a dedicated concentrator.

In the meantime, here’s the Meraki deployment guide for the VPN concentrator role: