You're sitting in a hotel lobby, trying to connect to your corporate VPN, and Windows throws ERROR_IPSEC_IKE_INVALID_GROUP (0X00003629). The connection dies before it even gets to the authentication stage. This usually happens after an IT admin tightened security policies on the VPN server, or you upgraded from an older Windows version that used a weaker DH group by default.
What's actually happening here is a negotiation failure. During the IKE (Internet Key Exchange) phase, your client and the VPN server have to agree on a Diffie-Hellman group. That group determines how strong the key exchange will be. If the server only offers groups your client doesn't support, or vice versa, the tunnel can't be established. The error code 0x3629 literally means "the Diffie-Hellman group is invalid" — but in practice, it's a mismatch, not a corrupt value.
Why does this happen?
Diffie-Hellman groups are numbered (2, 5, 14, 19, 20, 24, etc.). Each group has a different prime length — group 2 is 1024-bit, group 14 is 2048-bit, group 19 is 256-bit elliptic curve. Windows 10 and 11 default to a set of groups, but some VPN servers (especially older Cisco or SonicWall appliances) are locked to a specific group. If the server says "I only do group 2" and your client says "I only do group 14," you get this error.
The trigger is often a security policy update. I've seen it after an admin disabled group 2 on the server to comply with PCI DSS, without updating the client configuration. The client keeps trying group 2 first, gets rejected, and fails instead of falling back to a stronger group.
The fix: align the DH groups
The real fix isn't to blindly change registry keys — it's to find out what group the server expects and set your client to use it. Here's how I'd approach it, in order.
Step 1: Check the VPN client's settings
If you're using the built-in Windows VPN (IKEv2 or SSTP), open the adapter properties. Go to Control Panel \ Network and Sharing Center \ Change adapter settings, right-click your VPN connection, and select Properties. Under the Security tab, look for "Data encryption" and "Authentication." For IKEv2, you might not see DH groups here — they're buried in the registry.
For third-party clients like Cisco AnyConnect, check the connection profile. There's often a dropdown for "Group" that maps to a DH group. Set it to match your server's configuration. If you don't know what the server uses, ask your admin — guessing wastes time.
Step 2: Adjust the registry for IKEv2 (if applicable)
For native IKEv2 connections, Windows stores allowed DH groups in the registry. Open regedit and navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgentLook for a value named IKEDiffieHellmanGroups or AssumeUDPEncapsulationContextOnSendRule — the latter is unrelated but often confused. If IKEDiffieHellmanGroups exists, it's a DWORD where each bit represents a group. For example, to enable groups 14 and 19, you'd set it to 0x80000 (group 14 is bit 18, group 19 is bit 20). But here's the catch: default Windows configs don't include this value, and adding it can actually break things if you set it wrong.
My advice: don't touch the registry unless you've confirmed the server needs a specific group that Windows isn't offering by default. Windows 10/11 with recent updates supports groups 2, 14, 19, 20, and 24. If the server wants something exotic, like group 25 or 26, you'll need to update the client.
Step 3: Update the VPN client software
If you're using a vendor client (Pulse, GlobalProtect, FortiClient), update it. Vendors add support for newer DH groups in patches. I've seen a FortiClient 6.0 user get this error because the old version didn't support DH group 20, and the server had just been reconfigured to use it. An update to 6.2 fixed it instantly.
Also check if there's a profile update from your IT department. Sometimes the fix is as simple as importing a new .xml or .ovpn file.
Step 4: Force a specific DH group (advanced)
If you're confident the server uses a specific group, you can force Windows to use it via PowerShell. For IKEv2, you can set the proposal with Set-VpnConnection and the -Authentication parameter, but that doesn't control DH groups directly. For L2TP/IPsec, you can try:
Set-VpnConnection -Name "YourVPN" -Authentication MSCHAPv2 -EncryptionLevel RequiredBut honestly, this rarely helps because the DH group is negotiated at the IKE layer, not the tunnel layer. The better route is to check the server's accepted groups and align.
What if it still fails?
If you've aligned the groups and still get 0x3629, look at these three things:
- Check the server logs. On Windows Server, use
Get-WinEvent -LogName Microsoft-Windows-RasServer/Operationalto see the exact rejection reason. It might say "no proposal chosen," which points to the DH group, or it might be something else entirely. - Test with a different client. If you have a Linux box or a phone, try connecting with the same credentials. If it works there, the problem is definitely Windows-specific. If it fails everywhere, the server is the issue.
- Look for NAT or third-party firewall interference. A misconfigured firewall between you and the server can drop IKE packets, causing a timeout that Windows misreports as a DH group error. Check if UDP ports 500 and 4500 are open. I once spent an hour changing DH groups only to find the hotel's firewall was blocking UDP 500.
The last resort is to have your admin check the server's IKE policy and temporarily enable a broader set of groups to see if the client connects. That tells you exactly which group your client is offering.
Remember: this error is almost always a configuration mismatch, not a broken system. The fix is about making both sides speak the same DH language, and once you do, the VPN will come up faster than you can say "group 14."