Stackvora.tech

Meraki MX: build an Auto VPN site-to-site tunnel

Cisco Meraki MX appliances simplify VPN deployment through their Auto VPN feature, abstracting much of the complex IPsec configuration typically found in…

Cisco Meraki MX appliances simplify VPN deployment through their Auto VPN feature, abstracting much of the complex IPsec configuration typically found in traditional network devices. This guide details the process of establishing site-to-site VPN tunnels using Meraki Auto VPN, covering both hub and spoke configurations, network advertisement, and verification steps. We'll focus on practical configuration within the Meraki Dashboard, suitable for connecting multiple branch offices to a central datacenter or head office.

Understanding Meraki Auto VPN Fundamentals

Meraki Auto VPN is an overlay VPN technology designed to create full-mesh or hub-and-spoke IPsec tunnels automatically between Meraki MX appliances. It leverages a Meraki orchestrator in the cloud to manage key exchange, tunnel establishment, and routing updates. This significantly reduces the manual configuration burden associated with traditional IPsec VPNs, eliminating the need for pre-shared keys, ISAKMP policies, or IPsec transform sets on individual devices. Auto VPN supports both static routes and OSPF (for advanced routing between MXs and internal networks) to advertise connected subnets.

Key Concepts:

  • VPN Registry: The Meraki cloud-based service that orchestrates Auto VPN. MX appliances register with it to discover other VPN-enabled MXs in the same Meraki organization.
  • Hub: A central MX appliance that all other VPN-enabled MXs (spokes) connect to. In a hub-and-spoke topology, spokes communicate with each other through the hub. A network can have multiple hubs for redundancy or scale, but typically one or two primary hubs.
  • Spoke: An MX appliance that connects to one or more hubs. Spokes generally do not connect directly to each other unless explicitly configured for a full-mesh topology.
  • Local Networks: Subnets directly connected to or behind the MX appliance that need to be accessible over the VPN tunnel. These are advertised to other VPN peers.

Configuring Auto VPN in the Meraki Dashboard

The configuration process begins by navigating to the "Security & SD-WAN" section for your MX network in the Meraki Dashboard.

1. Enable Site-to-site VPN

From the Meraki Dashboard, select the network containing your MX appliance. Go to Security & SD-WAN → Site-to-site VPN. The default setting is usually "Off". Change this to "Hub" or "Spoke" based on the role this MX will play in your VPN topology.

2. Define VPN Role (Hub or Spoke)

Hub Configuration:

If this MX is designated as a hub:

  • Type: Select "Hub".
  • Uplink preferences: (Optional) If your MX has multiple WAN uplinks, you can prioritize which uplink(s) Auto VPN should use. By default, it uses all active uplinks.
  • NAT Traversal: Usually "Automatic". Only change if you have specific NAT requirements upstream of the MX.

Hubs act as the central point for VPN traffic. When a spoke needs to communicate with another spoke, traffic flows through the hub.

Spoke Configuration:

If this MX is designated as a spoke:

  • Type: Select "Spoke".
  • Hubs: Crucially, you must explicitly select which hub(s) this spoke should connect to. Click "Add a hub" and choose the relevant hub networks from the dropdown. This dropdown lists all other MX networks in your organization configured as "Hub" VPNs.
  • VPN Mode:
    • Split tunnel: This is the most common and recommended mode for spokes. Only traffic destined for networks advertised by the hub(s) (and other spokes via the hub) traverses the VPN. All other traffic (e.g., internet-bound) exits the spoke's local WAN uplink. This is efficient as it avoids backhauling internet traffic.
    • Full tunnel: All traffic from the spoke network, including internet-bound traffic, is routed through the VPN to the hub. The hub then routes the internet traffic. This is less common for general branch office setups but can be useful for security policies that mandate all traffic pass through a central inspection point. Be aware of increased bandwidth usage on the hub's internet connection.

3. Advertise Local Networks

For both Hub and Spoke configurations, you need to tell the MX which of its local subnets should be advertised over the VPN. In the "Local networks" section, you'll see a list of subnets associated with your MX's LAN interfaces. For each subnet you want to expose over the VPN, set its "VPN participation" to "On".

Important considerations for local networks:

  • Ensure that subnets advertised by different MXs do not overlap. Overlapping subnets will cause routing conflicts and VPN connectivity issues.
  • Only advertise subnets that clients behind the MX actually need to reach across the VPN.
  • Make sure the "Subnet" and "Usage" (e.g., LAN, VLAN) are correctly identified for each entry.

Example Configuration Snippet (conceptual representation as Dashboard is GUI-based):


# Hub MX Network: HQ-MX-Primary
Security & SD-WAN → Site-to-site VPN
  Type: Hub
  Local networks:
    - Subnet: 192.168.1.0/24, Usage: LAN, VPN participation: On
    - Subnet: 10.0.0.0/24, Usage: VLAN 10 (Servers), VPN participation: On

# Spoke MX Network: Branch-Office-A
Security & SD-WAN → Site-to-site VPN
  Type: Spoke
  Hubs:
    - HQ-MX-Primary (Network ID: L_1234567890abcdef)
  VPN Mode: Split tunnel
  Local networks:
    - Subnet: 192.168.10.0/24, Usage: LAN, VPN participation: On
    - Subnet: 172.16.0.0/24, Usage: VLAN 20 (POS), VPN participation: On

Verifying VPN Tunnel Status

Once the configuration is saved, the Meraki MX appliances will attempt to establish the VPN tunnels. This process typically takes 1-2 minutes for the initial connection.

1. Check VPN Status Page

Navigate to Security & SD-WAN → VPN Status on your Meraki Dashboard for the respective MX network. This page provides a visual representation of your VPN topology and the status of each tunnel.

  • A green status indicates a successful VPN tunnel establishment and traffic flow.
  • A yellow/orange status might indicate partial connectivity or a transient issue. Hover over the status for more details.
  • A red status indicates a problem, such as a failed tunnel negotiation or unreachable peer.

Ensure that your hub MX shows connections to its configured spokes, and spokes show connections to their configured hubs.

2. Confirm Reachability

From a client device behind one of the MXs, attempt to ping a device on a remote subnet advertised over the VPN. For example, from a client on 192.168.10.0/24 (Branch-Office-A), ping a server at 10.0.0.10 (HQ-MX-Primary).


# On a client behind Branch-Office-A MX (e.g., IP: 192.168.10.100)
ping 10.0.0.10

Successful pings indicate that the VPN tunnel is up and routing is working correctly. If pings fail, check your firewall rules on both MXs and any intermediate firewalls. Remember that Meraki MXs have built-in firewall rules (Security & SD-WAN → Firewall) that might block inter-VLAN or VPN traffic by default. Ensure explicit "Allow" rules are in place for the required traffic.

3. Use the Meraki Dashboard Tools

The Meraki Dashboard offers diagnostic tools to aid troubleshooting:

  • Network-wide → Monitor → Event log: Filter by "VPN" to see events related to tunnel establishment, disconnections, and errors.
  • Security & SD-WAN → Appliance status → Uplink: Verify that the WAN uplinks are healthy and have public IP addresses if necessary for VPN.
  • Security & SD-WAN → Appliance status → Tools: Use Ping or Traceroute from the MX appliance itself to test connectivity to remote VPN endpoints or resources.

Advanced Auto VPN Considerations

Full Mesh vs. Hub-and-Spoke

While Auto VPN generally simplifies a full-mesh deployment, the Dashboard UI for selecting hubs and spokes naturally lends itself to a hub-and-spoke topology. For a full-mesh, every MX would need to be configured as a "Hub" and select every other MX as a hub. However, for most enterprises, hub-and-spoke is sufficient and easier to manage, with spokes communicating through the hub.

OSPF over Auto VPN (MX 15.x firmware and higher)

For more complex routing scenarios, especially when connecting MXs to existing internal router infrastructure, OSPF can be enabled over Auto VPN tunnels. This allows dynamic advertisement of routes beyond the directly connected subnets.

To enable OSPF:

  1. Navigate to Security & SD-WAN → OSPF.
  2. Enable OSPF.
  3. Configure the Area ID, Type, and any interface costs for LANs and VPN.
  4. Crucially, ensure "Advertise VPN routes" is enabled under the "VPN" interface settings if you want OSPF to inject routes learned from other MXs over Auto VPN into your local OSPF domain. Conversely, "Advertise LAN routes" will share local OSPF routes over Auto VPN.

This is typically used in a hub-and-spoke setup where the hub MX is peering with an internal router, and spoke MXs are also peering with local routers. Auto VPN provides the underlying transport for OSPF adjacencies.

Firewall Rules and Traffic Shaping

Remember that Auto VPN establishes the tunnel, but firewall rules still govern what traffic is permitted to traverse it. Check Security & SD-WAN → Firewall and Security & SD-WAN → Traffic shaping to ensure that necessary ports and protocols are allowed and prioritized as required.

By default, Meraki's Auto VPN firewall rules often permit all traffic between VPN peers. However, explicit rules might be necessary if custom "Block" rules are in place or for granular control.

Common Pitfalls and Troubleshooting

  • Overlapping Subnets: The most frequent cause of VPN routing failures. Each local network advertised via Auto VPN must be unique across the entire VPN topology. The Dashboard will often warn you about this, but it's critical to avoid.
  • Firewall Rules: Even if tunnels are up, firewall rules on the MX (or upstream devices) can block traffic. Verify explicitly allowed ports and protocols.
  • Incorrect Hub Selection: Spokes must correctly point to the intended hub MX networks. If a spoke cannot connect, ensure the hub MX is online and correctly configured as "Hub".
  • DNS Resolution: If clients can ping by IP but not by hostname, the issue is often DNS. Ensure clients are using DNS servers that can resolve names for the remote network, possibly pointing to a DNS server on the hub network if a full-tunnel VPN is used, or a conditional forwarder if using split-tunnel.
  • WAN Connectivity: The MX appliance requires stable internet connectivity to establish and maintain Auto VPN tunnels. Check WAN uplink status.
  • Firmware Mismatch: While Meraki generally ensures compatibility, significant firmware version differences between MXs can sometimes lead to unexpected behavior. Keep your firmware up-to-date and consistent where possible.
  • NAT Traversal Issues: If an MX is behind another NAT device (e.g., a modem/router combo from an ISP), ensure that UDP ports 500 (ISAKMP) and 4500 (IPsec NAT Traversal) are forwarded to the MX's WAN IP. Meraki's Auto VPN handles NAT traversal well, but double NAT situations can sometimes complicate matters.

Back to the knowledge base · Ask the AI assistant