Fix ERROR_IPSEC_IKE_INVALID_POLICY (0x00003625) on Windows VPN

You're here because your VPN connection threw 0x00003625 and you're staring at a black box that won't connect.

I've seen this on Windows 10 22H2 and Windows 11 23H2 after a Windows update or when switching between corporate and personal VPN profiles. The OS caches a stale IPsec policy that doesn't match what the remote server expects.

The Fix: Reset the IPsec Policy Store

Skip the GUI rabbit hole — it's hiding the real culprit. Open an elevated Command Prompt (Win+X → Terminal (Admin)) and run:

netsh ipsec static reset

Then reboot. That's it. After restart, try your VPN again.

What this command does: It deletes the local IPsec policy store and resets it to default. Every IPsec rule, filter, and security association you've customised is gone. Windows rebuilds them fresh on next boot from the Registry hive at HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local.

If you can't reboot immediately, you can force a policy refresh without rebooting:

gpupdate /force
ipsecpol -w REG -x

But in practice, the reboot is more reliable because some kernel-mode components cache the old policy until the machine cycles.

Why This Happens

The error ERROR_IPSEC_IKE_INVALID_POLICY (0x00003625) means the IKE (Internet Key Exchange) negotiation failed because the security association proposal doesn't match what the remote party expects. The local machine sends a set of encryption, hash, and authentication parameters, and the responder says "nope, that's not valid."

Three real scenarios trigger this:

1. Corrupt local policy store — A Windows update or software install writes malformed entries into the IPsec database.
2. Mismatched policy after VPN profile switch — You import a new VPN configuration but the old policy doesn't get cleaned up.
3. Group Policy leftovers — Domain-joined machines sometimes retain IPsec policies from a previous network environment.

The reset command nukes the bad entries and forces Windows to read the current Registry state. If a Group Policy still pushes a broken policy, you'll need to work with your IT to correct the GPO.

Less Common Variations

1. Stale Security Associations

If the reset doesn't help, the problem could be a hung IKE security association (SA) in the kernel. Check with:

netsh wfp show state

Look for IPsec entries with State = Deleted or State = Closing. If you see a bunch, flush the Windows Filtering Platform state:

netsh wfp set options netevents = off
net stop mpsdrv & net start mpsdrv
netsh wfp set options netevents = on

This restarts the WFP driver, which tears down all SAs. Risk: it briefly disables Windows Firewall. Don't do this on a production machine without testing.

2. Certificate Authentication Issues

If your VPN uses machine certificates, the IKE policy might reject a certificate that's still valid but has a mismatched Extended Key Usage (EKU). Check the certificate chain with certlm.msc → Personal → Certificates. The certificate used for IPsec must have Client Authentication (1.3.6.1.5.5.7.3.2) and optionally Server Authentication (1.3.6.1.5.5.7.3.1). If it doesn't, IPsec policy validation fails silently — you get 0x00003625.

3. Registry Corruption in the IPsec Keying Module

Rare, but I've seen it on Windows Server 2019. The registry key HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley can become corrupted. You can back it up and delete it:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley" oakley_backup.reg
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley" /f

Then reboot. Windows recreates the key with defaults. This only applies if you've previously tweaked Diffie-Hellman group settings or encryption limits.

How to Prevent This from Coming Back

You can't bulletproof against Windows updates, but you can reduce the odds:

• Stop mixing VPN providers. If you switch from Cisco AnyConnect to native Windows VPN or OpenVPN, reboot in between. The IPsec stack doesn't always flush orphaned policies.
• Don't manually edit IPsec policies. The secpol.msc snap-in makes it too easy to create conflicting rules. Let Group Policy or the VPN client handle it.
• After a major Windows feature update (like 23H2 → 24H2), run netsh ipsec static reset proactively before connecting to any IPsec VPN. I do this on my own machine every feature update and it's saved me twice.
• Monitor the event log for Event ID 4285 (IPsec IKE negotiation failure) and Event ID 4457 (IPsec policy change). If you see a pattern, you'll catch the mismatch before the VPN refuses to connect.

The reset command is your trump card. Use it first, worry about the why later. More often than not, the why is "Windows got confused."