Cisco Meraki MX (static routing)

This guide provides step-by-step instructions for configuring Cisco Meraki MX appliances to establish IPsec VPN tunnels to Cloudflare WAN. It is intended for network engineers who are familiar with Cisco Meraki administration and have an active Cloudflare WAN subscription.

Test environment

Field	Value
Vendor	Cisco Meraki
Model	MX68
Release	MX 19.2.7

Note

Meraki 19.2.7 is the minimum required version to support Route-Based IPsec VPN with third-party endpoints, including Cloudflare WAN. Refer to the Meraki implementation and compatibility notes section for more details.

IKE and IPsec crypto settings

Field	Value
Traffic Selection Criteria	Route-Based VPN
Routing	Static
Redundant Tunnels	Yes
Tunnel Load Balancing	Active/Standby
IKE Version	IKEv2
Authentication	Pre-Shared Key
Anti-Replay Protection	Enabled
NAT Traversal (NAT-T)	Not Tested
NAT-T Port	Not Applicable
Phase 1 — DH-Group	Group 14
Phase 1 — Encryption	AES-256-CBC
Phase 1 — Authentication/Integrity	SHA-256
Phase 2 — DH-Group	Group 14
Phase 2 — Transport	ESP
Phase 2 — Encryption	AES-256-CBC

Note

Cloudflare recommends DH Group 20, which is not supported by the MX platform. DH Group 14 is compatible with the MX platform.

Cloudflare WAN and Cisco Meraki MX configuration

Replace all object names and IP addresses in the examples below to match your environment.

Note

The Cloudflare IPsec tunnel health checks require non-standard configuration settings to support the MX platform. The note in each section below identifies the affected fields.

Cloudflare WAN tunnel 1 of 2

Attribute	Value/Address
Name (required)	CF_WAN_TUN_01
Description	—
IPv4 Interface Address (required)	169.254.250.0/31
IPv6 Interface Address	—
Customer Endpoint	203.0.113.100
Cloudflare Endpoint	162.159.135.1
Tunnel health checks	True
Rate	Low
Type	Request
Direction	Bidirectional
Target	Custom
Target address	192.168.125.1 (MX LAN Interface IP)
Turn on replay protection	True
Automatic return routing	True

Note

The values for Rate, Type, Direction, Target, Target address, Turn on replay protection, and Automatic return routing are the non-standard settings required to support the MX platform.

Obtain the IKE identity and pre-shared key after tunnel creation:

Attribute	Value/Address
FQDN ID	bf6c493d03<REDACTED>.ipsec.cloudflare.com
Pre-shared key	Cloudflare-WAN-T1-PSK-1234!

Cloudflare WAN tunnel 2 of 2

Attribute	Value/Address
Name (required)	CF_WAN_TUN_02
Description	—
IPv4 Interface Address (required)	169.254.250.2/31
IPv6 Interface Address	—
Customer Endpoint	203.0.113.100
Cloudflare Endpoint	172.64.135.1
Tunnel health checks	True
Rate	Low
Type	Request
Direction	Bidirectional
Target	Custom
Target address	192.168.125.1 (MX LAN Interface IP)
Turn on replay protection	True
Automatic return routing	True

Note

The same non-standard settings called out for tunnel 1 of 2 also apply to tunnel 2 of 2.

Obtain the IKE identity and pre-shared key after tunnel creation:

Attribute	Value/Address
FQDN ID	0287844e9d<REDACTED>.ipsec.cloudflare.com
Pre-shared key	Cloudflare-WAN-T2-PSK-1234!

Customer premise equipment: Cisco Meraki

Mode: Routed

WAN Interface (Port 1)	Tunnel 1 of 2	Tunnel 2 of 2
WAN Interface	WAN 1	WAN 1
IP Address	203.0.113.100/24	203.0.113.100/24

LAN Interface (Port 3)	Tunnel 1 of 2	Tunnel 2 of 2
LAN Interface	LAN	LAN
IP Address	192.168.125.1/24	192.168.125.1/24

Note

Virtual Tunnel Interfaces (VTIs) cannot be configured on MX appliances.

Assumptions and constraints

Meraki implementation and compatibility notes

• Firmware prerequisite: The minimum required firmware for this configuration is MX 19.2.7.
• Hardware compatibility: Older Meraki hardware may be physically incapable of running 19.2.7. Route-Based VPN support is required for this architecture. Refer to Product firmware restrictions ↗ to determine whether your MX platform supports firmware release 19.2.7 or later.
• Active/Standby configuration: Redundant tunnels associated with Non-Meraki VPN connections are Active/Standby. Both tunnels are established, but Meraki only routes traffic via the primary IPsec VPN peer and dynamically fails over to the secondary IPsec VPN peer based on tunnel monitoring probes.
  • Anycast and tunnel redundancy: Despite the Active/Standby nature of IPsec VPN tunnels on the MX platform, high availability is maintained at the network layer because the Cloudflare remote endpoint IPs are advertised via BGP anycast across the Cloudflare global network and provide inherent geographic and logical redundancy.
• Route-Based VPN support: While often associated with specific cloud integrations, version 19.2.7 supports Route-Based IPsec VPN for third-party devices generally, including Cloudflare WAN.
• Redundancy and Multi-Uplink: This documentation specifically covers Active/Standby tunnel configurations.
  • Multi-Uplink IPsec VPN: The Meraki Multi-Uplink IPsec VPN ↗ feature is outside the scope of this guide.
• Anti-Replay Protection: Cloudflare recommends disabling Anti-Replay Protection for optimal performance with Cloudflare WAN. The Cisco Meraki MX platform does not permit administrators to disable this feature.
  • This is a known Meraki platform limitation.
  • In environments with high jitter or out-of-order packet delivery on the underlay (ISP network), this may cause intermittent packet drops on the MX side of the IPsec VPN tunnels.
• MSS Clamping: Cloudflare recommends specific Maximum Segment Size (MSS) clamping values to account for IPsec overhead and prevent fragmentation.
  • The Meraki Dashboard does not provide a user-accessible field to modify the MSS clamping value for third-party VPN tunnels.
  • Customers must contact Meraki Technical Support to request a manual backend modification of the MSS value (approximately 1360; the value may vary) for the specific network or tunnel.
• ISP scope: The provided configuration is validated for a single Internet Service Provider (ISP). The logic can be extended to accommodate redundant ISPs, but multi-homed configuration is outside the scope of this guide.

Cloudflare

• This configuration requires the Unified Routing dataplane to support Automatic Return Routing.
• You have already configured IPsec tunnels and static routes in the Cloudflare dashboard.
• You have used the Cloudflare dashboard to obtain the local identifier (FQDN/hostname) and generate a pre-shared key for each IPsec tunnel.
• You understand the importance of MSS clamping and adjusting it based on the traffic flows traversing the Cloudflare WAN IPsec tunnels.

Prerequisites: MX platform site-to-site VPN configuration

The following details from the Cloudflare configuration are required before proceeding with the Meraki configuration:

• IPv4 interface address values (in Classless Inter-Domain Routing (CIDR) notation)
• Cloudflare anycast IPs
• Local ID (FQDN/hostname)
• Pre-shared keys
• Remote subnets

CF_WAN_TUN_01

Attribute	Value/Address	Meraki — Applies To	Required to
IPv4 Interface Address	169.254.250.0/31	Private subnets	Support Cloudflare tunnel health checks
Cloudflare Endpoint	162.159.135.1	Public IP or hostname	Tunnel peer IP — primary IPsec peer
	162.159.135.1	Remote ID	IKE remote ID — primary IPsec peer
FQDN ID	bf6c493d03<REDACTED>.ipsec.cloudflare.com	Local ID	IKE local ID — primary IPsec peer
Pre-Shared Key	Cloudflare-WAN-T1-PSK-1234!	Shared secret	Shared secret — primary IPsec peer
Remote subnets	172.16.10.0/24, 172.16.11.0/24	Private subnets	Add routes for east/west traffic flows

CF_WAN_TUN_02

Attribute	Value/Address	Meraki Setting	Required to
IPv4 Interface Address	169.254.250.2/31	Private subnets	Support Cloudflare tunnel health checks
Cloudflare Endpoint	172.64.135.1	Public IP or hostname	Tunnel peer IP — secondary IPsec peer
	172.64.135.1	Remote ID	IKE remote ID — secondary IPsec peer
FQDN ID	0287844e9d<REDACTED>.ipsec.cloudflare.com	Local ID	IKE local ID — secondary IPsec peer
Pre-Shared Key	Cloudflare-WAN-T2-PSK-1234!	Shared secret	Shared secret — secondary IPsec peer
Remote subnets	172.16.10.0/24, 172.16.11.0/24	Private subnets	Add routes for east/west traffic flows

Remote subnets

In the MX platform, "Private subnets" refers to the remote networks the MX appliance routes through the IPsec tunnels.

This document assumes the following subnets are remote subnets:

• 172.16.10.0/24
• 172.16.11.0/24

Cloudflare

Authorize the Meraki tunnel health probe source IP

The MX platform uses tunnel monitoring to enable failover between primary and secondary IPsec VPN tunnels. Tunnel monitoring detects connectivity through the tunnels (not supported on BGP-enabled tunnels). Tunnel monitoring operates independently of Dead Peer Detection, which determines the status of the IPsec tunnels.

The tunnel health probes are used in addition to Dead Peer Detection to determine overall reachability of resources on the remote side of the IPsec tunnels.

Meraki reserves the IP address 192.0.2.3/32 (part of TEST-NET-1, defined in RFC 5737 ↗) as the source IP for tunnel monitor probes. Refer to Primary and secondary IPsec tunnels ↗ for details.

As 192.0.2.3/32 falls outside the traditional RFC 1918 ↗ address space, you must add it to the Unified Routing dataplane associated with your Cloudflare account.

Contact Cloudflare to request assistance with adding the internal_authorized_prefixes option to your account, with 192.0.2.3/32 included.

Cloudflare Gateway HTTP policy

Define an HTTP policy to permit the tunnel monitoring probe source IP address to reach the IP/URL (HTTP — port 80/tcp).

Note

The IP/URL is available from the Configure health checks section of the Meraki Dashboard (Security & SD-WAN > Site-to-site VPN > Configure health checks).

In the Cloudflare dashboard, go to Zero Trust > Traffic policies > Firewall policies > HTTP.

1. Add a new rule.
2. For Policy Name, enter Meraki Tunnel Health Checks - HTTP Policy.
3. Build an expression of type Traffic.
4. For Selector, enter Source Internal IP is 192.0.2.3.
5. For Action, select Do Not Inspect.

Position this policy at or near the top of the HTTP policy rulebase.

Diagram: Meraki tunnel monitoring with Cloudflare WAN

The following diagram shows the traffic flow from the tunnel monitoring reserved IP (192.0.2.3/32) as it traverses the IPsec tunnels to Cloudflare WAN, then through Cloudflare Gateway as the requests egress to the Internet. The response path is fully symmetric.

flowchart LR
accTitle: Meraki tunnel monitoring with Cloudflare WAN
accDescr: Traffic flow from the tunnel monitoring source IP through the Meraki MX, IPsec tunnels, Cloudflare WAN, and Cloudflare Gateway to an HTTP target on the public internet.
 subgraph CPE["Cisco Meraki (CPE) Active/Standby Model"]
    direction TB
        FW["Cisco Meraki MX
        WAN: 203.0.113.100/24
        ---
        LAN: 192.168.125.1/24
        ---
        LAN Subnet: 192.168.125.0/24"]
        L7_Health_Check["L7 Health Check
        ---
        Internal Src IP: 192.0.2.3/32"]
  end
 subgraph T1["Active - IPsec Tunnel 1"]
    direction LR
        T1_CPE["CPE VTI 1
        Internal to MX"]
        T1_CF["Cloudflare VTI 1
        169.254.250.0/31"]
  end
 subgraph T2["Standby - IPsec Tunnel 2"]
    direction LR
        T2_CPE["CPE VTI 2
        Internal to MX"]
        T2_CF["Cloudflare VTI 2
        169.254.250.2/31"]
  end
 subgraph CF["Cloudflare WAN"]
    direction TB
        EP1["Anycast Endpoint 1
        162.159.135.1"]
        EP2["Anycast Endpoint 2
        172.64.135.1"]
  end
 subgraph CF_GW["Cloudflare Gateway"]
    direction TB
        GW["Policy
        Src IP 192.0.2.3
        Allow"]
  end
    L7HCT["HTTP Target"]

    T1_CPE === T1_CF
    T2_CPE === T2_CF
    FW <==> T1_CPE & T2_CPE
    T1_CF <==> EP1
    T2_CF <==> EP2

    L7_Health_Check -.-> FW
    FW -.-> T1_CPE
    FW -.-> T2_CPE
    T1_CPE -.-> T1_CF
    T2_CPE -.-> T2_CF
    T1_CF -.-> EP1
    T2_CF -.-> EP2
    EP1 -.-> GW
    EP2 -.-> GW
    GW -.-> L7HCT
    FW@{ shape: stadium}
    T1_CPE@{ shape: stadium}
    T1_CF@{ shape: stadium}
    T2_CPE@{ shape: stadium}
    T2_CF@{ shape: stadium}
    EP1@{ shape: stadium}
    EP2@{ shape: stadium}
    GW@{ shape: stadium}

Meraki configuration

Meraki management model and Cloudflare WAN integration

The Meraki configuration management is built on a two-tier hierarchy. Objects and their associated settings are defined as either:

• Organization-wide: Global objects defined once for the entire tenant.
• Network-specific: Settings applied to an individual site or device.

The Non-Meraki VPN configuration is an Organization-tier object. It is pushed to specific MX appliances when they are associated with a corresponding Network Tag. This inheritance model is a critical factor: the tag controls which physical hardware attempts to establish tunnels to Cloudflare.

Meraki Organization

Orbital Path Ventures is a fictitious company referenced throughout the configuration to represent an Organization defined in the Meraki Dashboard.

The company manages a single Meraki MX appliance at their Austin, TX branch office, which is associated with a Network named Orbital Path Ventures - Austin TX.

A Network Tag labeled Orbital_Path_AUS_Office is associated with the Orbital Path Ventures - Austin TX Network.

Organization	Network	Tag
Orbit Path Ventures	Orbit Path Ventures - Austin TX	Orbital_Path_AUS_Office

Network Tag

Go to Network > Networks, then select the Organization.

• Orbit Path Ventures (substitute your Organization name).
• Network: Orbit Path Ventures - Austin TX (substitute your Network name).
• Tag: Orbital_Path_AUS_Office (substitute the Tag associated with the Network name).

Traffic steering

When integrating with Cloudflare WAN, the Meraki Network Tag determines which appliances inherit the Cloudflare tunnel configuration.

The Non-Meraki VPN configuration is a global object: any MX appliance with the associated Network Tag attempts to establish tunnels to Cloudflare using the same IPsec VPN peers.

To ensure predictable traffic flows and prevent routing conflicts, Cloudflare recommends the following best practices:

• Strict tunnel correlation: Maintain a 1-to-1 mapping between the redundant IPsec tunnel pairs defined in Cloudflare and the specific MX appliance initiating those tunnels.
• Site-specific Network Tags: Use granular, site-specific tags (for example, Orbital_Path_AUS_Office) rather than broad, generic tags to ensure only the intended MX inherits the tunnel configuration.
• Unique IPsec VPN peer objects: Create distinct Non-Meraki VPN peer objects at the Organization level for different physical geographic locations. Use the Availability option to establish the 1-to-1 mapping.

Return traffic from Cloudflare WAN is steered based on the Cloudflare virtual network routing table (refer to Traffic steering for details). Routes are specified based on the MX LAN prefix and corresponding IPsec tunnels.

Note

Before applying a Network Tag to a Non-Meraki VPN object, verify that the subnets defined in the Availability section of the Meraki IPsec configuration match the routing logic defined in the Cloudflare Unified Routing dataplane.

Note

If multiple MX appliances with different private subnets inherit the same Non-Meraki VPN object, they all attempt to establish tunnels using identical identifiers. This causes flapping or unpredictable routing behavior, because the Cloudflare dataplane forwards traffic destined for the prefixes associated with the private subnets indiscriminately through tunnels with the same identifier. The dataplane cannot determine if there is a mismatch of the private networks behind each MX.

Source-based default routing

Source-Based Default Routing ↗ enables an administrator to create a source-based default route and specify a next hop as a security appliance over Auto VPN or on a device on the LAN.

Source-Based Default Routing cannot be used in conjunction with Non-Meraki VPN endpoints, including Cloudflare WAN.

Define private subnets in the IPsec VPN peer configuration to control how MX appliances steer traffic through the respective tunnels.

Routing with private subnets

Any IP prefixes defined as private subnets in the IPsec VPN peer configuration control what traffic is routed across the primary and secondary VPN tunnels. They are visible in the routing table corresponding to a given MX appliance.

This document considers three route topologies:

1. East/west only:
   • Private traffic via Cloudflare WAN.
   • Internet via local Internet.
2. Internet only via Cloudflare Gateway:
   • Only route Internet traffic through Cloudflare WAN.
3. All traffic via Cloudflare WAN and Gateway:
   • East/west and Internet traffic routed via Cloudflare WAN.

All three topologies are covered in the IPsec VPN peers section.

MX site-to-site VPN configuration

Go to Security & SD-WAN > Site-to-site VPN.

Type

Select Hub (Mesh).

VPN settings

Local networks

Turn on VPN mode for the local network behind the MX devices.

From:

Name	VPN Mode	Subnet	Uplink
Default	Disabled	192.168.125.0/24	—

To:

Name	VPN Mode	Subnet	Uplink
Default	Enabled	192.168.125.0/24	—

IPsec VPN peers

Go to Security & SD-WAN > Site-to-site VPN > Organization Wide Settings.

Configure health checks

Configure a Layer 7 health check HTTP probe that the MX platform uses to determine reachability of resources through the IPsec VPN tunnels:

1. Select Configure Health Checks.

2. Provide the following values:

   Name	Endpoint
   Google	http://www.google.com

3. Select OK.

Note

The Layer 7 health check probes only support connections via HTTP (port 80/tcp). The Cloudflare Zero Trust configuration must permit the Meraki tunnel health check probe IP (192.0.2.3/32) to access the designated URL without requiring SSL/TLS encryption or any authentication or authorization policies.

Add primary and secondary IPsec VPN peers

IPsec VPN peer configurations are provided for the following topologies:

• East/west traffic only
• Internet only via Cloudflare Gateway
• All traffic via Cloudflare WAN and Gateway

Topology: east/west traffic only

Routing east/west traffic via Cloudflare WAN requires:

• Cloudflare routes specified for the LAN subnet behind the MX appliance (192.168.125.0/24) via CF_WAN_TUN_01 and CF_WAN_TUN_02.
• Remote subnets (172.16.10.0/24 and 172.16.11.0/24) specified as private subnets on the Meraki primary and secondary IPsec VPN peers.
• The IPv4 interface address prefixes specified on both CF_WAN_TUN_01 and CF_WAN_TUN_02 (169.254.250.0/31 and 169.254.250.2/31) specified as private subnets on the Meraki primary and secondary IPsec VPN peers.

Note

Automatic Return Routing is not required for east/west traffic only.

This ensures that:

• Cloudflare routes traffic destined for the LAN subnet behind the MX appliance via CF_WAN_TUN_01 and CF_WAN_TUN_02.
• The MX appliance explicitly routes traffic destined for the remote subnets (172.16.10.0/24 and 172.16.11.0/24) via the primary and secondary IPsec VPN peers respectively.
• The MX appliance explicitly routes ICMP Reply packets associated with Cloudflare tunnel health checks to the IPv4 interface addresses (169.254.250.0/31 and 169.254.250.2/31) specified on CF_WAN_TUN_01 and CF_WAN_TUN_02 via the primary and secondary IPsec VPN peers respectively.
• Internet traffic from the LAN subnet behind the MX appliance is routed via the WAN uplink.
• The MX appliance establishes IPsec tunnels to Cloudflare endpoints (162.159.135.1 and 172.64.135.1) via the WAN uplink.

Configure the following:

Cloudflare IPsec tunnels — automatic return routing:

Tunnel	Automatic Return Routing
CF_WAN_TUN_01	Disabled
CF_WAN_TUN_02	Disabled

Cloudflare routes:

Prefix	Description	Next hop	Priority	Region code	Type
192.168.125.0/24	CF_WAN_TUN_01	CF_WAN_TUN_01	100	All regions	Static
192.168.125.0/24	CF_WAN_TUN_02	CF_WAN_TUN_02	100	All regions	Static

Meraki private subnets:

Private Subnet	Scope
172.16.10.0/24	Remote site
172.16.11.0/24	Remote site
169.254.250.0/31	CF_WAN_TUN_01 — tunnel health check ICMP Reply packets
169.254.250.2/31	CF_WAN_TUN_02 — tunnel health check ICMP Reply packets

Primary IPsec VPN peer: east/west traffic only

1. Select + Add a peer.

2. Provide the following values:

   Attribute	Value
   Name	cf-wan-tun-01
   IKE Version	IKEv2
   Public IP or Hostname	162.159.135.1
   Local ID	bf6c493d03<REDACTED>.ipsec.cloudflare.com
   Remote ID	—
   Shared Secret	Cloudflare-WAN-T1-PSK-1234!
   Routing	Static
   Private Subnets	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24
   Availability	Orbital_Path_AUS_Office
   Tunnel Monitoring	Google Health Check
   Failover directly to internet	—
   IPsec Policy	—
   Preset	Custom
   Phase 1 — Encryption	AES 256
   Phase 1 — Authentication	SHA256
   Phase 1 — Pseudo-Random Function	SHA256
   Phase 1 — Diffie-Hellman group	14
   Phase 1 — Lifetime (sec)	28800
   Phase 2 — Encryption	AES256
   Phase 2 — Authentication	SHA256
   Phase 2 — PFS Group	14
   Phase 2 — Lifetime (sec)	28800

3. Select Save.

Note

Any private subnets specified in cf-wan-tun-01 are automatically inherited by cf-wan-tun-02.

Note

Availability: specifying the Orbital_Path_AUS_Office Network Tag pushes the IPsec VPN peer configuration to any MX appliances associated with the Orbit Path Ventures - Austin TX Network.

Secondary IPsec VPN peer: east/west traffic only

1. Select the --- icon in the settings column.

2. Select + Add secondary peer.

3. Do not select Inherit primary peer configurations. This ensures the Public IP or Hostname, Local ID, Remote ID, and Shared secret are configured with the settings required to successfully negotiate an IPsec tunnel CF_WAN_TUN_02.

4. Provide the following values:

   Attribute	Value
   Name	cf-wan-tun-02
   IKE Version	IKEv2 (Inherited)
   Public IP or Hostname	172.64.135.1
   Local ID	0287844e9d<REDACTED>.ipsec.cloudflare.com
   Remote ID	172.64.135.1
   Shared Secret	Cloudflare-WAN-T2-PSK-1234!
   Routing	Static (Inherited)
   Private Subnets	169.254.250.0/31, 169.254.250.2/31, 172.16.10.0/24, 172.16.11.0/24 (Inherited)
   Availability	Orbital_Path_AUS_Office (Inherited)
   Tunnel Monitoring	Google Health Check
   Failover directly to internet	—
   IPsec Policy	—
   Preset	Custom
   Phase 1 — Encryption	AES 256
   Phase 1 — Authentication	SHA256
   Phase 1 — Pseudo-Random Function	SHA256
   Phase 1 — Diffie-Hellman group	14
   Phase 1 — Lifetime (sec)	28800
   Phase 2 — Encryption	AES256
   Phase 2 — Authentication	SHA256
   Phase 2 — PFS Group	14
   Phase 2 — Lifetime (sec)	28800

5. Select Save.

Note

Inherited indicates the value was automatically applied based on the configuration as specified on cf-wan-tun-01.

Route table: east/west traffic only

Confirm the MX appliance route table includes routes for the private subnets defined in the primary and secondary IPsec VPN peer configuration.

Go to Security & SD-WAN > Monitor > Route table.

The Meraki route table reflects routes via cf-wan-tun-01 and cf-wan-tun-02 as follows:

Status	Version	Subnet	Name	VLAN	Next-Hop	Destination	Type
—	4	0.0.0.0/0	Default	—	—	WAN uplink	Default WAN Route
—	4	169.254.250.0/31	cf-wan-tun-01	—	cf-wan-tun-01	—	IPsec Peer
—	4	169.254.250.0/31	cf-wan-tun-02	—	cf-wan-tun-02	—	IPsec Peer
—	4	169.254.250.2/31	cf-wan-tun-01	—	cf-wan-tun-01	—	IPsec Peer
—	4	169.254.250.2/31	cf-wan-tun-02	—	cf-wan-tun-02	—	IPsec Peer
—	4	172.16.10.0/24	cf-wan-tun-01	—	cf-wan-tun-01	—	IPsec Peer
—	4	172.16.10.0/24	cf-wan-tun-02	—	cf-wan-tun-02	—	IPsec Peer
—	4	172.16.11.0/24	cf-wan-tun-01	—	cf-wan-tun-01	—	IPsec Peer
—	4	172.16.11.0/24	cf-wan-tun-02	—	cf-wan-tun-02	—	IPsec Peer
🟢	4	192.168.125.0/24	LAN	1	192.168.125.1	192.168.125.1	Local VLAN

Tunnel health and failover

Meraki uses tunnel monitoring to determine when to fail over automatically to the secondary IPsec VPN peer. Meraki uses Dead Peer Detection to determine the overall health of the IPsec tunnels.

Non-Meraki VPN peers support an Active/Standby model. Traffic is sent via cf-wan-tun-01 until a failover event occurs, at which point cf-wan-tun-02 becomes active. Traffic is dynamically reverted to cf-wan-tun-01 once its tunnel is reconnected.

Failover testing indicates traffic may be disrupted for a few seconds. Cloudflare has observed some failover events taking 15 to 20 seconds, but these incidents are rare.

Cloudflare tunnel health

Cloudflare tunnel health checks indicate 100% failure on the tunnel marked as standby. This ensures traffic is only steered through the active tunnel.

Active Peer	Tunnel health
Primary IPsec VPN peer	CF_WAN_TUN_01: 🟢 0%	CF_WAN_TUN_02: 🔴 100%
Secondary IPsec VPN peer	CF_WAN_TUN_01: 🔴 100%	CF_WAN_TUN_02: 🟢 0%

Meraki tunnel health

Use the Meraki Dashboard to determine the status of the IPsec tunnels:

1. Go to Security & SD-WAN > Monitor > VPN Status.
2. Scroll to the Overview section.
3. Select the filter labeled 2 IPsec peers.

East/west traffic only

Active tunnel: cf-wan-tun-01:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	169.254.250.0/31	Details (link)
🟢 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24
🟢 IPsec	cf-wan-tun-02	172.64.135.1	169.254.250.0/31	Details (link)
🟢 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24

Active tunnel: cf-wan-tun-02:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	169.254.250.0/31	Details (link)
🔴 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24
🟢 IPsec	cf-wan-tun-02	172.64.135.1	169.254.250.0/31	Details (link)
🟢 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24

Internet only via Cloudflare Gateway

Active tunnel: cf-wan-tun-01:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	0.0.0.0/0	Details (link)
🟢 Health check
🟢 IPsec	cf-wan-tun-02	172.64.135.1	0.0.0.0/0	Details (link)
🟢 Health check

Active tunnel: cf-wan-tun-02:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	0.0.0.0/0	Details (link)
🔴 Health check
🟢 IPsec	cf-wan-tun-02	172.64.135.1	0.0.0.0/0	Details (link)
🟢 Health check

All traffic via Cloudflare WAN and Gateway

Active tunnel: cf-wan-tun-01:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	0.0.0.0/0	Details (link)
🟢 Health check
🟢 IPsec	cf-wan-tun-02	172.64.135.1	0.0.0.0/0	Details (link)
🟢 Health check

Active tunnel: cf-wan-tun-02:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	0.0.0.0/0	Details (link)
🔴 Health check
🟢 IPsec	cf-wan-tun-02	172.64.135.1	0.0.0.0/0	Details (link)
🟢 Health check

Troubleshooting

MX platform routing table

Review the MX route table to determine what traffic is routed over the IPsec tunnels compared to direct internet routing.

Go to Security & SD-WAN > Monitor > Route Table.

MX tunnel monitoring

VPN Status reports that the health checks are failing on both tunnels:

Status	Name	Public IP	Subnets	Tunnel monitor
🟢 IPsec	cf-wan-tun-01	162.159.135.1	169.254.250.0/31	Details (link)
🔴 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24
🟢 IPsec	cf-wan-tun-02	172.64.135.1	169.254.250.0/31	Details (link)
🔴 Health check			169.254.250.2/31
			172.16.10.0/24
			172.16.11.0/24

Check the Cloudflare Gateway logs and policy to determine if HTTP requests originating from 192.0.2.3/32 are being blocked.

If blocked, create a rule to restore tunnel monitoring HTTP requests. Refer to Cloudflare Gateway HTTP policy for details.

Cloudflare and Meraki IPsec logs

Available in:

• Log Explorer
• Logpush > IPsec logs

IPsec logs can help diagnose a variety of issues related to IPsec tunnels, including:

• Using unsupported Phase 1 or Phase 2 encryption or integrity settings — look for messages indicating No proposal chosen.
  • Confirm that the Phase 1 and Phase 2 encryption or integrity values defined are supported by Cloudflare WAN.
  • Refer to Supported configuration parameters.
• IKE/IPsec identity: local or remote identity not defined or with incorrect values.
  • Refer to the Palo Alto third-party integration guide for an example of FQDN-based local identification.
• Authentication failures: wrong pre-shared key.

Refer to Configure tunnel endpoints for more details.

Cloudflare tunnel health checks

Ensure tunnel health checks for both CF_WAN_TUN_01 and CF_WAN_TUN_02 are configured with the following settings:

Attribute	Value	Notes
Enabled	True	Ensure the indicator displays 🟢 Enabled.
Type	Request	A stateful firewall drops ICMP Reply probes.
Direction	Bidirectional	Ensures probes are sent and received via the tunnel.
Target	Custom	The MX platform does not support VTIs, so probes must target an alternate IP.
Target address	192.168.125.1	Send probes to the LAN interface on the MX appliance.

Meraki references

• Connection Monitoring for WAN Failover ↗
• MX Routing Behavior ↗
• Organization Overview ↗
• Primary and Secondary IPsec VPN Tunnels ↗
• Site-to-Site VPN ↗