Site-to-Site IPsec VPN Down? A Universal Troubleshooting Checklist

By Stackvora Team · 2026-08-15 · 10 min read

Site-to-site IPsec has been standardised for decades, yet tunnels still fail for the same handful of reasons. The trick is to identify which phase fails before touching configuration — that single decision eliminates 80% of the search space.

Phase 1 or Phase 2?

Phase 1 (IKE) establishes the management channel. Phase 2 (IPsec SA) protects the actual traffic. Read your logs for which one never completes:

• No phase 1 → the peers are not talking at all: UDP 500 blocked, wrong peer IP, pre-shared key mismatch, or IKE version mismatch.
• Phase 1 up, phase 2 down → proposal or selector mismatch: encryption/hash/PFS group differ, or the interesting-traffic definitions do not mirror each other.
• Both up, no traffic → routing, firewall policy, NAT exemption, or MTU.

Mandatory matching parameters

Proxy-ID mismatch is the single most common phase 2 failure between different vendors. Cisco ASA derives selectors from the crypto ACL, FortiGate from the phase 2 subnets, Palo Alto from explicit proxy IDs. Write them down for both ends before debugging.

Vendor debug commands

# Cisco ASA / IOS
show crypto isakmp sa
show crypto ipsec sa
debug crypto ikev2 protocol 4

# FortiGate
diagnose vpn ike log filter name TUNNEL
diagnose debug application ike -1
diagnose vpn tunnel list

# Palo Alto
show vpn ike-sa
show vpn ipsec-sa
less mp-log ikemgr.log

# Linux strongSwan
swanctl --list-sas
journalctl -u strongswan -f

NAT traversal

If either peer sits behind NAT, IKE must move to UDP 4500 after detecting NAT during phase 1. Symptoms of blocked NAT-T are a phase 1 that establishes then dies, or tunnels that work only in one direction. Allow UDP 500, UDP 4500 and ESP (IP protocol 50) inbound on both edges — a firewall that permits only UDP 500 produces exactly this behaviour.

Routing and NAT exemption

A tunnel can be fully up while traffic still fails:

• Route-based VPNs need a route pointing the remote subnet at the tunnel interface.
• Policy-based VPNs need firewall rules in both directions referencing the tunnel.
• Traffic to the remote site must be exempt from source NAT, or the peer receives packets from an unexpected source and drops them at the selector check.
• Overlapping subnets on both sides require NAT inside the tunnel; there is no way around it.

Intermittent drops and rekey storms

Tunnels that come up and fail every hour usually have mismatched lifetimes or a device that does not support the peer's rekey behaviour. Set identical lifetimes (28800 s phase 1, 3600 s phase 2 is a safe pair), enable DPD on both ends with matching intervals, and check for duplicate tunnel definitions to the same peer — two configs racing to build the same SA cause continuous flaps.

MTU and fragmentation

Ping works, SSH works, file transfers hang: that is MTU. Encapsulation adds overhead, so set the tunnel MTU around 1400 and clamp TCP MSS to 1350–1360. Verify with:

ping -f -l 1400 10.20.0.10        # Windows
ping -M do -s 1400 10.20.0.10     # Linux

Reduce the size until it passes; that value minus headers is your working MSS.

Ten-minute checklist

1. Confirm peer IPs are current on both ends (dynamic WAN IP changes break tunnels silently).
2. Re-enter the pre-shared key on both sides — never trust a copied one.
3. Match phase 1 and phase 2 proposals exactly.
4. Mirror traffic selectors.
5. Allow UDP 500/4500 and ESP.
6. Exempt tunnel traffic from NAT.
7. Add or verify the route to the remote subnet.
8. Align lifetimes and DPD.
9. Clamp MSS.
10. Clear the SAs and rebuild from a clean state.

Documenting the tunnel so the next outage is shorter

Most IPsec incidents take hours because nobody can find the agreed parameters. Keep a one-page record per tunnel containing both peer IPs, the IKE version, phase 1 and phase 2 proposals, lifetimes, both sides' traffic selectors, the NAT exemption rules, the responsible contact at the remote organisation, and the change history. When a tunnel drops at 02:00 the difference between a fifteen-minute fix and a four-hour bridge call is usually that document.

Monitoring that actually catches failures

Do not monitor tunnel state alone — some platforms report a tunnel as up while phase 2 has no active SA. Ping a host on the far side through the tunnel on a schedule and alert on that. Add a second check for certificate or pre-shared key expiry where applicable, and watch for rekey counts trending upward, which is the earliest visible sign of an unstable link before users notice anything at all.

Follow that order and most tunnels come up within a single maintenance window. Paste both sides' phase 1/phase 2 configuration into Stackvora AI for a mismatch diff, and see the knowledge base for vendor-specific interop notes.