Fix 0x000032DA: IPSec Main Mode Filter Pending Deletion

Quick Answer (for the impatient)

Run net stop ipsec && net start ipsec in an elevated command prompt. If that doesn't clear it, then netsh ipsec static delete filterlist name=all and reapply your policy.

What's Actually Happening Here

IPSec main mode filters are the rules that say "who can talk to who" and "how they authenticate." When Windows tries to delete a filter but something — usually a pending security association (SA) or a half-broken policy update — keeps it alive, you get error 0x000032DA. I've seen this most often after a failed Group Policy update on a domain-joined machine, or when someone manually edited IPSec policies without restarting the service. One client had a printer server that couldn't communicate with the domain controller because of this exact error — the filter for domain traffic was stuck in limbo.

The real issue: the filter's reference count won't drop to zero. Windows thinks something is still using it, so it won't let go. But in practice, it's already dead — just not cleaned up. That's why restarting the service or wiping stale filters works.

Step-by-Step Fix (Start Here)

Open an elevated command prompt — right-click Command Prompt and choose "Run as administrator."
Restart the IPSec service:
```
net stop ipsec
net start ipsec
```
This usually unblocks it because the service drops all pending operations on restart. Wait 10 seconds, then try your original action again.
If that doesn't work, clear stale filters:
```
netsh ipsec static delete filterlist name=all
```
This wipes all main mode filters. You'll need to reapply your IPSec policy afterward. For domain-joined machines, a gpupdate /force will pull them back. For manual policies, re-import or re-apply.
Check for stuck SAs:
```
netsh ipsec static show all
```
Look for any entries under "Active Security Associations" — if you see one with the same filter name, clear it:
```
netsh ipsec static delete sa
```

Alternative Fixes If the Above Fails

Reboot and pray

Seriously. A cold restart clears the filter table completely. If you can't reboot right now, move to the next option.

Reset the IPSec driver

Run this in an elevated prompt:

net stop ipsec && net stop ikeext && net start ikeext && net start ipsec

The ikeext service (IKE and AuthIP extension) often holds the reference that keeps the filter alive. Restarting it together with ipsec usually does the trick.

Remove the filter via PowerShell

If netsh gives you attitude, try PowerShell:

Remove-NetIPsecMainModeRule -PolicyStore ActiveStore

This removes all active main mode rules. Then reapply your policy. The -PolicyStore ActiveStore flag targets the running rules, not the persistent ones, so it won't mess up your saved config.

Why This Error Happens (So You Can Avoid It)

The main trigger is applying IPSec policy changes without restarting the policy engine. When you update a filter and Windows tries to delete the old one while a security association is still using it — boom, pending deletion. Also common after a failed VPN disconnect or a network interface that goes down mid-handshake.

Had a client whose IPSec tunnel to a remote branch office kept dying every Tuesday at 3 PM. Turned out the weekly Group Policy refresh was overlapping with an active VPN session. The fix: schedule policy updates to happen during maintenance windows, or add a script that disconnects VPNs before gpupdate runs.

Prevention Tips (Do This Once)

Always restart the IPSec service after manual policy edits. It takes two seconds and prevents this headache.
Use gpupdate /force during off-hours if you're domain-joined. Schedule it with Task Scheduler if your IT team lets you.
Keep a backup of your IPSec policies — export them with netsh ipsec static export "C:\backup.ipsec". You'll thank me when you have to wipe and reapply.
Monitor for error 0x000032DA in Event Viewer under Windows Logs > System. If you see it more than once a month, your policy deployment process is broken. Fix it before users notice.

That's it. Go kill that stuck filter.