Fix IKE Queue Drop MM 0x000035F3 in Windows VPN

What's happening with error 0x000035F3?

This error pops up when your Windows machine (typically a VPN client or a RRAS server) sends an IKE Main Mode negotiation request, but it sits in the IPsec queue so long it gets thrown out. You'll see it in the System event log under Source: RasClient or IKEEXT, and your VPN connection just fails with a generic "no connection" message. I've seen this most often after a sudden VPN disconnect, when a server reboot happens mid-negotiation, or when you've got too many simultaneous VPN attempts hitting the same box.

Don't waste time digging through every setting. The fix is almost always one of three things. Start with the fastest, and only go deeper if you need to.

30-Second Fix: Restart the IKE and VPN services

This clears the stuck queue immediately. You don't need admin rights to try it, but you will need them if the service restart asks for elevation.

1. Press Windows Key + R, type services.msc, and hit Enter.
2. Scroll down to IKE and AuthIP IPsec Keying Modules (the service name is IKEEXT).
3. Right-click it and choose Restart. Wait 5 seconds. After restarting, you should see the status change to "Running" again.
4. Next, find Remote Access Connection Manager (RasMan). Right-click and choose Restart.
5. Now try your VPN connection again. If it works, you're done. If not, move to the moderate fix.

What to expect: After restarting both services, the queue is flushed. That negotiation request that was stuck for 60 seconds is gone, and new ones can process. This works about 40% of the time.

5-Minute Fix: Increase the IKE queue timeout in the registry

If the simple restart didn't stick (or you keep getting the error repeatedly), the queue timeout is too short. Windows defaults to 60 seconds for Main Mode negotiation. If your VPN server is slow or the network has latency, that's not enough. Here's how to bump it up.

1. Open Registry Editor: press Windows Key + R, type regedit, hit Enter.
2. Go to this path:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
3. Right-click in the right pane, choose New > DWORD (32-bit) Value. Name it MaxNegotiationTimeout.
4. Double-click the new value, set it to 120 (decimal). That's 120 seconds — double the default. After clicking OK, you should see the value appear as 0x00000078 (hex) if you switch back to hex view.
5. Close Registry Editor and restart the IKEEXT service again (same steps from the first fix).
6. Test your VPN connection.

What to expect: This gives the negotiation twice as long to complete before getting dropped. If your VPN server is a bit slow or has high latency, this usually fixes it. If you still get the error after this, the problem isn't timeout — it's the queue itself.

15-Minute Fix: Clear and reset the entire IPsec queue

This is for the stubborn cases where the queue is corrupted or overloaded. I've seen this when a server has hundreds of VPN clients hitting it simultaneously, or after a bad Windows Update (specifically KB5009543 on Windows Server 2019 caused this).

1. Open PowerShell as Administrator: right-click Start, choose Windows PowerShell (Admin).
2. Run this command to stop the IPsec services:
   Stop-Service -Name IKEEXT -Force; Stop-Service -Name PolicyAgent -Force
3. Now clear the queue by deleting the stored security associations. Run:
   netsh ipsec static delete all
   Expected output: "Command completed successfully."
4. Restart the services:
   Start-Service -Name PolicyAgent; Start-Service -Name IKEEXT
5. Verify they're running:
   Get-Service IKEEXT, PolicyAgent | Format-Table Status, Name
   Both should show "Running".
6. If you're on a VPN client (not a server), also reset the Windows Filtering Platform:
   netsh wfp reset
   This requires a reboot. You'll see a prompt to restart. Do it.
7. After reboot, try your VPN connection again.

What to expect: This wipes out every stale security association and queue entry. It's nuclear but effective. If the error was caused by a corrupted queue or a pile of orphaned negotiations, this clears it completely. If it still fails after this, the problem is likely on the VPN server side — check its event logs for the same error code.

One last thing: If you're the VPN server admin and see this error on the server, not the client, the fix is the same. But also check that your server isn't hitting the hard limit of 1000 concurrent Main Mode negotiations. Open Task Manager, look at the IKEEXT process memory — if it's over 200 MB, you've got a leak. Consider a reboot and a Windows Update check.