FWP_E_INCOMPATIBLE_CIPHER_CONFIG (0X80320039) Fixed

This error is a wall. Let's knock it down.

I know seeing 0X80320039 when your VPN or DirectAccess tunnel fails makes you want to throw something. I've been there. It's almost always a cipher negotiation mismatch between the client and server. The fix is dead simple, but Windows hides it well.

Quick Fix: Flush and Reset IPsec Policies

Open Command Prompt as Administrator. Don't skip that part — it won't work without admin rights.

netsh ipsec static delete policy name=all
netsh ipsec static set policy name=Default mmlifetime=480
netsh ipsec static set defaultrule mmlifetime=480

Run each command one at a time. Press Enter after each. Once done, reboot your machine. That's it for 90% of cases.

Why this works

The delete policy name=all command wipes any custom IPsec policies that might be forcing a specific cipher Windows doesn't support (like DES or 3DES on newer builds). The mmlifetime=480 sets a sane main mode lifetime — the default is 8 hours, and some older servers choke on that. After a reboot, the IPsec service rebuilds its policy cache from scratch using the built-in default cipher suites (AES-256, SHA-256, DH Group 14).

When the basic fix isn't enough

If the error still shows up, the server is likely insisting on a cipher your client doesn't offer. This commonly happens with:

• Windows 10 22H2 or Windows 11 23H2 trying to connect to a legacy Windows Server 2012 R2 or earlier that only offers AES-128-CBC or 3DES.
• DirectAccess deployments where the server certificate uses a deprecated cipher like RSA-1024 with SHA-1.
• Third-party VPN gateways (SonicWall, Fortinet) that default to DH Group 2 or 5 instead of the modern Group 14 or 19.

Check what ciphers the server expects

Run this on the client to see the proposed security associations:

netsh ipsec static show all

Look for the MM (Main Mode) section. If you see CipherAlg=DES or IntegrityAlg=MD5, that's your problem. Windows 10/11 won't negotiate those by default.

Force a specific cipher suite (advanced)

If the server won't budge, you can force the client to offer the older ciphers. I hate doing this, but sometimes you have no choice. Open an elevated PowerShell and run:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters" -Name "AllowWeakCiphers" -Value 1 -Type DWord
Restart-Service IKEEXT

This lets IKE (Internet Key Exchange) use DES, 3DES, and MD5. Only do this on a test machine first. Weak ciphers can be broken in minutes. After the VPN connects, set the value back to 0 and restart the service again.

Preventing this from coming back

Three things will keep 0X80320039 from haunting you again:

1. Keep your IPsec policies simple. Don't create custom policies unless you really need them. The defaults on Windows 10/11 are solid.
2. Update your VPN server. If you control the server, move it to at least AES-128 and SHA-256. Windows Server 2016 and later support this natively.
3. Check your certificates. If you're using machine certificates for IPsec, make sure they use SHA-256 or SHA-384. SHA-1 certificates will trigger this error on newer Windows builds.

One last thing: if you're using DirectAccess, run Get-DAConnectionStatus in PowerShell after the fix. It'll tell you if the tunnel is actually up. Don't trust the GUI — it lies sometimes.

That's the full picture. Short version: delete the custom policies, reboot, and if it still fails, check what the server is asking for. You've got this.