Caveats and Considerations
This section discusses important caveats and considerations associated with the Meraki Third Party (non-Meraki) VPN tunnel configuration to Secure Access.
- There is no stateful failover to a Secure Access secondary tunnel.
- The MX only supports active/cold standby to a single headend.
- Traffic from a failed site is required to reestablish the tunnel.
- Only static routing is supported; BGP is not supported.
- Requires traffic to be generated from the LAN side of an MX through the non-Meraki VPN to establish connection.
- Remote application access on Meraki networks through an MX is not possible until traffic is initiated from the application side of the MX through the non-Meraki VPN.
- Traffic will also need to be consistently generated from the LAN side of the MX over each non-Meraki VPN to keep the tunnel from timing out.
- ECMP/Load balancing is not supported. Only a single IPSec tunnel is supported between a single Meraki network and a Secure Access network tunnel group.
- A unique public uplink IP is required for each network.a.
- The public uplink IP is used as the MX peer device IP, and this cannot be changed.
- In the Secure Access dashboard, the network tunnel group will display the status as Warning. This is because the Meraki network cannot build a standby tunnel to the Secondary Hub in the network tunnel group that is provided for intra-region redundancy.