Cisco ASA site-to-site VPN flaps between dual ISP interfaces at remote office
A Cisco ASA remote office with two ISP-connected outside interfaces and ISAKMP enabled on both, paired with a central ASA crypto map listing both remote peer IPs, brings the IPsec tunnel up on both interfaces simultaneously and then flaps between them. This is a fundamental limitation of policy-based (crypto map) VPNs on the ASA platform; the durable fix is to migrate to route-based IPsec (VTI or DMVPN) on a platform that supports it, since ASA does not.
Indicators
- Site-to-site IPsec tunnel repeatedly goes up and down between two ISPs
- Tunnel established on both outside interfaces simultaneously
- Tunnel flaps occur even with static routes only (no SLA tracking involved)
- Intermittent connectivity between remote office and central office over VPN
- Behavior persists regardless of SLA monitor / route-tracking configuration
- 'show vpn-sessiondb l2l' shows the active peer IP changing over time
Likely causes
- Policy-based (crypto map) VPN behavior is non-deterministic when multiple peer IPs are configured for the same SA
- ISAKMP enabled on both outside interfaces causes both to negotiate the same tunnel
- Central ASA listing two peers in the crypto map alternates which peer it accepts/initiates with
- Duplicate SAs from both ISPs cause one side to tear down the other
- ASA platform lacks support for route-based IPsec tunnels, preventing clean active/standby failover
Diagnostic steps
-
Run 'show crypto isakmp sa' and 'show crypto ipsec sa' on both ASAs to confirm SAs are alternating between peer IPs.
-
Run 'show vpn-sessiondb l2l' on both ASAs and observe the active peer IP changing during a flap.
-
Disable ISAKMP on the secondary outside interface ('no crypto isakmp enable outside2') to confirm flapping stops with a single ISP active.
-
Remove the secondary peer from the central crypto map (e.g. 'crypto map BNG_TUNNEL 1 set peer <primary-peer>') to validate single-peer stability.
-
Review SLA monitor and track status with 'show sla monitor operational-state' and 'show track' to rule out tracking flaps as the trigger.
-
Capture 'debug crypto isakmp 127' and 'debug crypto ipsec 127' during a flap to identify which peer initiates the teardown.
Resolution path
- Recognise that policy-based (crypto map) VPNs on ASA are unreliable for dual-ISP failover with multiple peers
- As a short-term workaround, enable ISAKMP on only one outside interface and use SLA tracking to swap on failure (accept longer convergence)
- Plan migration of the VPN endpoint off the ASA to a platform supporting route-based IPsec (IOS router with VTI, FTD, or DMVPN-capable device)
- Implement DMVPN or point-to-point GRE-over-IPsec tunnels with a dynamic routing protocol (EIGRP/OSPF/BGP) for deterministic failover
- Validate failover behaviour by failing each ISP individually before decommissioning the dual-peer crypto map configuration
Prevention
- Avoid configuring multiple peers in a single crypto map entry for the same tunnel on ASAs
- Do not enable ISAKMP on more than one outside interface concurrently for the same site-to-site VPN
- Use route-based VPNs (VTI / DMVPN) on platforms that support them whenever dual-ISP redundancy is required
- Design VPN failover around dynamic routing protocols rather than crypto map peer lists
- Document supported failover designs per platform so ASAs are not selected for dual-ISP IPsec resiliency
Tools
- show crypto isakmp sa
- show crypto ipsec sa
- show vpn-sessiondb l2l
- show sla monitor operational-state
- show track
- debug crypto isakmp / debug crypto ipsec