Cisco ASA site-to-site IPSec VPN tunnel stops passing traffic until SA is cleared
On a site-to-site IPSec VPN between Cisco ASA devices (commonly 5520/5540), traffic can stop passing through an established tunnel — sometimes only for specific traffic selectors/ACLs — particularly after instability on the underlying transport (e.g., satellite link). The fix is to clear the affected IPSec SA for the remote peer and force renegotiation rather than reloading the ASA.
Indicators
- Traffic stops passing through an established site-to-site VPN tunnel
- Some traffic selectors/ACLs over the same VPN work while others do not
- Constant pings through the tunnel fail to keep it healthy
- Encrypt or decrypt counters on 'show crypto ipsec sa' stop incrementing in one direction
- Issue occurs intermittently, often after link instability (e.g., satellite link drops)
Likely causes
- Stale or desynchronized IPSec security associations between the two ASAs
- Unstable underlying transport causing SA state mismatch between peers
- Phase 2 SA for a specific proxy ACL not renegotiating after a transient outage
- Lack of or unreliable Dead Peer Detection (DPD) failing to tear down a broken tunnel
Diagnostic steps
-
Verify tunnel state and existing SAs with 'show crypto ipsec sa peer <remote-peer-IP>' and 'show crypto isakmp sa'.
-
Test connectivity for each interesting traffic flow (ping/traceroute) to determine whether all selectors or only specific ACLs are failing.
-
Check encrypt/decrypt counters in 'show crypto ipsec sa' to confirm whether one direction of the SA is broken.
-
Confirm you have an out-of-band/management path to the remote ASA before clearing the SA, since the tunnel will briefly drop.
-
Clear the affected IPSec SA on one side: 'clear crypto ipsec sa peer <remote-peer-IP>'.
-
Generate interesting traffic (e.g., ping across the tunnel) to trigger SA reestablishment.
-
Re-run 'show crypto ipsec sa peer <remote-peer-IP>' to confirm the tunnel is up and traffic passes in both directions.
Resolution path
- Identify the remote peer IP of the affected VPN tunnel
- Ensure out-of-band access to the remote ASA in case the tunnel does not immediately re-establish
- Run 'clear crypto ipsec sa peer <remote-peer-IP>' on one ASA
- Send interesting traffic across the tunnel to force IPSec renegotiation
- Verify the tunnel reestablishes with 'show crypto ipsec sa peer <remote-peer-IP>' and that traffic flows in both directions
- Accept a brief VPN outage during reestablishment
Prevention
- Enable and tune IKE Dead Peer Detection (DPD) so broken tunnels are detected and torn down automatically
- Use shorter IPSec SA lifetimes on unstable links to force more frequent rekeys
- Monitor tunnel state proactively via SNMP/syslog to detect failures before users report them
- Improve underlying transport reliability or add a backup path/secondary peer where possible
- Standardise crypto map/ACL definitions on both peers to avoid mismatched proxy ACLs
Tools
- Cisco ASA CLI
- clear crypto ipsec sa peer <remote-peer-IP>
- show crypto ipsec sa
- show crypto isakmp sa
- ping (to generate interesting traffic)