Fix ERROR_IPSEC_IKE_PROCESS_ERR_SA 0X00003606

You're hitting ERROR_IPSEC_IKE_PROCESS_ERR_SA (0X00003606) and it's a pain

I get it — you're trying to connect to a VPN or set up an IPsec tunnel, and Windows throws this cryptic error. The error means the IKE (Internet Key Exchange) process failed when handling the Security Association (SA) payload. This usually happens after a policy change, a reboot, or a failed VPN attempt that left the IPsec service in a weird state. Let's fix it fast.

The real fix: Reset the IPsec service and clear the policy

Skip all the registry edits and service restarts you might have seen. The most reliable way to clear this error is to reset the entire IPsec policy store and restart the service. Here's the exact step-by-step:

Open an elevated Command Prompt. Press Win + X, then choose Terminal (Admin) or Command Prompt (Admin). You need admin rights for this.
Stop the IPsec service. Type this and press Enter:
```
net stop IKEEXT
```
You should see a message: The IKE and AuthIP IPsec Keying Modules service was stopped successfully. If it's already stopped, that's fine.
Clear the IPsec policy. Type this command and press Enter:
```
netsh ipsec static delete policy name=all
```
This removes all static IPsec policies. You'll see no output if it works — that's normal.
Clear the quick mode policy too. Type:
```
netsh ipsec static delete qmpolicy name=all
```
Again, no output means success.
Clear the main mode policy. Type:
```
netsh ipsec static delete mmpolicy name=all
```
Same — no output is good.
Restart the IPsec service. Type:
```
net start IKEEXT
```
You'll see: The IKE and AuthIP IPsec Keying Modules service was started successfully.
Reboot your PC. This isn't optional — the IPsec service caches some state that only clears with a full reboot. After the reboot, try your VPN or IPsec connection again.

Expected outcome after the fix

When you reconnect, you should see the error disappear. The VPN tunnel or IPsec connection will negotiate fresh SAs without the corrupted payload. If you still get the error, move on to the less common causes below.

Why this works

The 0X00003606 error is almost always a stale or corrupted Security Association payload. Think of it like a broken handshake — the IKE process tries to match the SA from the remote server with what's stored locally. If the local policy has a mismatch (wrong encryption algorithm, expired key, or leftover from a failed negotiation), the process fails with this error. By deleting all policies, you force Windows to build new SAs from scratch when you reconnect. Restarting the service ensures no old state lingers. The reboot is the final cleanup.

I've seen this fix work on Windows 10 (all versions from 1809 to 22H2) and Windows 11 (21H2 and later). It also works on Windows Server 2016 and 2019 when you get the same error in a server-to-server IPsec setup.

Less common variations of the same issue

If the basic reset doesn't work, you might be dealing with one of these:

1. Corrupt IPsec policy store (needs deeper cleanup)

Sometimes the policy store itself gets corrupted. In that case, run these additional commands after step 3 above:

netsh ipsec static set store location=local
netsh ipsec static set store location=registry

This resets the store location to default. Then repeat steps 2 through 7 from the main fix.

2. Third-party VPN software left junk behind

I've seen this happen with Cisco AnyConnect, Palo Alto GlobalProtect, and even older built-in VPN clients. They install their own IPsec policies that conflict. Uninstall the third-party VPN software completely, reboot, then run the main fix. After that, reinstall the VPN client — it'll create fresh policies.

3. Windows Defender Firewall or other firewall blocking IKE ports

The IKE process uses UDP ports 500 and 4500. If something blocks them, the SA negotiation never completes. Run this command to check:

netsh advfirewall firewall show rule name=all | findstr /i "500 4500"

You should see rules allowing traffic on those ports for the IPsec service. If not, reset the firewall to default:

netsh advfirewall reset

Then retry the connection. Be aware this resets all custom firewall rules — you'll need to re-add any you had.

4. Time sync issue between peers

IPsec uses timestamps in the SA negotiation. If your system clock is more than 5 minutes off from the remote server, the payload gets rejected. Check your time:

w32tm /query /status

If it shows a large offset, resync:

w32tm /resync

Then try the connection again.

How to prevent this in the future

Once you're back online, take these steps to avoid seeing 0X00003606 again:

Don't mix multiple VPN clients. Running two IPsec-based VPN clients simultaneously is asking for trouble. Uninstall one before installing another.
Keep your system clock synced. Enable automatic time sync in Settings > Time & Language > Date & Time. Set it to sync weekly.
After a failed VPN attempt, wait 30 seconds before retrying. This gives the IPsec service time to clean up the old SA state. Rushing it causes the corruption that triggers this error.
If you use static IPsec policies (advanced setups), document them. When they get corrupted, you'll need to rebuild them from scratch. Keep a text file with the netsh ipsec static add policy commands you use.

That's it. You should be up and running now. If you still see the error after all this, check with your VPN administrator — the issue might be on the remote server side, with mismatched encryption algorithms or expired certificates.