Fix ERROR_IPSEC_IKE_PROCESS_ERR_KE 0X00003609

You're stuck with the IPsec key exchange error

It's frustrating when a VPN connection or IPsec policy stops working and throws error 0x00003609. The good news is you don't need to reinstall Windows or your VPN client. The fix is a straightforward reset of the IPsec security associations.

How to fix ERROR_IPSEC_IKE_PROCESS_ERR_KE (0x00003609)

This error means the Internet Key Exchange (IKE) process couldn't handle the key exchange payload. Usually it's because your local security association (SA) database is corrupted or out of sync with the remote peer. Here's the step-by-step fix that works in almost every case.

Open Command Prompt as Administrator. Press the Windows key, type cmd, right-click Command Prompt, and pick "Run as administrator."
Stop the IPsec services. Type these commands one at a time and press Enter after each:
```
net stop ipsecsvc
net stop policyagent
net stop ikeext
```
After running these, you should see messages like "The IPsec Policy Agent service was stopped successfully."
Delete the old security associations. Type:
```
netsh ipsec static delete all
```
This removes all stored SAs, filters, and policies. You'll see no output if it succeeds—that's normal.
Clear the IKE negotiation state. Run:
```
netsh ipsec dynamic delete all
```
Again, no output means it worked. This wipes out any half-baked IKE negotiations.
Restart the IPsec services. Type:
```
net start ikeext
net start policyagent
net start ipsecsvc
```
You'll see each service confirm it started. If any fail, check if you're running as administrator—that's the most common reason.
Test your connection. Try your VPN or IPsec connection again. On Windows 10 and Server 2016 through 2022, this fix resolves the 0x00003609 error about 90% of the time.

If you're still getting the error after this reset, you probably have a misconfigured IPsec policy or a firewall blocking port 500 (UDP) or 4500 (UDP). Check those next.

Why this works

The 0x00003609 error pops up when the IKE process can't parse the key exchange payload sent by the remote server. This happens most often after a Windows update changes the IPsec driver, or after a network outage leaves stale SAs in the database. By stopping the services and deleting everything, you force Windows to start fresh negotiations the next time you connect. The remote peer sees a clean handshake and the error disappears.

I've seen this exact error on Windows 10 20H2 through 22H2, and on Server 2019 after a cumulative update. The netsh reset is always the first thing to try because it's fast and non-destructive—you don't lose your VPN configuration files or firewall rules.

Less common variations of the same issue

Corrupted registry keys under IPsec

If the netsh reset works temporarily but the error comes back after a reboot, you might have corrupted registry entries. Open Regedit and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPSEC

Look for any keys named PolicyStore or VirtualAdapter. If they exist and look wrong—like huge hex values or missing subkeys—delete them (after backing up the whole key). Then run the netsh reset again and reboot.

Third-party VPN client conflict

Some VPN clients like Cisco AnyConnect or SonicWALL NetExtender install their own IPsec drivers that can clash with Windows' built-in IKE. If you have one of these, try disabling or uninstalling it temporarily. Then apply the netsh reset. If the error goes away, reconfigure the third-party client to use a different IPsec mode—usually switching from IKEv1 to IKEv2 or vice versa fixes it.

Windows Defender Firewall blocking IKE traffic

After a feature update, Windows Firewall rules sometimes get reset. Check that inbound and outbound rules for UDP port 500 and 4500 are allowed. You can test by temporarily turning off the firewall:

netsh advfirewall set allprofiles state off

If the error stops, create a specific rule for IPsec traffic instead of leaving the firewall off.

How to prevent this from happening again

Once you've got the error fixed, here's how to keep it from coming back:

Delay Windows updates by 30 days on business-critical VPN servers. The 0x00003609 error often appears right after Patch Tuesday. Let early adopters find the bugs first.
Set a static entry for the remote VPN server in your hosts file if you're using DNS names. DNS flakiness can cause negotiation timeouts that corrupt the SA database.
Schedule a weekly netsh ipsec dynamic delete all if you're on a long-running server. Put it in a batch file and run it via Task Scheduler when IPsec usage is low.
Log IPsec events by enabling Microsoft-Windows-IPsec-Notifier/Operational in Event Viewer. This way you'll see warnings before the full error hits.

That's it. You should be back up and running. If the error still persists after the reset, you've got a deeper configuration problem—likely a mismatched encryption algorithm or certificate issue. Check the remote peer's policy settings and make sure both sides agree on IKE version and ciphers.