0X000032E1

Fix WARNING_IPSEC_QM_POLICY_PRUNED (0x000032E1) Fast

EP
Erropedia Team
📅 May 26, 2026 📅 Updated Sep 13, 2026 👁 21 views Windows Errors Intermediate
IPSec quick mode policy added but some offers unsupported. Usually mismatched encryption or auth settings. Here's the real fix.

Yeah, I know. You're staring at that IPsec policy you just pushed out, and boom – the log says WARNING_IPSEC_QM_POLICY_PRUNED with that hex code 0x000032E1. It's not a full crash, but it's annoying because your secure tunnel might work partially or not at all. I've seen this on a client's Server 2016 box last month – drove them nuts because their VPN to HQ kept dropping.

The Real Fix: Match Your Quick Mode Offers Exactly

The error literally translates to: the quick mode policy got added, but some offers you listed aren't supported by the other side. Windows just prunes (removes) those offers. If it prunes all of them, no negotiation. Here's how you fix it fast.

  1. Check both sides' quick mode settings. On your Windows machine, open the Windows Firewall with Advanced Security snap-in (run wf.msc). Go to Connection Security Rules, find your rule, and double-click. Click the 'Authentication' or 'Quick Mode' tab – depends on your rule type. Look for the list of IPsec proposals.
  2. Note the exact combination of encryption algorithm (like AES-128, AES-256, or 3DES), integrity algorithm (SHA-1, SHA-256), and key lifetime (in minutes or KB). If you're using ESP, also check if you have AH enabled.
  3. Configure the remote side to accept at least one of your offers. If it's a third-party VPN, go into its IPsec proposal list and add an exact match. For Windows-to-Windows, both machines need the same offers in their quick mode policy. I had a client where the remote firewall only supported AES-256/SHA-1, but Windows default was AES-128/SHA-256. Pruned everything.
  4. If you're using Group Policy (for domain-joined machines), the IPsec settings are under Computer Configuration > Windows Settings > Security Settings > IPsec Security Policies. Edit the policy, go to 'Rule' > 'Quick Mode' and match the proposals.
  5. After adjusting, run gpupdate /force or restart the IPsec service (or reboot). Check the log again – the warning should be gone.

Why This Happens

IPsec negotiation works in two phases. Phase 1 (main mode) sets up the secure channel. Phase 2 (quick mode) negotiates how data is actually protected. When you add a quick mode policy, Windows lists the offers you defined. The remote machine checks each offer. If none match, Windows prunes the unsupported ones. If all offers get pruned, you get this warning. That's it – it's a mismatched proposal list.

Common culprits: using 3DES (old and often disabled on newer gear), SHA-1 (some firewalls now block it), or a key lifetime that's way too short (like 5 minutes). Windows default lifetimes are 480 minutes or 100,000 KB. If you set something weird like 1 minute, the other side might reject it.

Less Common Variations

Sometimes the error pops up even when offers match. Here's what I've seen:

  • ESP vs AH mismatch. You have ESP selected but the other side only does AH, or vice versa. Windows will prune the entire ESP offer. Check the 'Protocol' dropdown in your quick mode settings – use ESP unless you specifically need AH.
  • Certificate filter issue. If you're using certificates for authentication (instead of pre-shared key), the quick mode policy might get pruned if the certificate is invalid or not trusted. I had a case where the root CA wasn't in the remote's trusted store. Fixed by importing it.
  • Windows edition limitations. Windows 10 Home doesn't support IPsec policies at all. If you try to add one, you might see this warning because the feature isn't there. Stick to Pro, Enterprise, or Server editions.
  • NIC offload conflicts. Some network adapters with IPsec offload enabled cause weird pruning. Disable IPsec offload in the NIC properties (under Advanced > IPsec Offload) if you see inconsistent behavior.

Prevention for Next Time

Before deploying a new IPsec policy, do this:

  • List the remote device's supported algorithms from its documentation or admin panel. Then build your quick mode offers around that. Don't just use defaults.
  • Include at least two or three proposals with different algorithm combinations – e.g., AES-256/SHA-256 as primary, AES-128/SHA-256 as fallback, AES-128/SHA-1 if the remote is old. That way if one gets pruned, another might stick.
  • Test in a lab first. Spin up a VM with the same OS and IPsec config. If you see the warning there, fix it before touching production. Saved my bacon with a client's finance data tunnel.

Bottom line: this warning is your IPsec policy being honest. It's telling you, 'Hey, I couldn't use some of these offers.' Listen to it. Match the offers, and the tunnel will work. If it still doesn't, check the firewall logs on both ends – that's where the real story is.

Related Errors in Windows Errors
0X0000077F Fixing ERROR_NO_SITENAME (0x0000077F) on Windows 0X000036EB Fix ERROR_SXS_XML_E_BADPEREFINSUBSET (0x000036EB) 0XC00D272F Fix NS_E_DRM_PARAMETERS_MISMATCHED 0xC00D272F Error 0X80097003 Fix MSSIPOTF_E_NOHEADTABLE (0X80097003) error in Windows
0x000032E1 WARNING_IPSEC_QM_POLICY_PRUNED quick mode policy pruned IPsec policy not supported Windows IPsec error IPsec negotiation failure IPsec offer mismatch fix IPsec policy Windows firewall IPsec IPsec ESP AH settings IPsec phase 2 negotiation server 2016 IPsec error Windows 10 IPsec warning IPsec policy configuration

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.