ERROR_IPSEC_IKE_OUT_OF_MEMORY (0x3623) Fix

You're mid-VPN session, transferring a file, and the tunnel just dies. Event Viewer shows ERROR_IPSEC_IKE_OUT_OF_MEMORY (0x3623). Or worse, your site-to-site tunnel between two offices flaps every few hours. The trigger is almost always the same: a spike in concurrent IKE negotiations, or a leaked allocation in the IKE service that never releases. I've seen this on Server 2016 boxes running RRAS with 200+ remote clients, and on Windows 10 workstations where a buggy VPN client was leaking nonpaged pool.

What 0x3623 actually means

IKE (Internet Key Exchange) is the protocol that builds and maintains the IPsec tunnel. When it needs to allocate memory for a new security association (SA), it asks the kernel pool. If that allocation fails, you get 0x3623. The message is blunt: "Not enough storage is available to complete this operation."

Root cause is one of three things:

Nonpaged pool exhaustion. IPsec runs in kernel mode, so it draws from nonpaged pool. If another driver is eating it, IKE starves.
SA leak. Old security associations aren't being torn down. Each one holds memory. After a few thousand, you're done.
Concurrent negotiation storm. A misconfigured client or a DDoS of IKE packets forces the service to allocate faster than it can free.

The fix, in order

Check nonpaged pool right now. Open Performance Monitor and add Memory\Pool Nonpaged Bytes. If it's above 400 MB on a 64-bit server, that's your smoking gun. Use poolmon (from the WDK) sorted by nonpaged pool to find the tag eating it. IPsec's tag is usually Ipse or Ikee.
Restart the IKEEXT service. It won't fix a leak, but it clears the immediate error so you can keep working. From an elevated prompt:
```
net stop ikEEXT
net start ikEEXT
```
Note: this kills every active IPsec tunnel on the box. Warn users first.
Raise the SA limit. By default, Windows allows a finite number of IPsec SAs. Bump it via registry. Go to:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Parameters
```
Create a DWORD called MaxNumSAs and set it to 5000 (decimal). Reboot or restart PolicyAgent.
Update your NIC driver. This is the one people skip and it's often the actual fix. Intel PRO/1000 and some Broadcom NetXtreme drivers from 2018–2020 had a nonpaged pool leak when IPsec offload was enabled. Grab the latest from the vendor, not Windows Update.
Disable IPsec task offload if the driver's buggy. In Device Manager, open the NIC, Advanced tab, set IPsec Offload to Disabled. Reboot. This forces the CPU to handle IPsec, which is slower but won't leak.
Audit for SA leaks. Run this in PowerShell to see current SAs:
```
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA
```
If the count keeps climbing while tunnels are idle, you've got a leak. The culprit is usually a third-party VPN client (old Cisco AnyConnect, older FortiClient) or a stale RRAS config.

If it still fails

Check the IKEEXT trace. Enable it with:

netsh trace start scenario=NetConnection provider=Microsoft-Windows-IKEEXT capture=yes tracefile=C:\ike.etl

Reproduce the error, stop the trace, and open the ETL in Event Viewer or Network Monitor. You'll see exactly which allocation call returned STATUS_INSUFFICIENT_RESOURCES.

Also check for a third-party filter driver hooked into the IPsec stack. Anything from a personal firewall (older Comodo, ZoneAlarm) to a VPN accelerator can sit in that path and eat pool. Remove it, reboot, retest.

Last resort: if this is a single machine and the pool numbers look insane, you're dealing with a kernel leak. Run verifier /standard /driver yourvpn.sys and let Driver Verifier catch it. It'll bugcheck on the leak instead of letting it silently eat memory. Sounds harsh, but it pinpoints the offender in minutes.