Fix IPsec IKE Process ERR ID 0x0000360A – Step by Step

What this error means

You're seeing error ERROR_IPSEC_IKE_PROCESS_ERR_ID (0x0000360A) when trying to establish an IPsec VPN connection. This usually pops up during the IKE phase 1 or phase 2 handshake—when Windows can't properly read the identity payload sent by the remote peer.

The real cause? Nine times out of ten it's a mismatch. Either the pre-shared key doesn't match, the certificate isn't trusted, or the identifier format (like an IP address vs. FQDN) doesn't line up on both sides. I've seen this on Windows 10, Windows Server 2019, and Server 2022 connecting to Cisco ASA, FortiGate, and even other Windows VPN servers.

Here's the fix path. Start with the quick check. If that doesn't work, move to the moderate one. Then if you're still stuck, go advanced.

Fix 1: Quick check – Verify pre-shared key (30 seconds)

This is the most common reason and the fastest to test. The pre-shared key (PSK) must be identical on both ends—every letter, number, and character.

Open the VPN connection's properties. Go to Control Panel > Network and Sharing Center > Change adapter settings.
Right-click your VPN connection and choose Properties.
Go to the Security tab.
Make sure Type of VPN is set to IKEv2 or L2TP/IPsec depending on your setup.
Click Advanced settings under the Data encryption section.
In the IPsec Settings dialog, check Use pre-shared key for authentication.
Re-type the key slowly. No weird characters copied from a PDF that look like a space but aren't. A common gotcha: trailing spaces. Delete the whole key and type it fresh.
Click OK, then Apply. After clicking Apply you should see no validation errors pop up.
Try connecting again. If it works, done. If not, move to step 2.

Real-world trigger: I've seen this error when someone pasted a PSK from an email and the line break added a hidden newline character. Re-typing it fixed it.

Fix 2: Moderate fix – Check certificate trust and identifier format (5 minutes)

If the PSK is correct or you're using certificates, the problem is often the identifier itself. Windows has specific requirements for how it identifies itself during IKE negotiation.

Check certificate trust

Press Windows key + R, type certlm.msc, and hit Enter. That opens the local machine certificate store.
Expand Personal > Certificates. Find the certificate you're using for the VPN connection.
Double-click it and go to the Certification Path tab. Check that it says This certificate is OK at the bottom. If you see a red X or "not trusted", the root CA certificate isn't in the Trusted Root Certification Authorities store.
To fix that, export the root CA cert from your VPN server (or provider) and import it into the Trusted Root Certification Authorities store on your machine. Right-click that store, choose All Tasks > Import, and follow the wizard.

Match the identifier format

Most VPN servers expect a specific identifier—either the certificate's Subject (like CN=client1.domain.com) or an IP address. If your server expects an FQDN and you're sending an IP address, you'll get this error.

Open the VPN connection properties again (same as step 1 above).
Click the Security tab, then click Advanced settings.
Look for the Identity or Use the following IP address section. Some Windows versions don't show this directly—you might need to use PowerShell for finer control.
If you're using certificate authentication, the certificate's Subject name must match what the VPN server expects. For example, if your server expects client1.contoso.com, your cert's Subject must be exactly that.

PowerShell quick fix for identifier mismatch

Get-VpnConnection -Name "Your VPN Name"

That shows the current settings. If you need to set the authentication method specifically, use this:

Set-VpnConnection -Name "Your VPN Name" -AuthenticationMethod EAP

Replace EAP with Psk if you're using a pre-shared key. After running the command, type Get-VpnConnection -Name "Your VPN Name" again to confirm the change took effect.

Fix 3: Advanced fix – Registry tweak for IKE negotiation (15+ minutes)

If the first two fixes didn't work, the issue might be a strict IKE negotiation parameter. Windows has a registry value that controls how strictly it validates the ID payload. This is rare but I've seen it on Windows Server 2022 when connecting to older IPsec peers.

Warning: Editing the registry can break things if you're not careful. Back up your registry first. Right-click Computer in Regedit and choose Export.

Press Windows key + R, type regedit, and press Enter.
Go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
Look for a DWORD value called AssumeUDPEncapsulationContextOnSendRule. If it doesn't exist, right-click in the right pane, select New > DWORD (32-bit) Value, and name it exactly that.
Double-click it and set the value to 2 (Base: Hexadecimal). Click OK.
Close Regedit and restart the IPsec Policy Agent service. Open Command Prompt as admin and run:
net stop PolicyAgent && net start PolicyAgent
Try connecting again. After restarting the service, you should see the connection attempt go past the ID payload step.

Why this works: This registry key tells Windows to be more lenient about how it negotiates IKE with the remote peer, specifically for NAT traversal scenarios. Some peers send the ID payload in a slightly different format, and this tweaks the validation rules.

Fix 4: Last resort – Recreate the VPN connection from scratch

If none of the above works, the VPN connection profile itself might be corrupted. Delete it and create a fresh one.

Go to Settings > Network & Internet > VPN.
Select your VPN connection and click Remove.
Create a new VPN connection manually. Use the same server address, but re-type everything from scratch—don't copy-paste anything.
Test the connection. Sometimes you just need a clean slate.

If you're still stuck after all this, the problem is likely on the remote VPN server side. Check the server logs for more specific error codes—Windows only shows you this generic one. The server might have an incorrect peer ID filter or a certificate revocation list issue.