VPN Tunnel Failed to Establish Secure Connection Fix

Quick Answer

Check the pre-shared key first (it's usually the culprit), then verify dead peer detection (DPD) timers match on both sides — set them to 10 seconds with 3 retries.

Why Your VPN Tunnel Dropped

I've seen this on everything from old Cisco ASA 5505s to Sophos XGs to Ubiquiti EdgeRouters. The tunnel was working fine, then it just stopped. No explanation. The logs show something generic like IKEv1 failed to establish secure connection or ISAKMP SA not established. Nine times out of ten, it's one of two things: the pre-shared key got changed on one side without the other being updated, or dead peer detection (DPD) settings don't match.

Had a client last month — a medical office with two sites — the tunnel died at 3 AM. Their IT guy pulled the key from the config on one side, but the other side still had the old key from a year ago. Nobody had touched it. The router firmware update had reset the key to default on the secondary unit. Took me 10 minutes to spot it in the logs.

The other common scenario: one side is using aggressive mode while the other is using main mode for IKE negotiation. That's like one person speaking Spanish and the other speaking French — they'll never agree. Most firewalls default to main mode, and if someone hardcoded aggressive mode on one side (often done for compatibility with older clients), the tunnel will fail silently.

Step-by-Step Fix

Open the VPN logs on both ends. On pfSense, it's under Status > System Logs > IPsec. On a Cisco ASA, run show crypto isakmp sa and show crypto ipsec sa. Look for MM_WAIT_MSG2 or AG_WAIT_ERR — those tell you the phase is failing.
Compare the pre-shared keys. Don't trust the config export — physically re-enter the key on both sides. Keys get corrupted during copy-paste, and a single wrong character kills the tunnel. Use a short key (under 32 characters) to avoid truncation issues. I've seen Cisco ASAs silently truncate keys longer than 64 characters.
Check DPD settings. On most firewalls, set DPD interval to 10 seconds and retry count to 3. If one side has it at 30 seconds and the other at 10, the tunnel will drop because the faster side thinks the slower one is dead. I set this to 10/3 on every new build now — it's the sweet spot for stability without hammering the connection.
Verify IKE version. Both ends must use the same version — IKEv1 or IKEv2. Mixing them causes immediate failure. If you're still on IKEv1 and the other side upgraded to IKEv2 (common with newer firmware), the tunnel won't come up.
Match encryption settings. AES-256, SHA-256, DH Group 14 — confirm these match on both sides. A mismatch in encryption or authentication will fail negotiation before the tunnel ever starts. Use the same lifetime too — 86400 seconds for phase 1 and 3600 seconds for phase 2 is standard. I've seen units where one side had 3600 seconds and the other 28800; that caused intermittent drops every hour.

Alternative Fixes If That Doesn't Work

Reboot both VPN endpoints. Seriously. Sometimes a router's IKE process hangs and a reboot clears the SA table. I had a client's SonicWall that needed a monthly reboot because of a memory leak in the VPN daemon — reboot fixed it every time until they patched the firmware.
Delete and recreate the tunnel. Not just disable/enable — delete the policy, save, then rebuild it. Corrupt tunnel objects are real. I've seen a Cisco ASA retain old NAT rules tied to a deleted tunnel, blocking traffic until the config was cleaned by hand.
Check for NAT-T issues. If one side is behind a carrier-grade NAT (common with Starlink or cellular backup), the tunnel might need NAT traversal enabled. Set it to auto on both sides. I had a client using a Verizon LTE failover link — the tunnel wouldn't establish on cellular because of NAT-T mismatch. Turned it on, worked instantly.
Look at routing. Even if the tunnel establishes, traffic won't flow if the route to the remote network doesn't point through the tunnel interface. On pfSense, check that the route in your firewall rules points to the VPN gateway, not the WAN. I've wasted an hour on a tunnel that was "up" but no traffic passed because the route was missing.

Prevention Tip

Set a calendar reminder to review VPN configs every 6 months. Pre-shared keys should be rotated annually. Also, enable IPsec logging to a syslog server so you catch failures early. I use a free Papertrail account for remote monitoring — when the logs show repeated DPD timeouts, I know the tunnel's about to drop before the client calls. Simple fix, saves everyone a headache.