Quick answer: delete the PolicyLGText value under HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent and restart the IPsec service — that clears the stale DOI cache.
What's actually happening here is your Windows machine is trying to establish an IPsec Security Association with a remote gateway (often a VPN concentrator or a router doing NAT-T), and the IKE negotiation packet it receives carries a DOI that the local IKE engine doesn't recognize. DOI stands for "Domain of Interpretation" — it's a numeric field in the ISAKMP header that tells both sides which protocol family they're speaking. The only DOI defined for IPsec is 1 (IPsec DOI). When you see 0x3626, the other side sent something else, or your own Policy Agent got corrupted and is sending garbage itself.
I've seen this on Windows 10 21H2 and Windows 11 22H2, mostly with customer VPN clients (Cisco AnyConnect, Pulse Secure, or even built-in L2TP/IPsec) after a sleep/wake cycle. The Policy Agent service sometimes holds onto a stale policy blob that references an old DOI value, and it only breaks on the next rekey. The fix below clears that state.
Fix 1: Clear the Policy Agent registry cache
- Open
regeditas administrator. - Go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent. - Look for a value named
PolicyLGText. If it exists, right-click it and delete it. - Close regedit.
- Open an elevated Command Prompt and run:
net stop PolicyAgent && net start PolicyAgentThe reason this works is that PolicyLGText stores the last negotiated policy text, including the DOI field. When it gets stale or corrupted, the IKE engine reuses it and sends an invalid DOI in the next negotiation. Deleting it forces the service to rebuild the cache from scratch. You might need to re-establish your VPN connection afterward — that's expected.
Fix 2: If the registry value isn't there — restart the service and flush DNS
Sometimes the cache isn't in the registry. The IKE engine also keeps an in-memory database of active SAs. A clean restart of both the IPsec service and the Base Filtering Engine (BFE) usually wipes that.
- Run as admin:
net stop BFE
net stop PolicyAgent
net start BFE
net start PolicyAgent
ipconfig /flushdnsOrder matters here. BFE is a dependency for PolicyAgent, so stopping BFE first kills the whole IPsec stack. Reversing the start order makes sure the firewall engine is ready before the IKE service boots up. I've had cases where just stopping PolicyAgent didn't clear the bad SA because BFE still held a reference to the old policy.
Alternative fix: Update your network driver
If the above doesn't do it, the problem isn't the IKE stack — it's the network adapter driver mangling the ISAKMP packets. This is more common with Realtek and older Intel wireless chips. A driver that doesn't handle large UDP packets properly (or has broken checksum offloading) can corrupt the IKE header, making the DOI field look wrong to the remote side.
Go to your adapter's manufacturer site, download the latest driver, and install it. Don't rely on Windows Update — it often gives you an older, generic driver. For Intel, use their Driver & Support Assistant. For Realtek, check the chip's exact model via Device Manager.
Prevention: Disable RSS and large send offload
Once you've fixed the immediate error, you can stop it from coming back by turning off Receive Side Scaling and Large Send Offload on the adapter. Both features can cause packet reassembly issues with IKE, especially over VPN tunnels. In ncpa.cpl, right-click your adapter, go to Properties, then Configure, then the Advanced tab. Set:
- Receive Side Scaling → Disabled
- Large Send Offload (IPv4 and IPv6) → Disabled
- Checksum Offload on receive → Disabled (if it's present)
These are per-adapter, so if you use multiple networks (Wi-Fi and Ethernet), repeat on each. The performance hit is negligible for most workloads — you'll only notice a few MB/s difference on gigabit connections, and that's a fair trade for stable IPsec VPNs.
One last thing: if you're using a third-party VPN client, check for an option to enable "Force IPsec" or "Use legacy IKE" in its settings. Some clients default to IKEv2 but send an old ISAKMP DOI when the server doesn't negotiate properly. That's a client bug, but the registry fix above still works because it resets the local state that the client relies on.
If you're still stuck after all this, the problem is almost certainly on the remote end — their IKE daemon is misconfigured and sending an invalid DOI. You can confirm with a packet capture: open Wireshark, filter for isakmp, and look at the DOI field in the Security Association payload. If it's not 1, it's the server, not you.