I was working on large Meraki MX VPN deployment project recently and was asked to explain a common theme I’ve had to give guidance on time and time again with customer VPN designs – how do you integrate non-Meraki VPN peers with an existing AutoVPN domain? Well, this is one of those topics that requires a little more detailed explanation and this seemed like a perfect place to unpack it.
How do the two VPN solutions work and what are ways we can cleanly merge the two together?
AutoVPN, the MX Killer App
I think it’s important to start the conversation with a quick review of the Meraki AutoVPN architecture. For those that haven’t had a chance to see it in action, AutoVPN is Meraki’s cloud-provisioned VPN method for peering MX firewalls.
If you’ve ever had to manually build site-to-site VPN tunnels between two devices, then AutoVPN appears to be black magic to the general observer. It’s absurdly simple to configure. So simple in fact, that it’s been the benchmark for the fastest VPN to provision in the industry for nearly a decade.
Click hub or spoke, pick your local networks or VLANs you want to advertise from the dropdown and click save. The cloud controller orchestrates all the rest.
The best part is that’s just the foundation. With MX SD-WAN multipathing and app-based routing layered on top, it really has matured into a powerful, elegant software-defined WAN overlay solution for enterprise connectivity.
Non-Meraki IPSec VPN Peers
AutoVPN really is an incredible technology that radically simplifies the operational complexity of VPN provisioning. But as cool as the MX appliances are, not every VPN destination is terminated by a Cisco MX. So what’s the universal site-to-site peering protocol of the internet? IPSec.
The Meraki MX security appliance supports the industry standard IPSec stack for this very reason – building site-to-site VPNs to remote peers.
The configuration for non-Meraki IPSec VPN peers in Dashboard can be found under Security Appliance > Configure > Site-to-site VPN > Non-Meraki VPN peers.
IPSec VPNs use a two phase security exchange to authenticate the two peers. More information on how to properly configure those parameters can be found here as well as additional information on troubleshooting error conditions.
When You Need Both
Most companies with MX appliances prefer the cloud-orchistrated benefits of an AutoVPN architecture. Once you experience the simplicity, it’s hard to go back.
It’s also common for many companies with an investment into the MX platform to still require traditional IPSec site-to-site VPN connections to remote third parties. I see this most common in the healthcare and financial markets, but it’s frequently used in secure B2B processing or remote services needs in almost every industry.
So, no problem. MX supports both AutoVPN and non-Meraki IPSec VPN domains. Just use both where required.
I wish it were that simple. There are several important considerations to be aware of when trying to route traffic between AutoVPN and non-Meraki VPN destinations.
Notice that last point. Having the flexibility to terminate both VPN solutions on the same MX VPN hub is great, but you can quickly see that the two aren’t routable between each other.
This is especially problematic if you have a headend MX concentrating remote IPSec VPNs and need reachability to those third-party services from a branch office.
Not ideal, but fear not. With a little creativity (and one extra MX appliance) we can share route information between the two VPN domains – even with overlapping subnets.
Integrating Non-Meraki VPNS into AutoVPN
Fundamentally we have two major problems to overcome when combining the technologies.
- Non-Meraki VPN routes are not advertised to AutoVPN peers.
- Remote non-Meraki VPN subnets cannot overlap with any existing Dashboard subnets/routes. This won’t be a problem for most situations, but quickly becomes a sticking point if your IPSec remote routes happen to conflict with internal Dashboard subnets.
The diagram below depicts the challenge. This shows a single organization with a primary MX hub appliance. The hub, often positioned as a corporate firewall or data center VPN appliance terminates internal AutoVPN connections to remote branch sites as well as third-party VPN peers.
The hub can successfully connect to both, but cannot advertise the IPSec peer routes to the AutoVPN MX spoke sites. This means the branches (spokes) will not have reachability to the non-Meraki S2S VPN peer resources.
To solve this, we’ll need to rethink how each VPN service is terminated. If we move all of the non-Meraki VPN termination to a separate MX appliance, in a separate organization, and advertise VPN routes between the two MX hubs then both problems disappear.
Sound overly complicated? And we need more hardware? Hang with me – it’s actually relatively simple and more integrated than it might first appear.
Putting The Pieces Together
The simplest way to bridge the two VPN solutions is to first provision a new, non-Meraki VPN organization where a dedicated third-party VPN MX appliance will live. This new MX is configured as a hub and will peer directly with all non-MX VPN sites.
The new MX hub should be colocated with the primary MX hub – sharing a common LAN subnet either through a switch or directly connected.
Why the need for a separate org? Putting the third-party VPN MX into its own org will allow for overlapping VPN subnets since it has no visibility into the AutoVPN organization. No visibility means no Dashboard validation problems.
In this design we have a dedicated third-party VPN org and MX (shown on the far left), but we still don’t have route reachability between the two MX hubs.
To inject VPN routes between the two MX hubs, static summary routes can be used.
Non-Meraki VPN Hub
The non-Meraki VPN hub will be configured with one or more static routes for the AutoVPN supernets (with a next hop of the AutoVPN hub).
Primary Org’s AutoVPN Hub
The AutoVPN hub in the main org will be configured with one or more static routes for the third-party VPN destinations (with a next hop of the non-Meraki VPN hub). This tells the AutoVPN hub where to forward third-party VPN destination traffic, but also advertises those third-party VPN routes into the route table of remote spoke MX appliances.
Step 1: Create a New, IPSec VPN Only Organization
- Open a new browser session and navigate to dashboard.meraki.com
- Click on Create an account
- Fill in the fields presented – being careful to use the same company email address and password used in your existing primary organization. This will enable toggled access between the Dashboard organizations using the same login.
- Click the Create account button once all the required information is properly entered.
Step 2: Claim the Non-Meraki VPN Hub MX & Create Network
- In the new non-Meraki VPN organization, claim the new MX hardware using serial number or order number.
- Add the newly claimed MX appliance to a new network.
Step 3: Configure the Non-Meraki IPSec VPNs
- Navigate to Security Appliance > Configure > Site-to-site VPN page and set the Type to Hub.
- Scroll down to Organization-wide settings > Non-Meraki VPN peers and click Add rule.
- Enter the IPSec parameters required. Once configured, allow at least 60 seconds for the VPN negotiation process to complete.If you have trouble getting the tunnel operational, the Event log under the Network-wide menu should give you clues. This VPN troubleshooting KB is also a good troubleshooting resource.
Step 4: Add VPN Routes on Both Hubs
We’ll use the diagram below as a reference in adding the appropriate routes to both MX hubs. The web services and storage destinations at the top show the remote IPSec VPN targets our AutoVPN domain needs to reach. The spoke branch locations connected over AutoVPN are represented by a 10.100.0.0/16 supernet. Production branch deployments may not roll up so nicely into a single IP route, but the application below is the same.
At this point the assumption is that the IPSec tunnels have been successfully established between the non-Meraki VPN hub MX and the third party site-to-site peer. If not, revisit step three above before proceeding.
- On the non-Meraki VPN hub MX (lower left), configure a new VLAN interface for inside connectivity to the primary MX hub. This should be a common VLAN subnet shared by both appliances. In this example we’ll use 10.0.0.0/24. Next set the local LAN port to type access and set to the inside VLAN that was just created.
- When a new VLAN interface is created on an MX it automatically enables DHCP services for the subnet. DHCP should immediately be disabled on the non-Meraki VPN hub appliance to prevent client gateway mismatch issues.
- Verify reachability between the hub appliance inside interfaces by performing a ping from the local status page to the other hub’s inside VLAN interface.
- On the primary hub MX (center in diagram above), create a static route for the remote IPSec VPN destinations with a next hop set to the inside IP address of the non-Meraki VPN hub.
- On the non-Meraki VPN hub MX (left in diagram above), create a static route for the AutoVPN domain destinations (10.100.0.0/16) with a next hop of the primary MX hub inside IP address. Essentially repeating the previous step in the reverse direction.
Step 5: Verify Bidirectional Hub Reachability
- On the non-Meraki VPN hub MX network, navigate to Security Appliance > VPN status > non-Meraki peer and verify that the third-party VPN shows up (green).
- On the non-Meraki VPN hub MX network, navigate to the Security Appliance > Appliance status page. Select the Tools tab from the top menu and enter an IP that should be reachable behind the remote IPSec VPN peer. Start the ping tool to test connectivity.Repeat the previous ping test from the primary hub appliance. This will validate the local routing between MX hubs on the inside segment.
Step 6: Verify IPSec VPN Reachability From Spoke Nodes
Now that we have validated reachability to the IPSec VPN destinations from the primary MX hub, its important to extend our testing to the AutoVPN spoke nodes. This will test our connectivity end-to-end across both organizations and VPN domains.
The test above demonstrates the process from a Z3 teleworker appliance that’s participating in the AutoVPN domain and in the primary organization. If the pings to the IPSec destinations fail, double-check that the remote, non-Meraki IPSec VPN peer has the primary org’s AutoVPN subnets included in its interesting traffic list.
The Framework is Flexible. Be Creative.
If you need to merge non-Meraki IPSec VPN tunnels into a Meraki AutoVPN architecture, you now have a solution to do so without limitation. My guidance would be to use the power of AutoVPN’s cloud orchestration wherever possible and bridge in standalone IPSec tunnels to third-party peers only when an MX appliance can’t be used.
The solution presented in this writeup was focused on extending third-party VPN reachability to AutoVPN branch nodes, but the framework can be applied to other use cases and topologies. Need to add reachability to a new acquisition’s locations that also run MX AutoVPN, but uses a separate organization? Have some international locations that require non-Meraki VPN peering to existing CPE firewalls? Consider the principles and connectivity model outlined above and adjust to meet the needs of your specific project.
Thinking in terms of architecture limitations rarely produces the best outcomes. Instead, recognize the strengths (simplicity, flexibility, etc) of each element and combine them in smarter ways. With that in mind, go and build some interesting Meraki MX VPN designs.