Summary: Explains how the Meraki cloud-hosted VPN registry acts as the AutoVPN control plane, how hubs and spokes register and learn routes from each other, and what the dependency on the registry means during cloud outages.
Meraki AutoVPN does not use dynamic routing protocols between MX devices. There is no BGP, OSPF, or EIGRP running over the tunnels. Instead, all route distribution is driven by a centralised cloud-hosted database called the VPN registry. Every MX participating in AutoVPN registers its own subnets and learns its peers' subnets from this registry. The registry is the control plane; the IPsec tunnels are the data plane.
When an MX is configured for AutoVPN, it establishes an outbound connection to the Meraki cloud over TCP 443 and registers the following:
When an MX sits behind NAT, the cloud captures the NATted public address from the incoming connection, so peers receive the correct reachable IP rather than the MX's private interface address.
Any change made in the dashboard — adding a subnet, changing the WAN IP, altering hub priority, switching VPN role — triggers a registry update. That update is then distributed to the MX's peers, typically propagating within seconds to a few minutes.
Route learning for spokes is entirely registry-driven:
The spoke does not run any routing protocol over the tunnel to receive these routes. The registry entry is the sole source of truth for what subnets the hub owns and how to reach it.
Hubs learn spoke routes by the same mechanism in reverse. When a spoke registers, its local subnets are published to the registry and distributed to each hub the spoke is configured to use. The hub installs those subnets as routes pointing into the spoke's tunnel and establishes the IPsec tunnel back to the spoke's registered public IP.
This means subnet changes at either end propagate without any manual tunnel reconfiguration. Adding a new VLAN at a spoke site, for example, triggers a registry update that the hub downloads and installs automatically.
Hubs in the same organisation also establish tunnels with each other — the hub mesh. This follows the same registry model: Hub A learns Hub B's subnets from the registry, installs them as routes, and establishes a direct tunnel.
The important constraint is that each MX only publishes its own locally configured subnets to the registry. Hub A does not re-advertise Hub B's subnets into the registry on Hub B's behalf. As a result:
This non-transitivity is a fundamental property of how the registry works, not a tunnel or routing configuration issue. It is covered in detail in KBA-041 - Meraki AutoVPN — Spoke Site Failover and Non-Identical Route Tracking.
The registry tells each MX what peers exist and what subnets they own. It does not determine whether a peer is currently reachable. Liveness is handled separately, peer-to-peer, via IKE Dead Peer Detection (DPD). Each MX sends DPD hellos over the established tunnel; if a peer stops responding, the local MX marks that tunnel down and deactivates the corresponding routes.
The registry and DPD serve distinct functions:
When a tunnel goes down by DPD, the spoke deactivates the routes it learned from the registry for that hub and fails over within the same prefix group (see KBA-041).
The registry is hosted entirely in the Meraki cloud. This creates a layered dependency model.
| Protocol | Port | Purpose |
|---|---|---|
| TCP | 443 | MX to Meraki cloud — registry updates, dashboard, config push |
| UDP | 500 | IKE negotiation between MX peers (no NAT) |
| UDP | 4500 | IKE/IPsec with NAT traversal (NAT-T) |
UDP 500 and 4500 must be permitted outbound from each MX WAN interface and must not be blocked between peer MX public IPs.