Cisco Meraki MX Site-to-Site VPN: Step-by-Step

Cisco Meraki MX appliances simplify network deployments through cloud-managed features, including site-to-site VPNs. This guide details the configuration…

Cisco Meraki MX appliances simplify network deployments through cloud-managed features, including site-to-site VPNs. This guide details the configuration of IPsec VPN tunnels between Meraki MX devices (AutoVPN) and with non-Meraki VPN peers (True-IPsec), covering essential settings, encryption parameters, and routing considerations.

Meraki AutoVPN: Effortless Site-to-Site Connectivity

Meraki AutoVPN is a proprietary enhancement to standard IPsec, designed to automate tunnel establishment and routing between Meraki MX security appliances. It leverages the Meraki cloud for key exchange and tunnel negotiation, significantly reducing configuration overhead compared to traditional IPsec. AutoVPN is ideal for organizations with multiple Meraki sites requiring full mesh or hub-and-spoke connectivity.

AutoVPN Configuration Steps (Hub & Spoke)

AutoVPN setup is performed centrally from the Meraki dashboard.

1. Navigate to Security & SD-WAN > Site-to-site VPN.
2. Under "Type," select Hub (Mesh) for a central site that all other AutoVPN peers will connect to, or Spoke for a branch site connecting to a hub. For a full-mesh topology where all MXs connect directly to each other, all sites should be configured as "Hub (Mesh)".
3. For "Hub (Mesh)" sites:
   • In the "Local networks" section, select the subnets you wish to advertise over the VPN. These are typically VLANs configured on the MX.
   • Ensure "NAT traversal" is set to Automatic unless specific NAT issues exist.
4. For "Spoke" sites:
   • In the "Local networks" section, select the subnets to advertise.
   • In the "VPN target" section, choose the "Hub (Mesh)" networks from the dropdown. The Meraki dashboard automatically lists eligible hubs within the same organization.
5. Click Save changes. The Meraki cloud orchestrates tunnel setup automatically. Tunnel status can be monitored on the same page.

Important Note: AutoVPN typically uses UDP port 9350 for control traffic and UDP port 9351 for data traffic. Ensure these ports are open if intermediate firewalls are present between MX devices, though this is rare in typical deployments where MXs are at the edge.

Routing Considerations with AutoVPN

Meraki AutoVPN automatically exchanges routes between participating MX devices. There is no manual BGP or OSPF configuration required for the VPN tunnels themselves. When local networks are advertised, the MXs learn these routes and populate their routing tables. If you have non-Meraki devices or specific routing requirements behind an MX, static routes might be necessary on the MX or the downstream devices.

# Example of a static route on a Meraki MX (under Security & SD-WAN > Addressing & VLANs > Static Routes)
# This example is for routing traffic for 10.10.10.0/24 through a next-hop firewall 192.168.1.254 on VLAN 1
# This route would NOT be advertised via AutoVPN automatically; AutoVPN advertises connected subnets.

Name: On-Prem Firewall Network
Subnet: 10.10.10.0/24
Gateway IP: 192.168.1.254
VLAN: 1
Advertise via OSPF: No (usually 'No' unless integrating with an OSPF domain)
VPN: No (indicates this route is for local routing, not VPN transit)

True-IPsec: Connecting to Non-Meraki Peers

When integrating with a non-Meraki VPN device (e.g., Cisco ASA, Palo Alto Networks, Fortinet), you must configure a "True-IPsec" tunnel. This requires manual configuration of IKE (Phase 1) and IPsec (Phase 2) parameters.

Configuring a Non-Meraki VPN Peer

1. Navigate to Security & SD-WAN > Site-to-site VPN.
2. Under "Type," select Hub (Mesh) or Spoke (if this MX is part of an AutoVPN setup and also needs a non-Meraki tunnel), or simply leave it as Disabled if this MX will only connect to a non-Meraki peer.
3. Scroll down to the "Non-Meraki VPN peers" section.
4. Click Add a peer.
5. Configure the following parameters, ensuring they match the non-Meraki peer's configuration exactly:
   • Name: Descriptive name for the VPN peer.
   • Public IP: The public IP address of the non-Meraki VPN device.
   • Remote subnets: The subnets on the non-Meraki side that need to be accessible. Use CIDR notation (e.g., 10.0.1.0/24).
   • Local subnets: The subnets on the Meraki side that should be accessible to the non-Meraki peer.
   • IPsec policies:
     • IKE Version: Typically IKEv1 or IKEv2. IKEv2 is generally preferred for security and stability.
     • Authentication: Pre-shared key. Enter a strong, shared secret here.
     • Phase 1 negotiation:
       • Encryption: AES-256, AES-192, AES-128, 3DES, DES. AES-256 is recommended.
       • Integrity: SHA256, SHA1, MD5. SHA256 is recommended.
       • Diffie-Hellman Group: Group 1, 2, 5, 14, 19, 20, 21. Group 14 (2048-bit MODP) or higher is recommended.
       • Lifetime: Typically 86400 seconds (24 hours).
     • Phase 2 negotiation:
       • Encryption: AES-256, AES-192, AES-128, 3DES, DES. Must match Phase 1 if using PFS.
       • Integrity: SHA256, SHA1, MD5. Must match Phase 1 if using PFS.
       • Diffie-Hellman Group: None, Group 1, 2, 5, 14, 19, 20, 21. If Perfect Forward Secrecy (PFS) is desired, select a group (e.g., Group 14). Otherwise, select "None."
       • Lifetime: Typically 28800 seconds (8 hours).
6. Click Save changes.

Key IPsec Parameters and Recommendations

Note on NAT Traversal: If your Meraki MX has a public IP directly on its WAN interface, NAT-T is not strictly necessary. However, if the MX is behind another NAT device (e.g., another firewall, a router provided by an ISP), ensure NAT-T is enabled on both sides. Meraki automatically handles NAT-T if the WAN interface detects a private IP address.

Advanced VPN Settings and Considerations

Source Network Selection

When configuring local subnets for a VPN tunnel (both AutoVPN and non-Meraki), the Meraki MX uses the public IP of its WAN interface as the source for the VPN tunnel. If your MX has multiple WAN uplinks, you can select which WAN interface to use for the VPN under Security & SD-WAN > SD-WAN & traffic shaping > Uplink preferences, by creating a custom performance policy for VPN traffic.

Traffic Flow and Firewall Rules

VPN tunnels, once established, allow traffic between the defined local and remote subnets. However, Meraki's inherent firewall rules still apply. By default, Meraki MX devices block all inbound traffic that isn't part of an established connection or explicitly allowed. For VPN traffic, the MX automatically creates firewall rules to allow the tunnel itself, but you may need to add explicit layer 3 or layer 7 firewall rules (under Security & SD-WAN > Firewall) to permit specific application traffic *over* the VPN if it's being blocked. For example, to allow RDP (TCP/3389) from the remote network 10.0.1.0/24 to a local server 192.168.1.10, you would add an inbound rule on the Meraki MX:

# Example Meraki Firewall Rule for VPN traffic (Security & SD-WAN > Firewall > Layer 3 firewall)
# Rule Number: 1 (or next available)
# Policy: Allow
# Protocol: TCP
# Source:
#   Type: CIDR
#   CIDR: 10.0.1.0/24
# Source port: Any
# Destination:
#   Type: CIDR
#   CIDR: 192.168.1.10/32
# Destination port: 3389
# Comments: Allow RDP from remote VPN site

VPN Status Monitoring

To check the status of your VPN tunnels:

• Navigate to Security & SD-WAN > Site-to-site VPN.
• Scroll down to the "VPN status" section. This shows the health of AutoVPN peers and non-Meraki tunnels, including uptime, latency, and throughput.
• For more detailed insights, use Network-wide > Event log and filter by "VPN" for troubleshooting connection attempts or failures.

Common Pitfalls and Troubleshooting

• Mismatched Parameters: The most common issue with non-Meraki VPNs. IKE and IPsec phase 1/2 parameters (encryption, integrity, DH groups, lifetimes, pre-shared key) must match exactly on both ends. Even a single character difference in the pre-shared key will prevent tunnel establishment.
• NAT Issues: If either VPN peer is behind a NAT device, ensure NAT-T is enabled on both sides. If the MX is behind a 3rd party NAT, ensure UDP ports 500 and 4500 (for True-IPsec) or 9350/9351 (for AutoVPN) are port-forwarded to the MX's WAN IP.
• Firewall Rules: Even if the tunnel is up, traffic might be blocked by implicit or explicit firewall rules on either side. Check Layer 3 and Layer 7 firewall rules on the Meraki MX, and equivalent rules on the non-Meraki peer. Remember that Meraki client VPN clients get their own firewall rules under Security & SD-WAN > Client VPN.
• Incorrect Subnet Definitions: Ensure that "Local subnets" and "Remote subnets" are correctly defined and that there are no overlaps or missing networks.
• Routing Conflicts: If you have static routes or other routing protocols running on your internal network, ensure they don't conflict with routes learned over the VPN. Meraki MXs prioritize directly connected routes, then static routes, then VPN routes (learned via AutoVPN or explicit non-Meraki peer routes).
• Firmware Mismatch: While less common with AutoVPN, significant firmware differences can sometimes cause issues. Ensure MX devices are running recent, stable firmware.
• Performance Issues: Over-provisioning encrypted traffic can saturate the MX's CPU. Check Security & SD-WAN > Appliance status > Performance for CPU utilization. For high-throughput requirements, consider MX models with dedicated crypto engines (e.g., MX250, MX450, MX600).