VPN Troubleshooting Workflow

Troubleshooting a Site-to-Site VPN can be one of the most frustrating tasks for a network engineer. Because VPNs involve encryption, routing, and firewall policies across two entirely different organizations, pinpointing the failure requires a methodical, step-by-step workflow. Guessing will waste hours of your time.

Step 1: Define the Exact Problem

Never start changing settings until you know exactly what is broken. Check your firewall logs and dashboard to define the symptom:

Step 2: Check Basic Reachability

If Phase 1 is failing, first verify that the two firewalls can actually talk to each other over the internet.

• Can Firewall A ping the Public Peer IP of Firewall B?
• Is a firewall or ISP in the middle blocking UDP Port 500 (IKE) or UDP Port 4500 (NAT-T)?

Step 3: Check Tunnel Negotiation (Phase 1 & Phase 2)

IPsec VPNs require both sides to agree perfectly on a massive list of parameters. If a single setting is mismatched, the tunnel will not form.

Phase 1 (IKE) Mismatches:

• Pre-Shared Key (PSK): Is the password identical? Are there trailing spaces?
• Encryption & Hash: Does one side propose AES-256 with SHA-256, while the other side only allows AES-128 with SHA-1?
• Diffie-Hellman (DH) Group: Both sides must agree on the DH group for key exchange.

Phase 2 (IPsec) Mismatches:

• Local and Remote Networks: In policy-based VPNs, the subnets defined in the "Interesting Traffic" ACL must perfectly mirror each other. If Site A says 192.168.1.0/24 to 10.0.0.0/8, Site B must say 10.0.0.0/8 to 192.168.1.0/24. If Site A uses a /24 and Site B uses a /25, Phase 2 will fail.
• Perfect Forward Secrecy (PFS): If one side enables PFS and the other doesn't, Phase 2 will fail to negotiate.

Step 4: Check Routing

If the tunnel is UP (both Phase 1 and 2 succeed), but traffic won't pass, the problem is no longer the VPN—it is a routing or policy issue.

In a modern route-based VPN, the tunnel is treated as a virtual interface (e.g., tunnel.1). Check the Routing Table on both firewalls. Does Firewall A actually have a static route pointing traffic destined for Site B out the tunnel.1 interface? If not, it will send the private traffic out the Default Gateway to the internet, where it will be dropped.

Step 5: Check Firewall Security Policies

Firewalls block traffic by default. Even if the routing is perfect and the tunnel is up, you must create a Stateful Firewall policy explicitly allowing the traffic to pass. For example: "Allow traffic from Internal_Zone to VPN_Zone."

Remember that firewalls require bidirectional policies if connections can be initiated from either side.

Step 6: Check NAT (The Silent Killer)

When traffic leaves an internal network headed for a WAN interface, firewalls usually apply NAT (Source NAT) to translate the private IP into a public IP.

If your VPN traffic accidentally gets caught by a broad NAT rule, the Source IP will be translated to a Public IP before it enters the tunnel. The remote firewall will receive traffic from a Public IP it doesn't recognize and drop it. You must configure a NAT Exemption (or "No-NAT") rule explicitly telling the firewall: "If traffic is destined for the remote VPN subnet, DO NOT translate it."

Step 7: Check the Return Path (Asymmetric Routing)

If you can ping a remote server, but the server cannot ping you, you have a one-way traffic problem.

Check the return path. Your packet successfully reached the server. But when the server replies, where does its Default Gateway send the packet? If the server's local router doesn't have a route pointing back across the VPN to your subnet, the reply packet gets sent to the internet and dropped. A successful network connection requires a complete, unbroken round-trip path.

Quick Summary

Don't guess. If Phase 1 fails, check PSKs and IKE proposals. If Phase 2 fails, check network subnet definitions. If the tunnel is up but traffic fails, check Routes, Firewall Policies, and NAT Exemptions.