Meraki Auto VPN Configuration Settings

Licensing requirements 

• Cisco Secure Routers, MX and Z-series devices use a per-device licensing model, where each device requires a corresponding license in the Meraki dashboard  

• There are three license tiers such as Enterprise, Advanced Security, and Secure SD-WAN Plus  

• Auto VPN functionality is included as part of the MX and Z-Series feature set and does not require a separate license  

• Auto VPN can operate between MX and Z-Series Teleworker with supported license configurations, depending on the organization’s licensing model 

Hardware requirements 

• All MX and Z-Series models support Auto VPN 

Limitations 

• Auto VPN requires connectivity to the Meraki cloud to establish and maintain VPN tunnels 

• Upstream firewalls must allow outbound UDP ports 9350–9381 for Auto VPN registry communication 

• Network conditions such as restrictive NAT or firewall policies may prevent VPN tunnels from forming. In such situations, a manual upstream port forward to the MX may be required. Refer to  NAT Traversal section down below. 

Type

There are three options for configuring  MX and Z-series devices in the Auto VPN topology:

• Off: The MX and Z-series devices does not participate in Site-to-Site VPN 
• Hub (Mesh): The MX and Z-series devices establishes VPN tunnels to all remote Meraki VPN peers configured in Hub (Mesh) mode.  The device also establish VPN tunnels to other MX and Z-series appliances in hub-and-spoke mode, where the other MX and Z-series device configured as a hub.
• Spoke: The MX device establishes VPN tunnels only to the specified hub devices. Other spokes are reachable through their respective hubs unless restricted by site-to-site firewall rules.  If the majority of WAN Appliances in the Auto VPN domain are configured as Spoke with only a few key locations (such as data centers or headquarters) configured as hubs, then the Auto VPN environment has a hub-and-spoke topology.

Tunneling

There are two tunneling modes available for MX and Z devices configured as a Spoke: 

• Split tunnel (no default route): By default all WAN Appliances in the Auto VPN domain (dashboard organization) will only send traffic to an Auto VPN peer if the traffic is destined for a subnet contained within the Auto VPN domain. This is often referred to as 'split-tunnelling,' meaning that VPN-subnet-bound traffic is sent over VPN, and other traffic is routed normally via the primary WAN Appliance WAN uplink. If an organization wants to route all traffic (including traffic not contained within the Auto VPN domain) through a specific hub site, this is referred to as 'full-tunneling.' Full-tunneling only affects client data and all Meraki management traffic will egress directly via the primary WAN regardless. 

To configure full-tunneling in a full mesh topology simply define an Exit hub from the WAN Appliances in the Auto VPN domain.

Send only site-to-site traffic, meaning that if a subnet is at a remote site, the traffic destined for that subnet is sent over the VPN. However, if traffic is destined for a network that is not in the VPN mesh (for example, traffic going to a public web service such as www.google.com), the traffic is not sent over the VPN. Instead, this traffic is routed using another available route, most commonly being sent directly to the Internet from the local MX and Z-series device. Split tunneling allows for the configuration of multiple hubs. 

• Full tunnel (default route): To configure full-tunneling in a hub-and-spoke topology, simply associate a ‘Default route’ with one or more hub WAN Appliances. 

The configured Exit hub(s) advertise a default route over Auto VPN to the spoke MX and Z series device. Traffic destined for subnets that are not reachable through other routes will be sent over VPN to the Exit hub(s). Exit hubs' default routes will be prioritized in descending order. 

Full tunneling only affects client data, and Meraki management traffic will continue to use the WAN uplink directly. 

Concentrator priority

The concentrator priority determines how appliances in Hub (Mesh) mode will reach subnets that are advertised from more than one Meraki VPN peer. Similarly to hub priorities, the uppermost concentrator in the list that meets the following criteria will be used for such a subnet. 

A) Advertises the subnet 

B) Currently reachable via VPN 

It is important to note that concentrator priorities are used only by appliances in Mesh mode. An appliance in hub-and-spoke mode will ignore the concentrator priorities and will use its hub priorities instead. 

NAT traversal

If the MX and Z-series device is behind a firewall or other Network Address Translation (NAT) device, there are two options for establishing the VPN tunnel: 

• Automatic: In most cases, the MX and Z-series device can automatically establish site-to-site VPN connectivity to remote Meraki VPN peers even through a firewall or NAT device using a technique known as "UDP hole punching". This is the recommended (and default) option. 

• Manual: Port forwarding: If the Automatic option does not work, you can use this option. When Manual: Port forwarding is enabled, Meraki VPN peers contact the MX and Z-series device using the specified public IP address and UDP port number. You will need to configure the upstream firewall to forward all incoming traffic on that UDP port to the IP address of the MX and Z-series device. 

Make sure the port number you have chosen is not already used by another service. For example, do not use port 500 or 4500 as these are used for Client VPN and 3rd party VPN peer communication.

Local networks

If you have multiple LAN subnets, you can specify which VLANs and static routes participate in the VPN. 

Select Enabled under VPN Mode to define which locally defined or available subnets are to be exported to the Auto VPN domain. 

The same subnet can be advertised from more than one WAN appliance only if all advertising WAN appliances are in Passthrough or VPN Concentrator mode. 

All subnets advertised from a WAN appliance in Routed mode must be unique within the Auto VPN topology. 

Subnets to which the MX and Z-series device have Static LAN routes can also be advertised over the VPN. If you choose to advertise a statically routed subnet over the VPN, ensure that the gateway device for each subnet is configured to route traffic for remote VPN subnets to the MX and Z-series device, to keep your routing symmetrical. 

Subnets to which the MX-Z device has Static LAN routes can also be advertised over the VPN. If you choose to advertise a statically routed subnet over the VPN, ensure that the gateway device for each subnet is configured to route traffic for remote VPN subnets to the MX-Z device, in order to keep your routing symmetrical.

In full tunnel configurations when specifying a prefix to be part of a VPN, everything covered by that prefix will be allowed in the VPN. Therefore, subnets that overlap will cause traffic in a more specific subnet to be sent through the VPN, even if it is not configured to be included in the VPN. For example, if 10.0.0.0/16 is configured to be included in the VPN but 10.0.1.0/24 is not, traffic sourced from 10.0.1.50 will still be sent over the VPN.

VPN subnet translation

This feature is only supported for Auto VPN and is not intended to work with IPsec VPN peers.

In large distributed networks, multiple networks may have identical subnet scopes (for example, overlapping subnets). Site-to-site VPN requires unique and non-overlapping subnets. If multiple locations have the same local subnet, enable VPN subnet translation to translate the local subnet to a new subnet with the same number of addresses. For more information, refer to the

 Using Site-to-site VPN Translation article. 

Subnet Translation Example

• Branch 1 local subnet: 192.168.31.0/24
• Branch 2 local subnet: 192.168.31.0/24 (identical!)
• Branch 1 translated subnet: 10.0.1.0/24
• Branch 2 translated subnet: 10.0.2.0/24

In the example above, even though both networks have identical local subnets, they can communicate over the VPN using their translated VPN subnet. Branch 1 is accessible as 10.0.1.0/24 and Branch 2 is accessible as 10.0.2.0/24 over the VPN tunnel.

 

Open shortest path first (OSPF) route advertisement

As part of MX 18.1 firmware updates we are introducing a new Routing page, more details found in the "OSPF Configuration" section of the IPv6 Support on MX Security & SD-WAN Platforms - Routing article.

While the WAN Appliance does not currently support full OSPF routing, OSPF can be used to advertise remote VPN subnets to a core switch or other routing device, avoiding the need to create static routes to those subnets. OSPF advertisement is supported in VPN Concentrator mode or in Routed mode on MX 13.4+ firmware with VLANs disabled. 

Advertise remote routes: If this is set to Enabled, OSPF will be used to advertise remote VPN subnets as reachable via this MX. 

Router ID: The OSPF Router ID that this MX will use to identify itself to neighbors. 

Area ID: The OSPF Area ID that this MX will use when sending route advertisements. 

Cost: The route cost attached to all OSPF routes advertised from this MX. 

Hello timer: How frequently the MX  will send OSPF Hello packets. This should be the same across all devices in your OSPF topology. 

Dead timer: How long the MX will wait to see Hello packets from a particular OSPF neighbor before considering that neighbor inactive. 

MD5 Authentication: If this is enabled, MD5 hashing will be used to authenticate potential OSPF neighbors. This ensures that no unauthorized devices are injecting OSPF routes into the network. 

Authentication Key: The Message Digest Algorithm 5 (MD5) key number and passphrase. Both of these values must match between any devices that you wish to form an OSPF adjacency. 

WAN appliances in Routed mode only support OSPF when using the "Single LAN" LAN setting. This can be set on Addressing & VLANs page.

VPN firewall rules 

To configure VPN firewall rules, navigate to the appropriate settings under Security & SD-WAN. These rules control what traffic is allowed to pass through the VPN tunnel and apply to outbound VPN traffic to and from all MX and Z-series WAN appliances in the organization that participate in site-to-site VPN, including outbound IPsec VPN peer tunnel and related BGP control traffic.  

Firewall rules will not apply to inbound traffic or to traffic that is not passing through the VPN.  

For configuration steps, refer to the Site-to-site VPN Firewall Rule Behavior article. 

After completing the configuration steps, the Site-to-site VPN tunnel should be established. If the VPN tunnel does not come up immediately, send a ping to an IP address in the remote subnet to establish the VPN tunnel. 

 

Step 3: Select Save to apply the configuration.  

Auto VPN is a simple opt-in process. You can think of the WAN Appliances dashboard organization an existing VPN hub and spoke mesh topology environment, and every WAN appliance that has Auto VPN turned on is simply choosing to participate in that mesh. By default, all hubs contact all other hubs, and all spokes contact specified hubs. Additional configuration options can be found below.

Additional Auto VPN configuration options 

Enable Auto VPN by defining how the WAN Appliance will communicate with the rest of the Auto VPN domain 

If the WAN Appliance is configured as a Hub, it will build VPN tunnels to all other Hub WAN Appliances in the Auto VPN domain (in the same dashboard organization). It will also build VPN tunnels to all Spoke WAN Appliances in the Auto VPN domain that have this WAN Appliance configured as a hub. If all WAN Appliances in the Auto VPN domain are configured as Hub then the Auto VPN has a full mesh topology.

If the WAN Appliance is configured as a Spoke, it will build tunnels to only the WAN Appliances that are configured as its Hubs.  If the majority of WAN Appliances in the Auto VPN domain are configured as Spoke with only a few key locations (such as data centers or headquarters) configured as hubs, then the Auto VPN environment has a hub-and-spoke topology.

Choose which subnets (local networks) to export over VPN

Earmark which locally defined or available subnets are to be exported to the Auto VPN domain. Select Enabled under VPN Mode to define available subnets over the VPN.

Then save the changes so the WAN Appliance fetches the configurations from the cloud.

Post-configuration steps 

Monitoring Auto VPN 

To monitor the status of the site-to-site VPN tunnels between Meraki devices, navigate to Security & SD-WAN > Monitor > VPN Status. This page provides real-time status for the configured VPN tunnels. It lists the subnet(s) being exported over the VPN, connectivity information between the MX and Z-series WAN appliance and the Meraki VPN registry, NAT Traversal information, and the encryption type being used for all tunnels. For more information, refer to the VPN Status Page article.  

Additional resources 

Configuring Hub-and-spoke VPN Connections on the MX Security Appliance 

Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers 

Additional information 

How Auto VPN works

1. MX1 and MX2 are part of the same organization. MX1 and MX2 are configured to participate in Auto VPN. Both MX1 and MX2 send a Register Request message to their VPN registry in order to share their own contact information, and to get the contact information of the peer WAN Appliance(s) that it should form a VPN tunnel with. The Register Request message contains the IP address and the UDP port that the WAN Appliance communicates on, and the WAN Appliance requests the contact information of its peer WAN Appliance(s). 
2. VPN registries send the Register Response messages to the WAN Appliances with the contact information of the peers the WAN Appliances should establish a tunnel with. 
3. Once the information is shared with the WAN Appliance about its peers, a VPN tunnel is formed WAN Appliance to WAN Appliance. The Meraki cloud already knows the subnet information for each WAN Appliance, and now the IP addresses to use for tunnel creation. The cloud pushes a key to the WAN Appliances in their configuration which is used to establish an AES encrypted IPsec-like tunnel. Local subnets specified by dashboard admins are exported/shared across VPN. During this process, VPN routes are pushed from the dashboard to the WAN Appliances. Finally, the dashboard will dynamically push VPN peer information (e.g., exported subnets,  tunnel IP information) to each WAN Appliance. Every WAN Appliance stores this information in a separate routing table.

 

Any devices sitting upstream of a WAN Appliance will need the following destinations whitelisted so the WAN Appliance can communicate with the Auto VPN registries:

• Port
  • UDP 9350-9381
• IP range for non-China cloud (meraki.com):
  • 209.206.48.0/20
  • 158.115.128.0/19 
  • 216.157.128.0/20 
• IP range for China cloud (meraki.cn):
  • 43.192.139.128/25
  • 43.196.13.128/25

 

Ports used for IPsec tunneling:

• Source UDP port range 32768-61000
• Destination UDP port range 32768-61000

 

The VPN connection can be monitored under Security & SD-WAN > Monitor > VPN status page. The status of each WAN Appliance is displayed, along with their exported subnets, latency, connectivity and routing decisions that are being made over the Auto VPN domain in near real-time.