Quick answer for advanced users
Open Command Prompt as admin, run netsh ipsec static delete policy name=all and netsh int ipsec reset, then restart the VPN service and reconfigure your connection. That clears the stale queue and forces a fresh negotiation.
Why this happens
You're seeing 0X000035F2 when a Quick Mode (QM) negotiation request sits in the IPsec IKE queue longer than Windows allows. The default timeout is usually 180 seconds. After that, Windows drops the request and logs this error. I see this most often when connecting to corporate VPNs through a congested network, or when the VPN server responds slowly because it's overloaded. Sometimes it's a one-time glitch. Other times it means something's corrupted in your IPsec policy store.
I've fixed this on Windows 10 22H2 and Windows 11 23H2. On Server 2019 and 2022, same deal. The fix doesn't change if it's IKEv1 or IKEv2 — the queue timeout behavior is the same.
Step-by-step fix
Before you start, save any open work. You'll need to restart the IPsec service, which will temporarily drop active VPN connections.
- Open Command Prompt as Administrator. Click Start, type
cmd, right-click Command Prompt, choose Run as administrator. Click Yes on the UAC prompt. - Clear all IPsec policies. Type this and press Enter:
After you run it, you should seenetsh ipsec static delete policy name=allPolicy name=all deleted successfully. If you getNo policy was found, that's fine too — it means your store is already clean. - Reset the IPsec service. Type:
Wait for the messagenetsh int ipsec resetResetting IPsec... OK. This usually takes 2-3 seconds. - Restart the IPsec service. Type:
You'll seenet stop PolicyAgent && net start PolicyAgentThe IPsec Policy Agent service was stopped successfully.thenThe IPsec Policy Agent service was started successfully. - Restart the VPN service. Type:
Again, you'll get stop and start confirmation messages.net stop RasMan && net start RasMan - Reconfigure your VPN connection. Go to Settings > Network & Internet > VPN. Delete your current VPN connection and create a new one with the exact same server address, username, and password.
- Test the connection. Connect to the VPN. If it works, you're done. If you still see the error, move to the alternative fix below.
Alternative fix if the main one doesn't work
Sometimes the IPsec store is fine but the network path has issues. Here's what I'd try next:
- Change the VPN protocol. If you're using IKEv2, switch to L2TP/IPsec or SSTP. Each protocol handles timeouts differently. Right-click your VPN connection in Settings, go to Properties, and change the Type of sign-in info or VPN provider.
- Increase the IKE negotiation timeout. This is registry-level, so be careful. Open Regedit, go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\. Create a DWORD namedNegotiationTimeoutand set it to 300 (decimal). Reboot. This gives the queue 5 minutes instead of 3. - Temporarily disable Windows Firewall on your LAN connection only. I don't love this, but sometimes the firewall interferes with IKE traffic. Right-click your network icon, open Network & Internet settings, Windows Firewall, turn it off for your private network. Test the VPN. Turn it back on after.
Prevention tips
Once you've fixed the immediate error, do these two things:
- Don't let your VPN sit idle. If you're not using the connection, disconnect it. Idle tunnels can trigger the queue drop when you try to renegotiate.
- Update your VPN client software. If you're using a third-party client like Cisco AnyConnect or Pulse Secure, update to the latest version. Older clients sometimes hold onto dead queue entries.
That's it. The 0X000035F2 error is annoying but straightforward once you know what's dropping the ball. Nine times out of ten, clearing the IPsec policy store and restarting the services gets you connected.