--- title: Cisco Meraki MX (static routing) description: Configure static routing on Cisco Meraki MX with Cloudflare WAN. image: https://developers.cloudflare.com/zt-preview.png --- > Documentation Index > Fetch the complete documentation index at: https://developers.cloudflare.com/cloudflare-wan/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # 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](#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.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.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 ↗](https://documentation.meraki.com/Platform%5FManagement/Product%5FInformation/Compatibility%5Fand%5FFirmware/Firmware%5FUpgrades/Product%5FFirmware%5FVersion%5FRestrictions) 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 ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Site-to-site%5FVPN/Multi-Uplink%5FIPsec%5FVPN) feature is outside the scope of this guide. * **Anti-Replay Protection**: Cloudflare recommends [disabling Anti-Replay Protection](https://developers.cloudflare.com/cloudflare-wan/reference/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](https://developers.cloudflare.com/cloudflare-wan/reference/mtu-mss/#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](https://developers.cloudflare.com/cloudflare-wan/reference/traffic-steering/#unified-routing-mode-beta) dataplane to support [Automatic Return Routing](https://developers.cloudflare.com/cloudflare-wan/reference/traffic-steering/#automatic-return-routing-beta). * 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](https://developers.cloudflare.com/cloudflare-wan/reference/mtu-mss/#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.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.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 ↗](https://datatracker.ietf.org/doc/html/rfc5737)) as the source IP for tunnel monitor probes. Refer to [Primary and secondary IPsec tunnels ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Site-to-site%5FVPN/Primary%5Fand%5FSecondary%5FIPsec%5FVPN%5FTunnels) for details. As `192.0.2.3/32` falls outside the traditional [RFC 1918 ↗](https://datatracker.ietf.org/doc/html/rfc1918) address space, you must add it to the [Unified Routing](https://developers.cloudflare.com/cloudflare-wan/reference/traffic-steering/#unified-routing-mode-beta) 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](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/) 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](https://developers.cloudflare.com/cloudflare-wan/reference/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 ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Networks%5Fand%5FRouting/Source%5FBased%5FDefault%5FRouting) 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](#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.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.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](#cloudflare-gateway-http-policy) for details. ### Cloudflare and Meraki IPsec logs Available in: * [Log Explorer](https://developers.cloudflare.com/log-explorer/) * [Logpush](https://developers.cloudflare.com/logs/logpush/) \> [IPsec logs](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/account/ipsec%5Flogs/) 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](https://developers.cloudflare.com/cloudflare-wan/reference/gre-ipsec-tunnels/#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](https://developers.cloudflare.com/cloudflare-wan/configuration/third-party/palo-alto/) for an example of FQDN-based local identification. * Authentication failures: wrong pre-shared key. Refer to [Configure tunnel endpoints](https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-tunnel-endpoints/#add-tunnels) 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 ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Firewall%5Fand%5FTraffic%5FShaping/Connection%5FMonitoring%5Ffor%5FWAN%5FFailover#Enhanced%5FWAN%5FFailover%5Fand%5FFailback) * [MX Routing Behavior ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Networks%5Fand%5FRouting/MX%5FRouting%5FBehavior) * [Organization Overview ↗](https://documentation.meraki.com/Platform%5FManagement/Dashboard%5FAdministration/Operate%5Fand%5FMaintain/Inventory%5Fand%5FDevices/Organization%5FOverview) * [Primary and Secondary IPsec VPN Tunnels ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Site-to-site%5FVPN/Primary%5Fand%5FSecondary%5FIPsec%5FVPN%5FTunnels) * [Site-to-Site VPN ↗](https://documentation.meraki.com/SASE%5Fand%5FSD-WAN/MX/Design%5Fand%5FConfigure/Configuration%5FGuides/Site-to-site%5FVPN/Site-to-Site%5FVPN%5FSettings#Peer%5Favailability) ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"/directory/","name":"Directory"}},{"@type":"ListItem","position":2,"item":{"@id":"/cloudflare-wan/","name":"Cloudflare WAN"}},{"@type":"ListItem","position":3,"item":{"@id":"/cloudflare-wan/configuration/","name":"Configuration"}},{"@type":"ListItem","position":4,"item":{"@id":"/cloudflare-wan/configuration/third-party/","name":"Third-party integration"}},{"@type":"ListItem","position":5,"item":{"@id":"/cloudflare-wan/configuration/third-party/cisco-meraki-static/","name":"Cisco Meraki MX (static routing)"}}]} ```