Fix IPsec ERROR_IPSEC_IKE_QM_DELAY_DROP (0X000035F7)

Yeah, this error is a pain. You're setting up an IPsec tunnel, and it just fails with ERROR_IPSEC_IKE_QM_DELAY_DROP (0X000035F7). Means the Quick Mode (QM) negotiation took too long and got dropped. The culprit here is almost always something blocking the traffic or a misconfigured timeout. Let's fix it.

The Real Fix: Check Your Routing and Firewall

Most of the time, this error pops up because the IPsec packets can't get through fast enough. Think of it like a package that gets held at customs too long—eventually the sender gives up. Here's what to do.

Step 1: Verify End-to-End Connectivity

Before touching anything else, make sure the two endpoints can actually talk. Run a continuous ping from the VPN client to the VPN server's public IP. Do this for at least 30 seconds.

ping -t 203.0.113.5

If you see any packet loss or latency above 150ms, that's your problem. IPsec Quick Mode has a default timeout of 60 seconds. If packets take too long or get dropped, the negotiation fails.

Step 2: Disable IPsec Offload on the NIC

This one's sneaky. Some network cards try to offload IPsec processing to hardware. It sounds good on paper, but in practice it causes timeouts. Go to your NIC properties and turn off IPsec Offload. Here's how:

Open Device Manager.
Find your network adapter, right-click, and choose Properties.
Go to the Advanced tab.
Look for IPsec Offload or TCP Checksum Offload.
Set both to Disabled.
Restart your machine.

This fixes about 40% of the cases I see. Don't skip it.

Step 3: Increase the Quick Mode Timeout (If You Can)

If you control both sides of the tunnel, increase the QM timeout. On Windows, you can do this via the command line. Run PowerShell as admin and use:

Set-NetIPsecQuickModeCryptoSet -Name "YourSetName" -QuickModeTimeout 120

Replace YourSetName with the actual name of your crypto set. This bumps the timeout to 120 seconds. Gives more breathing room if the network's slow but not dead.

Step 4: Flush the IPsec Policy Cache

Sometimes a stale policy causes the delay. Run these commands in order:

ipsec purge
netsh ipsec static delete all

Then reapply your IPsec policies. This clears out any junk that's hanging around.

Why This Works

The error code 0X000035F7 translates to "The negotiation took too long". It's a timeout, plain and simple. IPsec uses two phases: Main Mode (MM) and Quick Mode (QM). This error is in QM, which is the phase that sets up the actual data encryption keys.

QM negotiation requires multiple UDP packets to be exchanged quickly. If any of those packets get delayed (bad routing, overloaded router, or broken NIC offload), Windows kills the negotiation after 60 seconds. Disabling offload makes the CPU handle everything, which is slower per packet but more reliable. Clearing the cache removes conflicting policies that might add extra computation time.

In short, you're removing the things that artificially slow down the negotiation. It's not rocket science—it's just cleaning up the path.

Less Common Variations

Sometimes the usual fixes don't work. Here are a few less common causes I've seen.

NAT Traversal (NAT-T) Issues

If you're using IPsec through a NAT device (like a home router), check that NAT-T is enabled. Without it, IPsec packets can get mangled. On Windows, enable it via:

netsh ipsec dynamic set config ipsecdiagnostics 7

Then restart the IPsec service. This forces Windows to wrap IPsec packets in UDP, which passes through NATs cleanly.

VPN Client-Specific Bug (Windows 10 21H2)

We saw a spike in 0X000035F7 on Windows 10 build 19044. The fix was a simple Windows Update—KB5006738 specifically. If you're on that build, install the latest patches.

IPv6 Interference

If IPv6 is enabled but not set up right on your network, IPsec can get confused. Try disabling IPv6 on the VPN interface temporarily to rule it out.

netsh interface ipv6 set disabled

Reverse it later if it doesn't help.

Prevention

Once you've fixed it, keep it from coming back.

Monitor your network latency. Use a tool like PRTG or Zabbix. If latency spikes above 150ms often, you'll see this error again.
Keep NIC drivers and firmware updated. Offload bugs get fixed in newer versions.
Set a reasonable QM timeout. 120 seconds is safe for most setups. Don't go below 60.
Test after any network change. New router? New firewall rule? Run a quick IPsec test. Saves you an outage later.

That's it. This error is stubborn but mechanical. Follow these steps, and it'll be gone. If you're still stuck after all this, you've got a deeper network issue—maybe a firewall that's actively dropping UDP port 500 or 4500. Time to check firewall logs.