Follow a disciplined process to validate routing, policies, encryption domains and tunnel status.
When a site-to-site VPN is down, random CLI commands waste time. Start with a framework: confirm the symptom (tunnel down, phase 1/2 failure, or tunnel up but no traffic), note recent changes, and gather the peer IP, interesting traffic, proposal settings, and pre-shared key or certificate status from both sides. Align the facts before you change anything.
Validate systematically. Check Phase 1 identity and proposal match, Phase 2 encryption domains and proxy IDs, routing for the protected networks, NAT exemptions, ACLs or firewall policy, and interface reachability between peers. Use packet captures and debugs carefully, and restore default logging when finished. If traffic fails while the tunnel shows up, shift focus to routing, overlapping subnets, and return-path issues.
Document the root cause and the fix. VPN incidents often recur when proposals drift between peers or when network teams add subnets without updating crypto maps or route-based VPN configuration. A written checklist turns a stressful outage into a repeatable recovery process—and makes the next engineer faster than the last.
