Skip to main content
Cisco Meraki Documentation

Primary and Secondary IPsec VPN Tunnels

  1. Last updated
  2. Save as PDF

Overview

Primary and secondary IPsec tunnels can be created to provide redundant connectivity to a remote peer. Use cases include SASE, SSE, SWG, FWaaS, etc.

Screenshot 2024-10-18 at 6.05.07 PM.png

Prerequisites

  • IKEv2 setting

  • MX 19.1.4 or newer release

  • MX platforms that support MX 19.1.4 firmware and above

Tunnel monitoring

To enable failover between primary and secondary tunnels, tunnel monitoring is required. Tunnel monitoring with Layer 7 health check (HTTP probes) enables tracking of Primary and Secondary IPsec tunnels to determine Layer 3 & 7 connectivity over both tunnels. Meraki Secure SD-WAN uses the health check monitoring data to determine when to automatically failover to the Secondary tunnel.

Layer 7 health check is not supported on dynamic routed BGP enabled tunnels. Tunnel monitoring with Layer 7 health check is only supported with static routed tunnels.

Configure Layer 7 Health Checks

Click on the Configure health check button as shown in the following image to start the process.


Next, configure a health check name and endpoint. Meraki Secure SD-WAN will probe the configured endpoint to track connectivity over the tunnel. The endpoint hostname will be resolved over the local WAN uplink with the DNS server IP configured on the WAN interface.

Screenshot 2024-10-15 at 10.47.31 AM.png

Next, apply the Health check to a tunnel. Navigate to the tunnel you want to monitor or create a new IPsec peer.

If you already have an IPsec peer configured, click on the … dotted menu next to the configured peer, and click on edit. On the side drawer under Tunnel monitoring, select the configured health check from the Health check drop-down and save. This will apply the health check to the tunnel.

Tunnel monitoring with Layer 7 health check must be configured to enable tunnel monitoring and failover to the Secondary tunnel. 

undefined

  • The configured Layer 7 health check and failover to direct internet will be inherited by the secondary tunnel once configured
  • Only one Layer 7 health check can be applied to a tunnel pair (Primary & Secondary)

The Enable failover to DIA (Direct Internet Access) allows you to control failover behavior if both primary and secondary tunnels are down, or marked failed by tunnel monitoring.

Failover to DIA is turned off by default, which means when the tunnel fails, traffic will not failover to the Internet uplink. However if the failover to DIA option is enabled, traffic will be rerouted to the local uplink.

  • Please note that failover to DIA only works when both primary and secondary tunnels are marked as failed or are both down
  • Failover to DIA does not work between Primary tunnel and DIA. A secondary tunnel must be configured

Once tunnel monitoring has been set up, you can now add a Secondary tunnel.

Creating a Secondary Tunnel

Secondary tunnels can be enabled to provide redundancy if the primary tunnel fails.

To create a Secondary tunnel, navigate to the Primary tunnel you want to create a secondary tunnel for, and click on the dotted … menu to right of the peer, and click on Add option under Secondary. This will open a dedicated side drawer for the Secondary peer.

  • Secondary tunnels are not supported on BGP over IPsec peers. If you have BGP enabled on your primary peer, you will not see the (Primary/Secondary) option

  • Secondary tunnels can only be configured if a health check has been set on the Primary tunnel

Configuring a secondary peer is the same as configuring a primary one. The inherit primary peer configuration makes it easy to inherit primary settings and minimizes error during configuration. IKE version, routing, private subnets and availability will be automatically inherited from the primary and set to read-only.

Screenshot 2024-10-15 at 10.54.37 AM.png

Tunnel failover criteria

Failover between primary and secondary tunnel occurs when:

  • Tunnel is up (IPsec is established) but the health check probes fail.

  • Tunnel is down.
     

MX periodically applies the following policy based on the latest probe data:

  1. If the primary tunnel is up, MX picks it.

  2. If the primary tunnel is down, and the secondary tunnel is up, MX picks the secondary.

  3. If the both primary and secondary tunnels are down, MX picks direct internet access if enabled.
     

“Up” means that the most recent probe has succeeded (returned a 1xx, 2xx or 3xx status code).

“Down” means that the most recent probe has failed (ICMP unreachable, TCP reset, HTTP 4xx/5xx code or similar) or timed out (packets lost) after 10 seconds.

The delay could be longer from an end user experience perspective as the end user’s device (laptop/smartphone) may take time to reestablish connections after we have completed the failover/failback.

Failover Timers

Probe interval - 10 secs
Failover time - between 1 - 30 secs

Probe interval and failover time is not configurable at this time.

Probe IP

Tunnel monitoring probes are sourced from 192.0.2.3/32 by default for both primary and secondary tunnels. The Probe IP cannot be configured via Dashboard at this time. The ability to customize your probe IP via Dashboard will be available when the 19.x firmware becomes GA.

VPN Tunnel and Health Check Status 

Navigate to Security & SD-WAN > VPN Status – IPsec VPN tab.

Here you can see the status of the IPsec tunnel.

VPN status indicator

Meaning

Green 

Phase 1 and phase 2 are up

Amber

Phase 1 is up but phase 2 is down 

Red

Phase 1 and phase 2 are both down

Health check status is currently logged in the event log. An event type category is not yet available for health check logs, a category will be available before 19.x goes GA.

Troubleshooting

  1. IPsec tunnel status - Check if IPsec tunnel is up.

  2. Health check status - Check if health check probes are successful.

  3. DNS resolution failure - Check if endpoint is resolvable with WAN uplink DNS, try generic endpoint.

  4. Remote peer issue - Troubleshoot IPsec tunnel.