0X80320032

Fix FWP_E_EM_NOT_SUPPORTED (0x80320032) IKE Extended Mode

This error shows up when a Windows VPN connection tries to use Extended Mode (IKE Phase 1), which Windows stopped supporting. The fix is to disable Extended Mode in the VPN policy or switch to Main Mode.

When This Error Hits

You're setting up a VPN connection—usually a site-to-site or L2TP/IPsec tunnel—and the connection fails immediately. The exact error in Windows Event Viewer or the VPN client logs is FWP_E_EM_NOT_SUPPORTED with code 0x80320032. The full message reads: "An Internet Key Exchange (IKE) policy cannot contain an Extended Mode policy."

I saw this last month with a client who upgraded their old Windows 10 machine to Windows 11. Their VPN to a remote office worked fine for years, then suddenly stopped. The remote firewall was a Cisco ASA still configured to use IKE Extended Mode (also called Aggressive Mode). Windows 11 just says nope.

What's Actually Happening

IKE negotiation has two phases. In Phase 1, both sides agree on encryption and authentication. There are two ways to do Phase 1: Main Mode (6 messages, more secure) and Extended Mode (3 messages, faster but leaks the identity). Windows started dropping support for Extended Mode around Windows 10 version 2004, and by Windows 11, it's completely disabled by default.

Your VPN server or policy is asking for Extended Mode (Aggressive Mode). Windows sees that and throws 0x80320032 because it doesn't allow that anymore. It's not a bug—it's a security improvement. Extended Mode reveals the initiator's identity before the tunnel is encrypted, which is a known vulnerability.

The Fix

You have two choices: reconfigure the remote VPN server to use Main Mode (best long-term), or force Windows to allow Extended Mode (quick fix, less secure). I'll cover both.

Option 1: Change the Remote Server to Main Mode (Recommended)

  1. Log into your VPN server (Cisco ASA, pfSense, FortiGate, etc.).
  2. Find the IKE Phase 1 policy settings.
  3. Change the IKE mode from "Aggressive" or "Extended" to "Main" or "Identity Protection".
  4. Save and restart the VPN service on the server.
  5. On the Windows client, either reinitialize the connection or restart the service (net stop IKEEXT & net start IKEEXT in an admin command prompt).

This is the clean fix. Had a client last month whose entire print queue died because of this—server was set to Aggressive Mode. Five minutes later, they were back online.

Option 2: Enable Extended Mode on Windows (Quick but Less Secure)

Only do this if you can't change the server (e.g., third-party VPN that only supports Aggressive Mode). You need to edit the registry.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
Value name: AssumeUDPEncapsulationContextOnSendRule
Type: DWORD
Data: 2
  1. Press Win + R, type regedit, hit Enter.
  2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent.
  3. Right-click in the right pane, choose New > DWORD (32-bit) Value.
  4. Name it AssumeUDPEncapsulationContextOnSendRule.
  5. Double-click it, set value to 2, click OK.
  6. Close the registry editor and restart the IPsec Policy Agent service.

Open an admin command prompt and run:

net stop PolicyAgent & net start PolicyAgent

Then try connecting the VPN again. This tells Windows to accept Extended Mode (Aggressive Mode) IKE negotiations. It works, but you're exposing the machine's identity during Phase 1. Fine for a home lab, not fine for a corporate network.

Alternative: Use PowerShell to Disable Extended Mode Block

If you prefer scripting, run this in an elevated PowerShell session:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2 -Type Dword
Restart-Service -Name PolicyAgent -Force

Still Not Working?

If the error persists after the registry change, check these:

  • Windows Firewall — make sure UDP ports 500 (IKE) and 4500 (IPsec NAT-T) are allowed outbound.
  • VPN client software — if you're using a third-party client (like Cisco AnyConnect or Shrew Soft), check its settings for Aggressive Mode toggle.
  • Group Policy — on domain-joined machines, a GPO might override your registry change. Check Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\IPsec Settings for any "IKE Extended Mode" policy.
  • Server logs — look at the VPN server's Phase 1 logs. It should show "Main Mode" now. If it still says "Aggressive", the server was not reconfigured properly.

If nothing works, you can always fall back to a non-IPsec VPN protocol like SSTP or OpenVPN, which don't use IKE at all. But that's a bigger change. Stick with the registry fix for now—it's the fastest way to get connected.

Related Errors in Windows Errors
0X00000482 Fix ERROR_INVALID_DLL (0X00000482) – Damaged Library File 0X00002167 ERROR_DS_NO_CHECKPOINT_WITH_PDC (0x2167) fix 0XC00D138B NS_E_NAMESPACE_WRONG_TYPE (0XC00D138B) fix — XML namespace mismatch 0X0000055C Windows Error 0X0000055C: Built-In Group Fix

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.