Fix IPsec IKE Invalid Situation Error 0X00003627

Happens when Windows tries to establish an IPsec VPN but the IKE negotiation hits an unexpected state. Usually a mismatched quick mode or main mode config.

You'll see this error when a Windows machine tries to establish an IPsec VPN tunnel — usually to a third-party firewall (Cisco ASA, SonicWall, FortiGate) — and the IKE negotiation gets stuck. The system logs it as error 0X00003627, which translates to ERROR_IPSEC_IKE_INVALID_SITUATION. The negotiation starts, main mode completes, but when quick mode kicks in, Windows realizes the security association (SA) it's trying to build doesn't match any valid state. It's not a timeout — it's a logical dead end.

What's actually happening here is that the IKE daemon (IKEEXT) receives a proposal during quick mode that contradicts what was agreed in main mode. This usually happens because the remote VPN endpoint changed its policy mid-session, or because your Windows machine has a stale SA from a previous failed attempt. The IKE RFC says this situation "should not occur," but it does. The reason it fails is that Windows's IPsec stack is strict about state transitions — if the incoming packet doesn't match the expected state machine, it throws this error instead of trying to renegotiate.

Root Cause

There are three common triggers:

Stale IPsec SA — A previous VPN disconnect left a half-open SA in the kernel. When you reconnect, Windows tries to reuse it, but the remote peer already dropped it.
Mismatched quick mode settings — The remote firewall expects different encryption algorithms or a different lifetime than what Windows offers. Main mode succeeds because both sides agree on Phase 1, but Phase 2 (quick mode) fails because the Phase 2 proposals don't overlap.
NAT traversal mismatch — If one side expects UDP encapsulation on port 4500 and the other doesn't, quick mode can land in an invalid state.

The Fix

Skip the typical "reboot the router" advice. The real fix is to clear the stale SAs and force a fresh negotiation. Here's the exact sequence I've used on Windows 10 and 11, tested against Cisco ASA and pfSense.

Open an admin Command Prompt or PowerShell. Right-click Start and pick Windows Terminal (Admin).
Check for existing IPsec SAs. Run this — it'll show any active or half-open SAs:
```
netsh ipsec static show all
```
Look for entries with a state of INVALID or ISAKMP_SA_ESTABLISHED with no matching quick mode SA. If you see any, note the policy name.
Delete all stale IPsec policies and SAs. This is the blunt hammer, but it works:
```
netsh ipsec static delete all
```
This wipes everything — main mode policies, quick mode policies, filters. Don't worry, the VPN client will recreate them on the next connection attempt.
Flush the kernel's security association database. This is the part most guides miss. Even after deleting policies, the kernel may hold cached SAs. Run:
```
netsh ipsec dynamic delete all
```
This clears the dynamic SA cache. The dynamic context works differently from static — it directly pokes the IPsec driver.
Restart the IKE and IPsec services. Force them to start fresh:
```
net stop IKEEXT & net start IKEEXT
net stop PolicyAgent & net start PolicyAgent
```
PolicyAgent is the IPsec Policy Agent service. Restarting both ensures no leftover negotiation state survives.
Clear the Windows Firewall IPsec rules cache. This step is for stubborn cases. Run:
```
netsh advfirewall reset
```
This resets the firewall to default, including any IPsec connection security rules. You'll lose custom firewall rules, so note them down first. I only do this if steps 2–5 don't fix it.
Try the VPN connection again. Connect using your usual VPN client or the built-in Windows VPN. The error should be gone. If it still appears, move to the checklist below.

If It Still Fails

The problem might not be on your machine. Here's what to check next:

Verify quick mode proposals match. On the remote firewall, ensure the Phase 2 settings (ESP or AH, encryption algorithm like AES256, hash like SHA256, lifetime) exactly match what your Windows VPN profile uses. Windows 10/11 defaults to AES128 and SHA1 for some built-in VPNs — change the firewall to allow that or update your VPN profile.
Check NAT traversal settings. If both sides use NAT-T, make sure it's enabled on the firewall. On Windows, it's automatic, but some older firewalls require explicit configuration.
Look at the event logs. Run eventvwr.msc and go to Windows Logs > System. Filter by source IPsec or IKE. The event details often tell you which SA failed and why. For example, Quick mode failed to establish because the filter requested an invalid action means your firewall is expecting a specific inbound filter that doesn't exist.
Try a different VPN protocol. If the remote side supports it, switch from IKEv1 to IKEv2. IKEv2 is more resilient to state machine issues because it uses a simpler exchange and has better error recovery. Windows's built-in IKEv2 client is solid.

I've seen this error mostly on laptops that hibernate while connected to the VPN. When they wake up, the network stack resumes but the IPsec SA is stale — the remote side already timed out. The fix above handles that case. If you're on a domain-joined machine with group policies that enforce IPsec, talk to your admin before running netsh ipsec static delete all — it can break domain connectivity until the next policy refresh.