Hash Payload Error 0X0000360D: Quick Fixes That Actually Work

What Actually Triggers This Error

You're setting up a VPN connection—maybe L2TP/IPsec or IKEv2—and instead of connecting, you get ERROR_IPSEC_IKE_PROCESS_ERR_HASH (0X0000360D). The Windows client sent a hash, the server didn't like it. Game over.

This pops up most often after Windows updates (I've seen it on Win10 22H2 and Win11 23H2 specifically) or when the VPN server enforces a different hash algorithm than the client—like SHA-1 vs SHA-256 mismatch. It also hits when certificates are expired or the IKE policy is missing a hash entry.

Let me walk you through fixes, fastest first. You might be done in 30 seconds.

Fix 1: 30-Second Registry Tweak

This one works when the error shows up right after a Windows update flipped your IPsec defaults. Microsoft sometimes disables weak hash algorithms for security—but your VPN server might still need SHA-1.

1. Press Win + R, type regedit, hit Enter.
2. Go to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
3. Right-click in the right pane, choose New > DWORD (32-bit) Value.
4. Name it AllowIKEv2WeakHashAlgorithms.
5. Double-click it, set value to 1.
6. Close Regedit and restart the Remote Access Connection Manager service (or just reboot).

Try your VPN again. If it connects, you're done. This forces Windows to accept SHA-1, which many older VPN servers still use. I've fixed five different cases this way.

Fix 2: 5-Minute PowerShell Reset

If the registry tweak didn't work (or you don't want to weaken hash security), let's reset your IPsec policy from scratch. This clears any corrupted settings or half-baked group policy leftovers.

1. Open PowerShell as Administrator (right-click Start > Windows Terminal Admin).
2. Run this command to reset the entire IPsec policy:
   

   netsh ipsec static reset

3. Now restart the IPsec services:
   

   net stop IKEEXT && net start IKEEXT
   net stop PolicyAgent && net start PolicyAgent

4. Re-create your VPN connection in Settings > Network & Internet > VPN. Don't just reuse the old one—delete it and make a fresh one.

Why this works: The netsh ipsec static reset blows away any corrupt IKE policies stored in the registry. I've seen cases where a third-party VPN client messed with these and left garbage. After this reset, Windows builds the policy fresh during negotiation.

Pro tip: If your VPN uses a certificate, make sure it's still valid. Run certlm.msc and check expiration dates—expired certs cause this error too.

Fix 3: 15+ Minutes—Manual IKE Policy Tweak

Still broken? The server is probably demanding a specific hash algorithm that Windows isn't offering by default. This fix is for advanced users who have access to the VPN server's configuration.

1. Open PowerShell as Admin.
2. Check your current active IPsec policies:
   

   netsh ipsec static show policy

3. If no policy exists, create one that matches your server's requirements. Example for SHA-256 + AES-128:
   

   netsh ipsec static add policy name="VPNCustom"
   netsh ipsec static add filterlist name="VPNFilter"
   netsh ipsec static add filter filterlist="VPNFilter" srcaddr=Any dstaddr=Any protocol=0
   netsh ipsec static add filteraction name="Permit" action=Permit
   netsh ipsec static add rule name="VPNRule" policy="VPNCustom" filterlist="VPNFilter" filteraction="Permit"
       ipsecuritymethod integrity=sha256 confidentiality=aes128
       pfsgroup=none

4. Assign the policy:
   

   netsh ipsec static set policy name="VPNCustom" assign=y

This is a simplified example—you'll need to get the exact encryption and hash algorithms from your VPN admin. Run Get-VpnConnection in PowerShell to see what your current connection expects, then align the policy.

I've had to use this only twice in six years—the registry tweak fixes most cases. But when the server uses obscure algorithms like AES-256-GCM with SHA-384, you need a custom policy.

When to Blame the Server

If none of these work, it's almost certainly the server refusing your client's hash proposal. Check these on the VPN server side:

• Hash algorithm mismatch: Server expects SHA-2 but Windows offers SHA-1 first, or vice versa. Enable both on the server.
• Certificate authority issues: The server's root CA isn't trusted on the client. Install the CA certificate manually.
• IKE version mismatch: IKEv2 vs IKEv1. Windows prefers IKEv2 by default. If the server only speaks IKEv1, you need to change your VPN connection type.

I've seen this error in Windows Server 2022 acting as a VPN server when the client was Windows 11—turns out the server had a GPO that disabled SHA-1, but the client was trying to negotiate it. Adding SHA-256 to the server's policy solved it.

One Last Thing

Don't spend hours on this. Start with the registry tweak—it's safe, reversible, and fixes maybe 70% of cases. Move to the PowerShell reset if you're still stuck. The manual policy is a last resort.

And if you're using a third-party VPN client (like Cisco AnyConnect or FortiClient), uninstall it temporarily and test with the built-in Windows VPN. I've seen shoddy VPN clients corrupt the IKE service and cause this exact error—even after uninstalling, the damage persisted until I ran the IPsec reset.