Fix IPSec IKE Negotiation Pending 0x35EB

The 30-Second Fix: Flush the Stale Security Association

You're seeing ERROR_IPSEC_IKE_NEGOTIATION_PENDING (0x000035EB) and the VPN won't connect. The culprit here is almost always a stale IKE security association (SA) that's still in the negotiating state. It happens when you interrupt a connection, reboot the VPN client mid-handshake, or the remote peer times out but Windows doesn't.

Don't bother restarting the whole machine yet. Open an admin PowerShell or Command Prompt and run this:

netsh ipsec static delete all

That nukes every SA and filter. Then try your VPN connection again. It clears the stuck state in seconds. If it works, you're done. If not, move to the next step.

The 5-Minute Fix: Restart the IKEEXT Service and Clear the Policy Store

If flushing SAs didn't cut it, the IKE service itself might be holding onto a bad negotiation context. The IKE and AuthIP IPsec Keying Modules service (IKEEXT) needs a full restart.

Open an admin Command Prompt.
Stop the service: net stop IKEEXT & sc query IKEEXT — wait until it shows STOPPED.
Clear leftover policies: sc stop PolicyAgent & sc start PolicyAgent
Start IKEEXT again: net start IKEEXT

Now flush again for good measure:

netsh ipsec static delete all

Retry the VPN. I've seen this fix the issue on Windows 10 22H2 and Server 2019 when a mismatched PSK or certificate renewal left an orphaned negotiation. The order matters — kill IKEEXT first, then PolicyAgent, then start them in reverse. Skipping PolicyAgent restart means the base IPsec driver might still have stale rules.

The 15+ Minute Fix: Rebuild the IPsec Policy and Check the Registry

If you're still stuck, the problem is deeper. Either Group Policy pushed a conflicting IPsec rule, or the registry has a corrupted security association database. Here's the nuclear option.

Step 1: Delete the Stored SA Database

Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec in regedit. Look for a key called ActiveSAs or SpiTable — if it exists, delete it. Don't mess with other keys in there.

Step 2: Clear Group Policy IPsec Settings

Open an admin command prompt and run:

gpupdate /target:computer /force
netsh ipsec static set policy name=""

That forces a GP refresh and resets any local IPsec policy. If your VPN relies on Windows Firewall with Advanced Security, check that the connection security rules aren't duplicated — that's a common cause of negotiation loops.

Step 3: Verify IKE Auth Payload

This error also fires when the IKE initiator sends a certificate but the responder expects preshared key, or vice versa. Enable verbose logging:

netsh wfp capture start
(trigger the VPN connection)
netsh wfp capture stop

Open the generated wfpdiag.cab and look for IKE_INIT or IKE_AUTH failures. The log will show you exactly which authentication method mismatch caused the pending state. It's not pretty reading, but it's precise.

When to Call the Network Team

If none of this works, the remote VPN gateway might be misconfigured. Common causes: NAT traversal disabled on the server side, or the IKE lifetime is shorter on the server than the client. Check the firewall logs on the peer — if you see repeated Quick Mode proposals being rejected, that's your smoking gun.

Pro tip: On Windows Server 2016 and later, the Set-VpnAuthProtocol PowerShell cmdlet lets you force IKEv2 or adjust encryption transforms. Run Get-VpnConnection first to see what your client is actually sending.

That's it. Start with the 30-second flush, escalate as needed. Nine times out of ten, the stale SA is your only problem.