Cause 1: The quick mode policy is still assigned to a filter action
The number one reason you see 0X000032CA is that you're trying to delete or modify a quick mode policy that's still referenced by an active filter action. Windows won't let you touch a policy that's in use. This often happens when you've set up a VPN or a direct tunnel on a server and then try to clean up old IPsec rules without removing the references first.
For example, you might have a rule that filters between two subnets and uses a quick mode policy named "QM_Office". If you try to delete that policy with netsh ipsec static delete policy, you'll get exactly this error.
How to fix it
You need to find which filter action is using the policy, then either delete the action or reassign a different policy to it. Here's the step-by-step:
- Open an elevated Command Prompt. Click Start, type
cmd, right-click it and choose "Run as administrator". - List all filter actions with this command:
netsh ipsec static show filteraction
Look for any that list your quick mode policy in the "QM Policy" column. - Once you find the culprit, you have two options. If you don't need that filter action anymore, delete it with:
netsh ipsec static delete filteraction name="ActionName"
ReplaceActionNamewith the actual name. - If you still need the action, point it to a different quick mode policy, or create a new one first. To create a new QM policy:
netsh ipsec static add qmpolicy name="QM_New"
Then assign it:
netsh ipsec static set filteraction name="ActionName" qmpolicy="QM_New" - Now try deleting the original policy again:
netsh ipsec static delete qmpolicy name="QM_Old"
If it deletes without error, you're done.
What to expect: After running the delete command, you'll see no confirmation message, but you won't get the 0X000032CA error either. Run netsh ipsec static show qmpolicy to confirm it's gone from the list.
Cause 2: Another rule is using the policy through a filter list
The second most common trigger is that the policy is referenced by a filter list that's still active, even if the filter action itself doesn't show it. This happens when you have multiple rules pointing to the same filter list, and that list references the qm policy indirectly.
I've seen this on domain controllers where someone imported a security template that included IPsec rules. The template creates a filter list that's bound to a specific quick mode policy, and the binding isn't obvious from the filter action properties.
How to fix it
You'll need to check all filter lists and their actions, then remove the reference. Here's the process:
- List all filter lists:
netsh ipsec static show filterlist - For each list, view its details:
netsh ipsec static show filterlist name="ListName" level=verbose
Look for the section that shows which filter action it's bound to, and then check that action's qm policy. - If you find a filter list that uses an action with your qm policy, you can either delete the filter list (if it's not needed) or reassign the action.
- To delete a filter list:
netsh ipsec static delete filterlist name="ListName" - Then try deleting the qm policy again.
What to expect: Sometimes the delete command will hang for a few seconds. That's normal. If it returns to the prompt without an error, the policy is free. You can verify with the show command.
Cause 3: The policy is stored in the persistent policy store
Less common but real: the quick mode policy might be in the persistent IPsec policy store, not the static one. The persistent store is loaded at boot and can't be modified while the system is running. This is rare because most admins use the static store, but it happens if you've used netsh ipsec dynamic or a legacy tool.
You'll know it's this cause if the policy shows up in netsh ipsec static show qmpolicy but you can't delete it even after clearing all references.
How to fix it
You have two options. The clean way is to use the dynamic store to remove it, but that only works if the policy isn't active. If it is active, you'll need to restart the IPsec service first.
- Open Services (services.msc), find "IPsec Policy Agent", right-click and select Restart. This flushes the dynamic store.
- After the service restarts, run:
netsh ipsec dynamic delete qmpolicy name="PolicyName" - If that doesn't work, you can also try disabling the IPsec service entirely, but that's a last resort because it kills all IPsec protection.
What to expect: After restarting the service, the policy might disappear from the dynamic store automatically. If not, the delete command will work without the error.
Quick reference summary
| Cause | Fix | Command(s) |
|---|---|---|
| Policy tied to a filter action | Delete or reassign the filter action | netsh ipsec static delete filteraction or set filteraction |
| Policy referenced by filter list | Delete the filter list | netsh ipsec static delete filterlist |
| Policy in persistent store | Restart IPsec service, then delete | netsh ipsec dynamic delete qmpolicy |
Start with cause 1 because that's what most people hit. If the error still shows up, move to cause 2. Cause 3 is a long shot but I've seen it on Windows Server 2016 and 2019 after a botched migration.
One last tip: always run these commands from an elevated prompt. If you're not elevated, you'll get an access denied error that looks similar but has a different code. And don't forget to check your syntax — a single typo in the policy name will give you a different error too.