The 30-Second Fix: Check Your IPSec Policy Offers
This error means Windows added your main mode policy, but then went “nope” on some of the offers inside it. Most of the time, it's because you're trying to use an encryption or hash algorithm the machine just doesn't support.
Open an admin PowerShell and run:
netsh ipsec static show policy allLook at the output. You'll see something like “Main Mode: SHA-1, 3DES” – if those are in there, that's your problem. Windows 10/11 with recent updates dropped 3DES and MD5 for IPSec. Had a client last month whose print server kept dropping connections because Group Policy was pushing a policy with MD5. Took me longer than I'd like to admit to spot it.
If you see deprecated algorithms, you need to edit the policy. But first, check if you're even using Group Policy or local policy. Run:
gpresult /r | findstr IPsecIf it says “IPsec Policy from GPO”, you need to talk to whoever manages Group Policy. If it's local, you can change it yourself.
The 5-Minute Fix: Update the Policy Offers
If you're using local IPSec policy, here's how to fix it. Hit Win + R, type secpol.msc, and press Enter. That opens the Local Security Policy snap-in.
Navigate to Security Settings > IPsec Policies on Local Computer. Right-click the policy that's causing the error (likely the one you just added). Select Properties.
Go to the Rules tab. Select the rule that applies to the connection, click Edit. Then on the IP Filter List tab, select the filter and click Edit. Don't change filter lists unless you know what you're doing – but do check that the Authentication Methods tab is set right.
Now go to the Tunnel Endpoint tab. If you don't need tunneling (and most small businesses don't), set it to None. I've seen this error pop up because someone had a tunnel endpoint set to a specific IP when the remote gateway didn't support it.
Back in the rule properties, click the Connection Type tab. Make sure it's set to All network connections unless you specifically need only LAN or remote access.
If none of that helps, delete the policy (right-click > Delete) and re-create it using the IPsec Policy Wizard. Choose the Request security option – that's usually the most compatible.
The 15+ Minute Fix: Deep Dive into IKE and Authentication
Alright, the simple stuff didn't work. Time to get your hands dirty. This error often hides an authentication mismatch or a certificate problem.
First, check the event logs for more detail. Open Event Viewer (eventvwr.msc), go to Windows Logs > Security. Look for event ID 4654 (or 5453 on older systems). That event will tell you exactly which offer got pruned.
Common causes I've seen in the field:
- Certificate trust broken: The machine's certificate isn't trusted by the remote side. Run
certlm.mscand check that the issuing CA is in the Trusted Root Certification Authorities store. I once spent an hour on a client's VPN because their certificate had expired and they'd been using it for three years – nobody thought to check. - Pre-shared key mismatch: Double-check the key on both ends. One extra space or a typo will give you this error. I use
Get-Random -Minimum 100000 -Maximum 999999in PowerShell to generate random PSKs – avoids typos. - IKE version mismatch: Windows 10/11 defaults to IKEv2, but older devices might only do IKEv1. In the policy properties, on the Key Exchange tab (Security Methods), click Edit. Under IKE protocol, try setting it to IKEv1 or Both. Had a client's old firewall that only spoke IKEv1 – Windows kept trying v2 and pruning it.
- Diffie-Hellman group mismatch: Same tab, check the DH group. Windows defaults to Group 14 (2048-bit), but some older devices only support Group 2 (1024-bit) or even Group 1 (768-bit). Match what the remote side expects.
If you're still stuck, reset the whole IPSec stack. As admin in PowerShell:
net stop ipsecsvc
net stop ikeext
net start ikeext
net start ipsecsvcThen clear the SA database:
netsh ipsec static delete all
netsh advfirewall resetRebuild your policy from scratch after that. I've seen corruption in the policy store cause this error – nuking it and starting fresh is sometimes the only way.
When to Give Up and Call for Help
If you've done all this and still get the error, it's probably not a Windows problem. Check the remote device – could be a firmware bug, a missing license for certain encryption suites, or just a flat-out incompatibility. I had a Fortigate firewall that needed a firmware update before it could talk to Windows Server 2022. Sometimes the fix is on the other end.
Also, if you're in an enterprise environment with a central management tool like SCCM or a third-party IPSec client, those can override local policies. Check if there's a management agent running that's pushing conflicting settings.
The bottom line: 0x000032e0 is Windows telling you “I got your policy, but I can't use all of it.” Find the mismatch, fix it, and you're golden. Now go fix that client's VPN.