How to Set Up VPN Tunnels with Cisco Meraki MX

Cisco Meraki MX security appliances are among the most popular network devices deployed in UK businesses, and for good reason. Their cloud-managed architecture makes them remarkably straightforward to configure and monitor, while their security features — including VPN, firewall, intrusion detection, and content filtering — make them a comprehensive solution for small and medium-sized businesses that need enterprise-grade networking without enterprise-grade complexity.

For UK businesses operating across multiple locations — whether that is a head office in London with branches in Manchester, Birmingham, and Edinburgh, or a distributed team with employees working from home — VPN connectivity underpins daily operations. Without reliable, encrypted tunnels linking these sites and users, organisations risk exposing sensitive data to interception, failing to meet GDPR obligations for data protection in transit, and creating a fragmented network that hampers productivity and collaboration.

The shift towards hybrid working, accelerated by the pandemic, has made VPN infrastructure even more critical. Where once a business might have needed a single site-to-site tunnel between two offices, many UK organisations now require a combination of permanent site-to-site links, on-demand client VPN for remote workers, and cloud connectivity to platforms such as Microsoft Azure and Amazon Web Services. The Meraki MX platform handles all of these scenarios from a single device, which is one of the reasons it has become so widely adopted across the UK market.

One of the most common use cases for the Meraki MX is establishing VPN tunnels — either between multiple office sites (site-to-site VPN) or for remote employees connecting from home or on the road (client VPN). When configured correctly, these VPN tunnels provide secure, encrypted connectivity that protects your data in transit and extends your corporate network to wherever your people need to work.

This guide covers both site-to-site and client VPN configurations on the Meraki MX platform, including best practices for security, performance, and troubleshooting common issues.

Understanding Meraki VPN Types

The Meraki MX supports three distinct VPN configurations, each serving a different purpose. Understanding which one to use — and when to combine them — is the starting point for any VPN deployment.

Auto VPN (Site-to-Site Between Meraki Devices)

Auto VPN is Meraki's proprietary technology for establishing site-to-site VPN tunnels between Meraki MX appliances. It is the simplest and most reliable option when both ends of the tunnel are Meraki devices. Auto VPN handles key exchange, encryption negotiation, and tunnel establishment automatically through the Meraki cloud dashboard — you do not need to configure IP addresses, pre-shared keys, or IKE parameters manually.

The simplicity of Auto VPN cannot be overstated. In a traditional IPsec deployment, a network engineer would need to carefully configure matching parameters on both sides of the tunnel — encryption algorithms, hashing methods, Diffie-Hellman groups, pre-shared keys, and traffic selectors. A single mismatch in any of these parameters will prevent the tunnel from establishing. With Auto VPN, the Meraki cloud handles all of this negotiation automatically, significantly reducing the risk of misconfiguration and the time required to bring new sites online.

Auto VPN also supports sophisticated topology options. A hub-and-spoke design routes all inter-site traffic through a central hub — ideal for businesses that centralise their internet breakout, security inspection, or application hosting at a primary data centre. A full-mesh topology creates direct tunnels between every pair of sites, reducing latency for site-to-site communication but increasing the number of tunnels that must be maintained. For many UK businesses, a hybrid approach works best: a hub-and-spoke design with selective direct tunnels between high-traffic site pairs.

From a cost perspective, Auto VPN is included in the Meraki MX licensing at no additional charge. The primary cost consideration is ensuring that each site has an appropriately sized MX appliance for its VPN throughput requirements. The MX67 handles up to 450 Mbps of VPN throughput, suitable for small branch offices, whilst the MX450 supports up to 2 Gbps for larger sites with heavier traffic demands.

Non-Meraki VPN (Site-to-Site with Third-Party Devices)

When you need to connect your Meraki network to a site using a different firewall or router — such as a Cisco ASA, Fortinet FortiGate, SonicWall, or an Azure Virtual Network Gateway — you will use the non-Meraki VPN (also known as third-party VPN) configuration. This uses standard IPsec with IKE (Internet Key Exchange) and requires manual configuration of tunnel parameters on both sides.

Third-party VPN tunnels are essential for businesses that need to connect their Meraki-managed network to partner organisations, cloud platforms, or legacy infrastructure running non-Meraki equipment. A common scenario for UK businesses is connecting an office network to an Azure Virtual Network to access cloud-hosted applications, databases, or virtual desktops. Another frequent requirement is establishing a tunnel to a co-location facility or a managed hosting provider that uses their own firewall infrastructure.

The key challenge with third-party VPN tunnels is ensuring parameter alignment. Unlike Auto VPN, where the Meraki cloud coordinates the configuration automatically, a non-Meraki tunnel requires the administrator to manually configure identical IPsec parameters on both the Meraki MX and the remote device. This includes the IKE version, encryption algorithm, hashing algorithm, Diffie-Hellman group, key lifetime, and pre-shared key. If any single parameter differs between the two sides, the tunnel will fail to establish — and the error messages are not always immediately clear about which parameter is mismatched.

It is strongly recommended to document all tunnel parameters in a shared configuration sheet before beginning the setup, and to coordinate with the remote site's network administrator in real time during initial configuration. This avoids the frustrating back-and-forth of troubleshooting parameter mismatches after the fact.

Client VPN (Remote Access)

The client VPN allows individual users to connect to the corporate network from remote locations using a VPN client on their laptop, phone, or tablet. The Meraki MX supports the L2TP/IPsec protocol, which is natively supported by Windows, macOS, iOS, and Android — no additional VPN client software is required in most cases.

Configuring Auto VPN (Site-to-Site)

Auto VPN configuration is remarkably straightforward. The entire process is managed through the Meraki Dashboard and typically takes less than five minutes per site.

Step One: Define the Hub Site

In the Meraki Dashboard, navigate to Security & SD-WAN > Site-to-site VPN. Set the VPN mode to "Hub" for your main office or data centre. This designates the site as a central point to which other sites (spokes) will connect. Select which local subnets should be advertised over the VPN — typically your LAN subnets that contain shared resources such as file servers, printers, and internal applications.

Step Two: Configure Spoke Sites

On each branch office MX, navigate to the same VPN settings page and set the VPN mode to "Spoke". Select the hub site(s) from the dropdown. Again, choose which local subnets should participate in the VPN. The tunnel will establish automatically within minutes — the MX appliances negotiate the encryption, exchange keys, and bring the tunnel up without any manual intervention.

Step Three: Verify Connectivity

Once the tunnels are established, verify connectivity by testing access to resources at the hub site from each spoke, and vice versa. Use the Meraki Dashboard's VPN status page to monitor tunnel health, latency, and throughput. The dashboard provides real-time and historical data on VPN performance, making it easy to identify issues.

Network Topology Considerations

When designing your Auto VPN topology, consider how traffic flows between sites and which resources need to be accessible from where. In a hub-and-spoke configuration, all traffic between spoke sites passes through the hub, which means the hub site requires sufficient bandwidth and VPN throughput capacity to handle the aggregate traffic from all spokes. This is particularly important for UK businesses using centralised applications such as on-premises ERP systems, file servers, or VoIP platforms hosted at the hub site.

For organisations with latency-sensitive applications — such as real-time collaboration tools, VoIP, or video conferencing — consider enabling direct tunnels between sites that communicate frequently. The Meraki Dashboard allows you to designate specific spoke-to-spoke tunnels without requiring a full-mesh topology, giving you granular control over traffic flow whilst keeping the overall tunnel count manageable. Pay particular attention to the quality of the underlying internet connections at each site; a VPN tunnel can only perform as well as the slowest link in the chain.

Configuring Non-Meraki VPN (Third-Party IPsec)

When you need to establish a VPN tunnel between your Meraki MX and a third-party device or cloud platform, the configuration requires more manual setup. You will need to define the IPsec parameters on both sides and ensure they match exactly.

Required Parameters

Before starting the configuration, gather the following information: the public IP address of the remote peer, the remote LAN subnets that need to be accessible, a pre-shared key (PSK) that both sides will use for authentication, and agreement on the IKE and IPsec encryption parameters.

Parameter	Recommended Setting	Notes
IKE Version	IKEv2	More secure and reliable than IKEv1
Phase 1 Encryption	AES-256	Strongest available option
Phase 1 Hash	SHA-256	SHA-1 is deprecated
Phase 1 DH Group	Group 14 (2048-bit)	Minimum recommended by NCSC
Phase 1 Lifetime	28800 seconds (8 hours)	Meraki default
Phase 2 Encryption	AES-256	Match Phase 1 for consistency
Phase 2 Hash	SHA-256	Ensure both sides match
Phase 2 PFS Group	Group 14	Perfect Forward Secrecy
Phase 2 Lifetime	3600 seconds (1 hour)	Meraki default

Configuring Client VPN (Remote Access)

The Meraki MX client VPN provides remote access for individual users. Configuration involves both the MX appliance and the user's device.

MX Configuration

In the Meraki Dashboard, navigate to Security & SD-WAN > Client VPN. Enable the client VPN and configure the following: the client VPN subnet (a dedicated range that will be assigned to VPN clients, such as 10.0.100.0/24), the DNS servers that clients should use, the authentication method (Meraki cloud authentication, Active Directory, or RADIUS), and the shared secret (pre-shared key) that clients will use to connect.

For UK businesses with Active Directory, integrating the client VPN with your AD domain is strongly recommended. This allows users to authenticate with their existing domain credentials, simplifies user management, and enables you to control VPN access through AD group membership.

Multi-Factor Authentication Considerations

One significant limitation of the native Meraki client VPN is its lack of built-in multi-factor authentication (MFA). The L2TP/IPsec protocol supports only username and password authentication, which means a compromised set of credentials could allow an attacker to connect to your corporate network via VPN. For UK businesses handling sensitive data — particularly those subject to regulations such as the Data Protection Act 2018 or sector-specific requirements in financial services and healthcare — this is a serious concern.

To address this, many organisations implement MFA through their RADIUS server. By integrating the Meraki client VPN with a RADIUS server that supports MFA — such as Microsoft NPS with Azure MFA, Cisco Duo, or Okta — you can require a second factor (such as a push notification, one-time code, or hardware token) before granting VPN access. This significantly strengthens your remote access security posture and aligns with NCSC guidance on protecting remote access connections.

Alternatively, for businesses that require a more robust remote access solution with native MFA support, integrated endpoint compliance checking, and more granular access controls, consider deploying Cisco AnyConnect alongside the Meraki MX. AnyConnect supports SAML authentication, allowing integration with identity providers such as Azure AD and Okta, and provides features such as posture assessment — checking that the connecting device meets minimum security requirements before granting network access.

Client Device Configuration

Because the Meraki client VPN uses L2TP/IPsec, it can be configured natively on all major operating systems without installing additional software. On Windows, create a new VPN connection in Network Settings with the type set to L2TP/IPsec with pre-shared key. On macOS, add a VPN configuration in System Settings > Network with the interface set to VPN and type set to L2TP over IPsec.

Security Best Practices for Meraki VPN

A properly configured VPN is a strong security tool, but a poorly configured one can introduce vulnerabilities. Follow these best practices to ensure your Meraki VPN deployment is secure.

Use strong pre-shared keys — a minimum of 32 characters with a mix of character types. Rotate pre-shared keys at least annually. For client VPN, integrate with Active Directory or RADIUS rather than using Meraki cloud authentication, as this provides better user management and allows you to enforce password policies. Enable split tunnelling only when necessary — full tunnel mode forces all traffic through the VPN, providing better security monitoring but consuming more bandwidth. Restrict VPN access to authorised users through group-based policies. Monitor VPN connection logs for unusual patterns, such as connections from unexpected geographic locations or at unusual times.

For businesses pursuing Cyber Essentials certification, ensure that your VPN configuration meets the scheme's requirements for secure remote access, including strong authentication, encryption of data in transit, and access controls that limit what VPN users can reach on the internal network.

Network Segmentation and VPN Access Control

A critical security principle that is often overlooked in VPN deployments is network segmentation. Simply granting VPN users full access to the entire internal network creates unnecessary risk — if a VPN user's device is compromised, the attacker gains the same broad access. Instead, use the Meraki MX's group policy feature to restrict VPN users to only the specific subnets and services they need for their role.

For example, a remote sales team member might only need access to the CRM system and shared sales documents, not to the finance server, development environment, or network management interfaces. By creating group policies tied to Active Directory groups and assigning them through the client VPN configuration, you can enforce least-privilege access without manual intervention for each user.

Logging, Monitoring, and Incident Response

Every VPN connection and disconnection should be logged and monitored. The Meraki Dashboard provides event logs that record VPN connection events, including the username, source IP address, and duration of each session. For businesses with a SIEM (Security Information and Event Management) system — such as Microsoft Sentinel, Splunk, or a managed SOC service — configure the Meraki MX to forward syslog data so that VPN events are correlated with other security telemetry.

Establish clear procedures for responding to suspicious VPN activity. This includes connections from unusual geographic locations (which could indicate stolen credentials), connections at unusual times, repeated failed authentication attempts (which could indicate a brute-force attack), and any VPN user accessing resources outside their normal pattern. The Meraki Dashboard's built-in alerting can notify administrators of some of these events, but a SIEM provides more sophisticated correlation and detection capabilities.

Troubleshooting Common VPN Issues

Despite Meraki's ease of use, VPN issues do occasionally arise. The most common problems and their solutions include tunnels failing to establish (usually caused by mismatched IPsec parameters or firewall rules blocking UDP ports 500 and 4500), intermittent disconnections (often caused by DPD — Dead Peer Detection — timeout mismatches or NAT traversal issues), slow performance (typically caused by the MX being undersized for the traffic volume, or the underlying internet connection being insufficient), and client VPN users unable to access internal resources (usually a routing or DNS issue on the client subnet).

The Meraki Dashboard provides extensive troubleshooting tools, including event logs, VPN status monitoring, and the ability to run packet captures directly on the MX appliance. For non-Meraki VPN tunnels, always check the event log on both sides of the tunnel to identify where the negotiation is failing.

Performance Optimisation for VPN Tunnels

VPN performance is ultimately constrained by two factors: the throughput capacity of the MX appliance and the quality of the underlying internet connection. When users report slow performance over VPN, start by checking whether the MX appliance is approaching its rated VPN throughput limit — this information is visible on the Meraki Dashboard's appliance status page. If the appliance is consistently running at or near capacity, it may be time to upgrade to a higher-capacity model.

For site-to-site tunnels, the Meraki MX's integrated SD-WAN capabilities can significantly improve performance by intelligently routing traffic across multiple internet connections. If a site has both a primary fibre connection and a secondary 4G or 5G backup, the MX can use both links simultaneously for VPN traffic, balancing load and providing automatic failover. This is particularly valuable for UK businesses in areas where single-provider internet reliability may be inconsistent.

For client VPN users experiencing slow performance, the most common cause is the user's own internet connection — particularly upload speed, which is often the bottleneck for consumer broadband. Encourage remote workers to use wired Ethernet connections rather than Wi-Fi where possible, and consider whether split tunnelling (routing only corporate traffic through the VPN while allowing internet traffic to go direct) would improve the user experience without unacceptably compromising security.