ERROR_IPSEC_TRANSPORT_FILTER_NOT_FOUND (0X000032D1): Fix IPsec Filter Errors

Quick answer: ERROR_IPSEC_TRANSPORT_FILTER_NOT_FOUND (0X000032D1) means Windows tried to remove or modify an IPsec transport filter that no longer exists — usually after a policy was deleted, a machine was restored from an image, or a firewall tool already cleaned up the filter underneath you.

You'll see this most often when a script or Group Policy is trying to tear down an old IPsec rule that's half-gone. The filter record in the IPsec driver doesn't match what the policy database thinks is there. Classic trigger: you restore a VM from a snapshot taken before an IPsec policy change, then a domain GPO re-applies the old policy and tries to delete filters that were never created on this instance. The GUI tool reports "The specified transport mode filter does not exist" and the operation bails out. Same thing happens after a botched netsh ipsec static delete policy that removed the policy object but left filter entries orphaned in the driver.

Two things are going on. The persistent policy store and the active IPsec driver state are out of sync. Cleaning one without the other leaves you stuck. The fix is to flush both sides, then reapply the policy cleanly.

Before you start

You'll need an elevated Command Prompt or PowerShell. Back up any custom IPsec policies first — if you're using domain-assigned policies, note the GPO name so you can reapply it. On a domain controller or a machine with critical IPsec tunnels, plan a maintenance window. Restarting the IPsec service drops existing security associations and any active tunnels will need to renegotiate.

Step-by-step fix

Step 1: Stop the IPsec services

Open Command Prompt as Administrator (right-click, Run as administrator). Stop the two services that manage IPsec state:

net stop PolicyAgent
net stop IKEEXT

You should see "The Policy Agent service was stopped successfully" and the same for IKE and AuthIP IPsec Keying Modules. If either is already stopped, that's fine — move on.

Step 2: Export your current IPsec configuration

Don't skip this. Even if you think there's nothing to save, export it. If something goes wrong later, you'll want a rollback point:

netsh ipsec static exportpolicy "%USERPROFILE%\Desktop\ipsec-backup.ipsec"

You should get a message that the policy was exported successfully. Check your desktop — the file should be there, typically a few KB in size.

Step 3: List the offending filters

See what Windows thinks is still around:

netsh ipsec static show filterlist name=all level=verbose

You'll get a wall of output. Look for filter entries whose policy is missing or whose name has odd characters. Any filter listed here that belongs to a policy you already deleted is a candidate for cleanup. Note the filter name and policy name — you need both.

Step 4: Delete each orphaned policy

For every policy that showed up with orphaned filters, run:

netsh ipsec static delete policy name="PolicyName"

Replace PolicyName with the actual name from Step 3. Wrap it in quotes if it has spaces. You should see "The command completed successfully." If you get ERROR_IPSEC_TRANSPORT_FILTER_NOT_FOUND here, that's actually the point — the policy is half-deleted. Move to Step 5.

Step 5: Reset the IPsec policy store

When deletion keeps failing with 0X000032D1, wipe the persistent store entirely. This clears all local IPsec policies. Domain GPOs will re-apply on next refresh, which is usually what you want anyway:

netsh ipsec static delete all

Expected output is "The command completed successfully." If it returns the 0x32d1 error again, the driver state is the problem, not the store. Keep going.

Step 6: Restart the IPsec services

Bring the driver back up so it releases any stale filter handles:

net start PolicyAgent
net start IKEEXT

Both services should report they started successfully. If PolicyAgent fails to start, check Event Viewer under Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security. The exact subcode in the event will tell you if a specific filter is still wedged.

Step 7: Reapply your policy

If you saved a backup in Step 2 and need it back:

netsh ipsec static importpolicy "%USERPROFILE%\Desktop\ipsec-backup.ipsec"

Then confirm with netsh ipsec static show policy name=all. You should see your policy listed with no errors. Test your tunnel or application that needed IPsec — it should negotiate fresh.

If that didn't work

Sometimes the filter lives in the Windows Firewall with Advanced Security layer, not the legacy IPsec store. Check via PowerShell:

Get-NetIPsecRule | Where-Object { $_.DisplayName -like "*orphan*" }
Get-NetIPsecMainModeRule
Get-NetIPsecQuickModeRule

Remove any rule that references a policy you've already deleted:

Remove-NetIPsecRule -DisplayName "RuleName" -Confirm:$false

If the rules won't budge, the filter is stuck in the driver. A reboot is the least invasive cleanup — the IPsec driver rebuilds its filter tables from scratch at boot. Do a clean restart, not a fast startup shutdown. On Windows 10 and 11, hold Shift while clicking Shut down, or run:

shutdown /r /t 0

Last resort for stubborn instances: reset the Windows Firewall and IPsec stack together. This nukes every rule, not just IPsec, so only do it on a machine where you can rebuild the firewall config:

netsh advfirewall reset
netsh ipsec static delete all

Preventing this next time

You can't apply 0X000032D1 to a filter that never existed. The trigger is almost always a partial state — a snapshot restore, a script that died halfway, or two management tools fighting over the same policy. Pick one tool and stick with it. If you manage IPsec through Group Policy, don't also script netsh ipsec against the same machines. If you do script it, wrap every create/delete pair in a check:

netsh ipsec static show policy name="MyPolicy" >nul 2>&1
if errorlevel 1 ( echo Policy not present, skipping delete ) else ( netsh ipsec static delete policy name="MyPolicy" )

After any snapshot restore on a machine with IPsec, run netsh ipsec static delete all before letting GPO reapply. It's a five-second step that saves twenty minutes of chasing ghost filters. And keep IPsec policy changes out of the same maintenance window as firewall rule changes — when both go sideways you can't tell which one broke first.