ERROR_IPSEC_MM_FILTER_NOT_FOUND (0X000032CF) shows up when the IPsec policy engine can't find a main mode filter it expects. You'll see this most often when you rebuild a VPN or site-to-site tunnel on Windows Server 2016/2019/2022, or when you import an old IPsec policy from a decommissioned box and try to activate it. The filter's supposed to exist. It doesn't. Either it got deleted out from under the policy, or the policy registration is half-broken.
Don't panic and don't start reinstalling anything. Work down the ladder. Stop at the first fix that clears it.
Fix 1 — Restart the IPsec services (30 seconds)
Half the time this is just the Policy Agent (PolicyAgent / IKEEXT) holding a stale in-memory filter list after a config change. A restart of the services forces it to reload from the registry.
Open an elevated PowerShell or cmd and run:
net stop PolicyAgent
net stop IKEEXT
net start IKEEXT
net start PolicyAgentThen retry whatever triggered the error — activating the policy, connecting the VPN, or starting the tunnel.
If you're on a domain controller, expect the restarts to take a few seconds longer and throw a dependency warning on PolicyAgent. That's normal, it's waiting on IKEEXT.
Quick sanity check before you move on: net start | findstr /i "policy ike" should show both services up.
Fix 2 — Identify and remove the orphaned filter (5 minutes)
When a restart doesn't cut it, there's a filter registered in the policy that points at a rule or filter list that no longer exists. This is the classic case after someone edits a policy with netsh ipsec static and deletes a filter list without deleting its child filters, or when you copy a policy between machines and the GUIDs don't line up.
Dump the current IPsec config:
netsh ipsec static show all
netsh ipsec static show filterlist all level=verbose
netsh ipsec static show policy allLook for a filter list with zero filters, or a policy that references a filter list that isn't in the output. That's your orphan.
Kill it with:
netsh ipsec static delete filterlist name="YourFilterListName"
netsh ipsec static delete policy name="YourPolicyName"Rebuild the policy clean instead of trying to surgically patch it. I've wasted way too many hours trying to hand-edit broken filter lists. It's never worth it. Delete and recreate.
Heads up: if the policy is GPO-assigned, deleting it locally will just get overwritten on the next gpupdate. Check gpresult /h gpreport.html first and fix it at the source in Group Policy Management.
Fix 3 — Full IPsec policy store reset (15+ minutes)
Sometimes the local policy store itself is corrupt. You'll know because netsh ipsec static show all throws its own errors, or filters you know exist don't show up.
Before nuking anything, export what you've got so you can diff it later:
netsh ipsec static exportpolicy file=C:\temp\ipsec-backup.ipsecNow clear local policies (this does not touch domain-assigned ones — those come from GPO):
netsh ipsec static delete allIt'll prompt. Say yes. Then restart the services again (see Fix 1). Re-import your known-good export or rebuild the policy from scratch.
If you're dealing with a corrupt registry-level store and netsh still misbehaves, the heavier hammer is to wipe the IPsec policy keys under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent — export them first, because you won't get them back. Then reboot, not just restart services. The IPsec stack reads some of that at boot.
When it's actually a GPO problem
If the error comes back after every gpupdate, stop fighting the local machine. On the domain controller or wherever you manage policy:
- Open Group Policy Management.
- Find the GPO with the IPsec policy.
- Check the Connection Security Rules under Computer Configuration > Windows Settings > Security Settings > Windows Firewall with Advanced Security.
- Look for rules referencing endpoints or certificates that no longer exist — old CA, retired server, expired cert. Delete them and re-create the rule.
Run gpupdate /force on the client and check Event Viewer under Applications and Services Logs > Microsoft > Windows > IKEEXT for whatever it complains about next.
Common triggers, so you know what you're dealing with
| Scenario | Why 0x32CF fires |
|---|---|
| Imported old policy from a decommissioned server | Filter references a GUID that doesn't exist on the new box |
| Edited policy with netsh, deleted a filter list | Child filters orphaned, parent policy still points at the list |
| GPO half-applied after failed gpupdate | Policy shell registered, filters never landed |
| Antivirus or third-party firewall stripped filters | Some endpoint agents rewrite the IPsec store and drop entries |
| Server restored from a snapshot with mismatched config | Registry has policy, IPsec driver state doesn't match |
That last row bites people more than you'd think. Restoring a VM snapshot rolls back the IPsec store but the running IKE state can be from after the snapshot. Restart the services and it usually reconciles.
What not to do
Don't run netsh winsock reset or netsh int ip reset for this. I see people recommend it constantly and it's wrong — those reset the network stack, not IPsec policies, and they'll break your static routes and NIC configs for zero benefit. Same with sfc /scannow. It has never once fixed 0x32CF in my experience. Skip it.
Don't reboot before trying the service restart in Fix 1. A reboot takes three minutes and a service restart takes five seconds, and they do the same thing to the IPsec policy engine.
The fix that holds is always the same: get the policy store back to a consistent state. Either clean out the orphan, or rebuild the policy. Nothing in between is worth your time.