Fix ERROR_IPSEC_TRANSPORT_FILTER_ENDING_DELETION (0X000032DB)

What's actually happening here

Error 0x000032DB means the IPsec driver can't finish removing a transport filter — it's stuck in a pending deletion state. This usually happens when you've modified or removed an IPsec policy while the system was processing it, or when a Group Policy update left a half-baked rule behind. I've seen this most often on Windows Server 2019 after a failed VPN tunnel teardown, but it can hit Windows 10/11 too.

The driver keeps the filter in limbo, blocking new rule additions and causing IPsec policy agent errors in Event Viewer under System > IPsec. Don't waste time reinstalling drivers — the fix is about flushing that stuck state.

Fix 1: Restart the IPsec service (30 seconds)

The simplest thing you can try. Sometimes the driver just needs a clean slate.

1. Open Command Prompt as Administrator.
2. Run net stop IKEEXT && net start IKEEXT. This restarts the IKE and AuthIP IPsec Keying Modules service.
3. Also run net stop PolicyAgent && net start PolicyAgent to restart the IPsec Policy Agent.

Check if the error clears by trying to add or modify an IPsec rule via netsh ipsec static show policy. If it's gone, you're done. If not, move on.

Why this works sometimes: The PolicyAgent service holds the active filter list. Restarting it forces a re-read of the policy store, which can drop orphaned pending deletions. It fails when the filter is stuck in the driver's internal state, not just the service cache.

Fix 2: Flush and reapply the IPsec policy (5 minutes)

If a restart didn't cut it, we're going to nuke the current policy assignment and reapply it. This forces the driver to release the pending filter.

1. Open Command Prompt as Administrator.
2. Run netsh ipsec static show policy to list all policies. Note the name of the assigned policy (usually something like Secure Server (Request Inbound)).
3. Unassign the policy: netsh ipsec static set policy name="YourPolicyName" assign=no
4. Delete the stuck filter. First find it: netsh ipsec static show filterlist. Then delete: netsh ipsec static delete filterlist name="FilterListName"
5. Reassign the policy: netsh ipsec static set policy name="YourPolicyName" assign=yes

Test your IPsec rules again. If the error reappears or persists, the filter is stuck in the registry itself — proceed to Fix 3.

The gotcha: If you don't know the policy name, check the registry at HKLM\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local. Each GUID there corresponds to a policy. Export that key before deleting anything — I've seen people nuke the entire store and lose all firewall rules.

Fix 3: Clean the registry and WFP store (15+ minutes)

This is the nuclear option. The pending deletion state is stored in the Windows Filtering Platform (WFP) database, which the IPsec driver reads directly. You'll need to wipe that and rebuild.

1. Backup the entire IPsec registry tree: reg export HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent C:\backup_ipsec.reg
2. Open an elevated Command Prompt and stop both services: net stop IKEEXT && net stop PolicyAgent
3. Delete the WFP filter store. This is the part most guides skip: run sc stop wfplwfs (the WFP lightweight filter driver), then delete the file C:\Windows\System32\drivers\wfplwfs.sys — wait, no. Don't delete the driver file. Instead, clear the operational store:
• netsh wfp show filters — note the filter IDs if you have many.
• Delete all IPsec-related filters: netsh wfp delete filters (this removes ALL WFP filters, not just IPsec). This will break Windows Firewall rules temporarily.
4. Now clean the IPsec-specific registry: reg delete HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Policy /f
5. Reboot. After reboot, Windows Firewall will recreate default filters. Run gpupdate /force if your IPsec policies come from Group Policy.

Why step 5 matters: The PolicyAgent\Policy key holds the parsed policy objects. If a filter is stuck pending deletion, its GUID is referenced here but not in the active filter list. Deleting the entire key forces a clean rebuild from the source (local policy or GPO).

Real-world scenario where this is needed: A sysadmin removed a VPN server's IPsec rule via PowerShell's Remove-NetIPsecRule while 20 tunnels were active. The driver marked the filter as pending deletion but couldn't unload it because active SAs referenced it. Same fix applies — clear the policy store, reboot, let SAs die naturally.

When to give up and use a different approach

If none of these work, the issue might be deeper — a corrupted WFP engine. In that case, disable IPsec entirely by setting HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Start to 4 (disabled) and reboot. You'll lose IPsec but gain a working firewall. Then use a third-party VPN or SSH tunnel instead. Not ideal, but practical when your server needs to stay online.