0x000035F1 IPsec IKE MM Acquire Drop – queue timeout fix

You're setting up a site-to-site VPN between two Windows servers, or maybe a client's remote access VPN. Everything looks right in the firewall rules and IPsec policies. But connections fail. Event Viewer gives you ERROR_IPSEC_IKE_MM_ACQUIRE_DROP (0x000035F1) – 'The negotiation request sat in the queue too long.'

I saw this one last month on a Server 2019 box that was also running Hyper-V. The IKE negotiation request got queued, but the IPsec service couldn't process it fast enough. The default queue depth is tiny – 5 requests. If more than 5 come in during a busy window, the oldest one gets dropped with this error.

What's actually happening

The IKE main mode (MM) negotiation uses a queue to hold incoming requests while the service works through them. The queue has a hard limit. Once it's full, new requests sit around until they time out. The default timeout for that queue is 5 seconds. If the IPsec service is bogged down – maybe it's waiting on a certificate lookup, or the server's CPU is pegged – the request expires before it gets processed.

Common triggers:

A server under heavy load (Hyper-V hosts are notorious for this)
Multiple VPN connections trying to establish at the same time (like after a reboot)
Slow certificate validation or DNS resolution
A network hiccup that causes retransmissions to pile up

The fix is simple: increase the queue depth and timeout. You do it through the registry. No third-party tools needed.

Step-by-step fix

Open Registry Editor as Administrator. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\. If there's no PolicyAgent key under Services, the service isn't installed – but it should be on any Windows machine that supports IPsec.
Create the key for queue parameters. Right-click on the PolicyAgent key, select New > Key, and name it Oakley. Yes, 'Oakley' – that's what Microsoft called the IKE engine internally.
Add two DWORD values under the Oakley key:
- MmAcquireQueueSize – set it to 50 (decimal). This is the max number of queued IKE requests. 50 is safe. On a really busy server you can go to 100, but don't go crazy – 50 is plenty for most.
- MmAcquireTimeout – set it to 60 (decimal). This is the timeout in seconds. 60 seconds gives the service time to breathe if it's under load. Some old docs say 15 seconds, but I've had better luck with 60.
Restart the IPsec service – or the whole server if you can't afford to break connections. To restart the service cleanly, open an admin command prompt and run:
```
net stop PolicyAgent && net start PolicyAgent
```
This will drop all existing IPsec connections. So schedule it during a maintenance window.
Test the VPN connection again. If you're using a manual IPsec policy, trigger a renegotiation. For a Windows RRAS VPN, restart the Routing and Remote Access service too – sometimes it holds stale state.

If it still fails after the fix

Sometimes the queue change alone isn't enough. Here's what else to check:

CPU or memory exhaustion. Open Task Manager and look for anything eating resources. I once found a runaway antivirus scan that was locking up the IPsec service. Disabled real-time scanning on the VPN interface and the problem went away.
Certificate revocation list (CRL) issues. If your IPsec policy uses certificates, the service might be hanging on a CRL check that's timing out. Turn off CRL checking temporarily to test: certutil -setreg chain\ChainCacheResyncFiletime @now (then restart PolicyAgent). If that fixes it, your CRL server is the real problem.
DNS resolution for peer names. If your IPsec policy references a machine by name, a slow DNS lookup can add to the queue. Stick to IP addresses in the policy when possible.
Antivirus or firewall software. Some third-party security software intercepts IPsec traffic. Had a client using Trend Micro that was causing this exact error. Uninstalling it (not just disabling) fixed it instantly.

One more thing: check if you're running out of non-paged pool memory. Run poolmon -b and look for large allocations tagged 'Ipsec' or 'Ndis'. If it's climbing, you've got a leak – probably a driver issue. Update your NIC drivers and any VPN adapter software.

Most of the time, the registry tweak above is all you need. I've used it on dozens of servers and never had to go further. Just remember: restarting PolicyAgent kills active connections. Plan for it.