Meraki Auto VPN Explained for the 500-220 Exam
Auto VPN is the feature that lets Meraki MX appliances build IPsec tunnels between sites without you writing a single crypto map. To answer Design questions on the 500-220, you need to understand what it automates and, more importantly, where it can quietly break.
Contents
Quick summary
| Takeaway | What it means |
|---|---|
| Auto VPN is automated site-to-site IPsec | MX and vMX appliances negotiate tunnels using settings exchanged through the Meraki cloud, so you never configure phase 1 and phase 2 by hand. |
| Two topologies | You choose hub-and-spoke or full mesh per network, and the choice drives how traffic flows between spokes. |
| The VPN registry brokers the setup | A cloud registry collects each appliance's public IP, port and reachability so peers can find each other, but user data still travels directly peer-to-peer. |
| NAT traversal is the classic failure point | Symmetric NAT or restrictive firewalls stop the registry from learning a usable endpoint, and tunnels fall back or fail. |
| vMX extends Auto VPN into the cloud | A virtual MX places an Auto VPN endpoint in AWS or Azure so a data centre or cloud workload joins the same overlay as your branches. |
What Auto VPN actually automates
Traditional site-to-site VPN means manually matching IKE and IPsec parameters on both ends: encryption algorithm, DH group, lifetimes, pre-shared keys and the interesting traffic ACLs. Get one value wrong on one side and the tunnel never comes up. Auto VPN removes that entire negotiation from your hands.
With Auto VPN, each MX reports its configuration and connectivity details to the Meraki cloud. When two appliances in the same organisation are set to participate, the cloud gives each one what it needs to build an IPsec tunnel directly to the other. You enable it in Security & SD-WAN, pick a role, and the tunnels form. The exam expects you to know that this is orchestration of standard IPsec, not a proprietary transport.
What still travels peer-to-peer
A common misconception is that traffic flows through Meraki's cloud. It does not. The cloud brokers the setup; the encrypted user data goes directly between the appliances over the internet. If the internet path between two sites is down, no amount of cloud health helps that tunnel.
Hub-and-spoke versus full mesh
Auto VPN gives you two topology models, and the 500-220 Design domain leans on knowing when each applies. The model is set per network, and each MX is assigned a role.
In hub-and-spoke, you nominate one or more MX as hubs. Spokes build tunnels to the hubs but not to each other. Spoke-to-spoke traffic transits a hub. This suits designs where branches mostly talk to a data centre or where you want a central inspection or breakout point.
In full mesh (also called mesh mode), every participating appliance builds a tunnel to every other. Spoke-to-spoke traffic goes directly. This is efficient for many sites that talk laterally, but tunnel count grows with the number of sites, so it does not scale infinitely.
- Hub: a concentrator that spokes connect to; can also advertise routes to reach subnets behind it.
- Spoke: connects only to its configured hubs; relies on a hub to reach other spokes.
- Mesh: every appliance peers with every other, giving direct paths at the cost of more tunnels.
How the VPN registry brokers tunnels through NAT
The piece that makes Auto VPN work over the public internet is the cloud VPN registry. Each MX contacts the registry and reports the public IP address and UDP port it is reachable on, plus its local subnets and the type of NAT it sits behind.
When peers need to connect, the registry hands each one the other's endpoint details. Because both sides learn each other's public IP and port from a trusted source, they can initiate the tunnel without static configuration and without one side needing a fixed public address known in advance. This is how two branches, each behind a dynamic-IP broadband connection, can still mesh.
The registry has to reconcile NAT. If an MX is behind a friendly NAT, the registry learns a consistent external IP and port that the peer can use. Understanding this hand-off is what lets you reason about the failure modes below.
The failure modes the exam cares about
Design questions rarely ask you to praise Auto VPN; they ask what breaks it. These are the situations to recognise.
Symmetric NAT and unfriendly firewalls
If an appliance sits behind symmetric NAT, the external port it uses toward the registry differs from the port a peer would need, so the endpoint the registry learned is not usable for the peer. Deep packet inspection firewalls or those blocking the UDP ports Auto VPN uses cause the same outcome: the registry has details but the direct tunnel cannot establish. Placing the MX with a public IP, or ensuring the upstream firewall allows the required outbound UDP, resolves this.
Overlapping subnets and route advertisement
Auto VPN routes based on the local subnets each appliance advertises into the overlay. If two sites advertise the same subnet, the overlay cannot route deterministically and connectivity to that subnet becomes ambiguous. Plan non-overlapping addressing across all sites that share an Auto VPN.
Hub reachability in hub-and-spoke
In hub-and-spoke, a spoke depends on its hub for anything it cannot reach directly. If the hub is unreachable, spoke-to-spoke communication that transits that hub stops even when the spokes themselves are healthy. Redundant hubs address this.
When a vMX makes sense
A vMX is a virtual MX appliance you deploy in a public cloud such as AWS or Azure. It participates in Auto VPN exactly like a physical MX, which means it becomes an Auto VPN endpoint inside your cloud environment.
The design case is straightforward: you have workloads in a cloud VPC or VNet, and you want your branches to reach them over the same encrypted overlay rather than building separate VPN connections. Deploy a vMX as a hub, advertise the cloud subnets, and your spokes reach cloud resources the same way they reach a physical data centre. It is not a fit when you only need branch-to-branch connectivity with no cloud presence; the physical MX estate handles that alone.
Auto VPN topology and role comparison
| Aspect | Hub-and-spoke | Full mesh |
|---|---|---|
| Tunnel pattern | Spokes tunnel to hubs only | Every appliance tunnels to every other |
| Spoke-to-spoke traffic | Transits a hub | Direct between appliances |
| Central control point | Yes, at the hub | No single choke point |
| Tunnel count | Lower, scales with hubs | Grows with number of sites |
| Typical fit | Branches to data centre or central breakout | Many sites with lateral traffic |
Try CMSS Professor
CMSS Professor uses an original Dashboard-style simulator to rehearse selected Auto VPN decisions without a licensed organization. It does not reproduce live behavior, and its practice estimate is not an exam prediction. Inspect the free public preview before choosing one-time access.
Frequently asked questions
Does Auto VPN send my traffic through the Meraki cloud?
No. The cloud registry only brokers the tunnel setup by sharing endpoint details. The encrypted user data travels directly between the appliances over the internet.
What happens if an MX is behind symmetric NAT?
The external port seen by the registry may not match what a peer needs, so the direct tunnel can fail to establish. Giving the MX a public IP or adjusting the upstream firewall usually resolves it.
Can I mix hub-and-spoke and full mesh?
Topology is set per network and each MX has a role, so different networks in one organisation can use different models. Plan roles deliberately around where traffic needs to flow.
What is a vMX used for in Auto VPN?
A vMX is a virtual MX in a public cloud that joins Auto VPN as an endpoint, letting branches reach cloud workloads over the same overlay they use for physical sites.