Fix FWP_E_INCOMPATIBLE_DH_GROUP 0X80320031 in 2 Minutes

This error kills IPsec VPN connections when Diffie-Hellman groups mismatch between client and server. The fix is forcing a compatible DH group on the Windows firewall rule.

Yeah, I've seen this one more times than I care to count. You're trying to connect a VPN or set up a direct IPsec tunnel, and Windows throws back the 0X80320031 error — FWP_E_INCOMPATIBLE_DH_GROUP. The culprit here is almost always a mismatch between what your firewall policy expects for the Diffie-Hellman group and what the remote end is offering.

Straight to the Fix

Don't bother reinstalling network drivers or resetting Winsock — that rarely helps here. The real fix is to modify the IPsec rule that's failing. You can do this with a netsh command in an elevated command prompt.

Open Command Prompt as Administrator.
Run this command to list existing IPsec rules:

netsh advfirewall consec show rule name=all

Find the rule name that corresponds to your failing connection — it'll be something like "My VPN Tunnel" or "DirectAccess-ClientToCorp". Once you have the name, run:

netsh advfirewall consec set rule name="YourRuleName" new dhgroup=14

Replace YourRuleName with the actual rule name. The dhgroup=14 forces use of DH group 14 (2048-bit MODP), which is broadly compatible and avoids the error in most cases. If you're connecting to an older device that only supports group 2 (1024-bit MODP), use dhgroup=2 instead.

After that, restart the IPsec service:

net stop IKEEXT && net start IKEEXT

Now try your VPN connection again. Nine times out of ten, that's it.

Why This Works

The error code 0X80320031 translates to "The Diffie-Hellman group is not compatible with the policy type." Windows Firewall (specifically the Windows Filtering Platform) enforces IPsec rules at the kernel level. When a rule specifies a DH group that doesn't match what the remote peer is offering, WFP kills the connection before it even gets to the handshake.

By default, Windows might pick DH group 2 or try to negotiate automatically. But some VPN concentrators or older firewall appliances expect a specific group. Group 14 (2048-bit) is the sweet spot for modern compatibility — it's strong enough for security policies and supported by almost everything made after 2010. If you're dealing with something ancient that only speaks group 1 or group 2, you'll need to match that exactly.

Less Common Variations

Sometimes the rule is set via Group Policy, and you can't change it locally without breaking policy compliance. In that case, you have two options:

Override via local policy — Run secpol.msc, go to Windows Defender Firewall with Advanced Security, then Connection Security Rules. Find the rule, open properties, and on the Authentication tab, check "Advanced" to modify the DH group. But if GPO updates, it'll overwrite your change.
Create a new rule with higher priority — Use netsh to add a new rule that matches the same traffic but with a different DH group. Give it a higher priority number so it takes precedence. Example:

netsh advfirewall consec add rule name="OverrideVPN" endpoint1=any endpoint2=any action=requireinrequireout auth1=computerpsk psk=YourSecret dhgroup=14

Another rare case: if you're using IKEv2 with certificates, the DH group negotiation happens during the IKE SA exchange. The error can also pop up if the remote server's certificate doesn't match the DH group expected by Windows. Check the server's IPsec proposal list — it should include at least one group that matches what you set.

I've also seen this on Windows Server 2016/2019 when running DirectAccess. The fix is the same — check the DirectAccess server's IPsec policy in the Remote Access console. Under Step 3 (Infrastructure Server Setup), you might need to lower the DH group to match client capabilities.

Prevention

To stop this from coming back, you need to align DH groups before you ever set up an IPsec rule. When planning a site-to-site VPN or a client-to-server tunnel, standardize on DH group 14 across all endpoints. It's the minimum for most compliance frameworks (PCI-DSS, HIPAA) and avoids the 0X80320031 trap.

If you're managing multiple Windows machines, push consistent IPsec settings via Group Policy. Under Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access > Filtering Platform Connection, you can audit DH group mismatches before they break connections. Use that audit log to catch issues early.

And for the love of everything, document your DH group choices somewhere. Five years from now, some poor sysadmin will thank you when they don't have to debug 0X80320031 at 2 AM during a VPN outage.