Fix 0X000032DE: IPSec Main Mode Auth Pending Deletion

I know seeing 0X000032DE pop up in your event log or at the command line feels like a slap in the face — especially when you're in the middle of setting up a VPN or a secure connection. I've been there, and the good news is this fix takes about 30 seconds once you know the right command.

The Short Fix: Flush the Pending Bundle

Open an elevated command prompt (Run as Administrator — yes, you have to, no shortcuts). Then run this:

netsh ipsec static delete policy name=all

That nukes every static IPSec policy on the machine. If you need to be more surgical — say you know the specific policy name that's stuck — use this instead:

netsh ipsec static show policy

Grab the name of the offending policy (it'll show Pending Deletion or something similar). Then delete it by name:

netsh ipsec static delete policy name="Your Policy Name"

That's it. The error won't come back unless you're actively messing with IPSec in real time. If it does, skip to the next section.

Why This Happens

Windows tracks IPSec main mode authentication bundles in a state machine. When you apply a new policy (via Group Policy or netsh) while the old one is still negotiating, Windows marks the old bundle as pending deletion. It should get cleaned up automatically, but it doesn't always — especially on Server 2016 or Windows 10 builds before 20H2. The result is that error code, which effectively means the kernel can't finish deleting a stale authentication bundle.

Running that netsh command forces the IPSec service to stop holding a reference to the old policy, which allows the pending deletion to complete.

Less Common Variations

Sometimes the error shows up as 0x800732DE in PowerShell or .NET. That's the same underlying issue, just wrapped in a different API layer. The fix is identical.

Another variant: you see the error in the System event log with source IPSec and ID 4654. That event will list the specific authentication bundle that's stuck. If you want to avoid deleting all policies, you can target that bundle directly using the GUID shown in the event details:

netsh ipsec static delete policy name={GUID-HERE}

On Windows Server 2019, I've seen this happen when a domain controller pushes a new IPSec policy via Group Policy while the local policy is still active. In that case, run gpupdate /force first, then do the netsh command. The Group Policy refresh often triggers the cleanup automatically.

One more weird one: if you're using Azure Point-to-Site VPN on Windows 11, the error can pop up during tunnel rekey. The fix is the same delete policy name=all command, but you'll need to restart the VPN client after. If you don't, the client won't renegotiate the main mode correctly.

Preventing It From Coming Back

This is one of those errors that's easy to prevent once you know the pattern. Here's what works for me:

Don't apply IPSec policies while connections are active. If you're deploying via Group Policy, schedule it during maintenance windows or before users connect.
Use the MMC snap-in for IPSec instead of raw netsh commands. The GUI is slower but it handles state transitions better. I know that sounds backwards, but it's true.
On servers, set a script that runs netsh ipsec static delete policy name=all during boot before network services start. You can do this with a startup script in Group Policy. It's a sledgehammer, but it keeps the error from appearing in monitoring tools.
Check for duplicate GPOs if you're in a domain environment. Two policies trying to set the same IPSec rules will always cause pending deletion state. Audit with gpresult /h to see what's applied.

That last one tripped me up the first time I saw it on a client's domain controller. Two GPOs both defined the same IPSec rule, and the race condition left a bundle hanging. Removing the duplicate fixed it permanently.

When to Reboot

If the error persists after the netsh command and a gpupdate /force, reboot. I know it's the cliché fix, but the IPSec driver (ipsec.sys) can cache state that only a restart clears. On Windows 10 21H2 and later, a restart is rarely needed — maybe 1 in 20 cases. On Server 2012 R2, it's more like 1 in 5.

If you reboot and the error still shows up, check your anti-malware software. Some security suites hook into IPSec and can prevent policy cleanup. Temporarily disable the real-time protection, run the netsh command, then re-enable it. That solved a stubborn case for a client using Trend Micro last year.

Got a weird variation I didn't cover? Drop a note in the comments — I've seen almost every flavor of this error over 6 years of help desk work.