Fix ERROR_IPSEC_IKE_INVALID_HASH_ALG (0x0000362F) – Quick Steps

Cause #1: Mismatched IKE Hash Algorithm Between Client and Server

This is the one I see 9 times out of 10. You're trying to connect to a VPN server (maybe a client's FortiGate or a Windows Server 2019 RRAS box), and the server expects SHA256 but your client is offering SHA1, or vice versa. The error pops right up.

I had a client last month whose entire remote workforce couldn't connect after the IT guy updated the VPN server settings but forgot to push the new config to everyone's laptops. Classic.

Fix: Align the Hash Algorithm

1. Check the server's IKE security association (SA) proposal. On a Windows RRAS server, open Routing and Remote Access console, right-click the server, go to Properties > Security. Under Custom IPsec policy, click Customize. Look at the Data integrity (hashing) algorithm. Common picks: SHA1, SHA256, SHA384.
2. Match it on the client. In Windows, the easiest way is to change the VPN connection's security settings. Go to Settings > Network & Internet > VPN, click your connection, hit Advanced options. Under Type of sign-in info, pick Certificate for IKEv2. Then click Properties on the connection in Network Connections (ncpa.cpl), go to Security tab, and under Advanced settings, you can force the specific hash algorithm.
3. Or just use PowerShell to set it precisely. Run as admin:

Set-VpnConnection -Name "YourVPNName" -AuthenticationMethod Eap -EncryptionLevel Required -IPSecAuthentication Certificate -L2tpPsk $null -TunnelType IKEv2 -Force

If the server uses SHA256, the client will negotiate it automatically after you set the correct encryption level. If it still fails, you need to force it via registry.

Registry workaround (if client won't negotiate correctly):

1. Open Regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters.
2. Create a DWORD named NegotiateDH2048_AES256 and set it to 1.
3. Reboot.

This forces SHA256/AES256 negotiation. I've used this on a dozen Windows 10 machines that refused to play nice with a SonicWall TZ400.

Cause #2: Corrupt or Outdated VPN Connection Profile

Sometimes the VPN profile on the client gets corrupted. Happens when you upgrade Windows, switch network adapters, or import a config from an old machine. The hash algorithm setting gets mangled or the cached security association is stale.

Last week, a client's laptop started throwing 0x0000362F after a Windows 11 feature update. The profile looked fine, but it was referencing a dead hash algorithm from a previous driver.

Fix: Delete and Recreate the VPN Connection

1. Open Settings > Network & Internet > VPN. Click the connection and hit Remove.
2. Also check ncpa.cpl – right-click the VPN adapter (it's usually hidden, so press Alt > File > New Incoming Connection won't show it, but you can see it under Network Connections). Right-click and delete it if it still exists.
3. Reboot the machine (clears cached SAs).
4. Create the VPN connection fresh from the server's config or using a RAS phonebook file (.pbk). If you have a .pbk from the admin, right-click it and choose Connect.
5. If you're setting it up manually, make sure in the security tab you select IKEv2 as the VPN type, and Use Extensible Authentication Protocol (EAP) with Microsoft: Secured password (EAP-MSCHAP v2) or certificate, depending on server requirements.

Pro tip: After recreating, test with a ping to the server's IP. If it passes but the VPN still fails, the issue is in the authentication phase, not the hash algorithm. Move on to Cause #3.

Cause #3: IPsec Policy or Registry Setting That Overrides Default Hash

Sometimes group policy or a leftover registry key forces a specific hash algorithm that the server doesn't support. I've seen this on domain-joined machines where IT pushed a custom IPsec policy that locked SHA1, but the server was updated to require SHA256.

Fix: Check Local IPsec Policy and Registry

1. Open secpol.msc (Local Security Policy). Go to Security Settings > IP Security Policies on Local Computer. If there's an assigned policy, right-click it and select Unassign. Then reboot.
2. Check the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec for any Configuration or Policy keys. If you see anything like ActivePolicy or AssignedPolicy, delete them (after backing up).
3. Also check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent for any Oakley keys that might force specific algorithms.

If the machine is domain-joined, run gpresult /h gp.html and look for any IPsec settings. You might need to talk to whoever manages group policy.

Quick-Reference Summary Table

Bottom line: this error is almost always a configuration mismatch, not a driver issue or hardware fault. Start with the hash algorithm, then clean the profile, then check policy. I've never seen a case where reinstalling Windows helped – that's just overkill. Save that for when the coffee spills on the laptop.