IPsec integrity check failed (0xC0360006) fix

Pre-shared key mismatch (most common cause)

What's actually happening here is that both ends of the IPsec tunnel compute an integrity hash over the packet payload, then compare it. If the pre-shared key on one side doesn't match the other, those hashes won't line up. Windows throws 0xC0360006 and drops the packet.

You'll see this most often when someone updates the PSK on a firewall or VPN concentrator but forgets to update the Windows client. The connection tries to establish, Phase 2 negotiation starts, then boom—integrity check fails.

Fix: Verify and re-enter the pre-shared key on both ends

1. On the Windows machine, open Network and Sharing Center → Change adapter settings. Right-click your VPN connection → Properties → Security tab.
2. Under IPsec settings, click Advanced settings. In the Pre-shared key field, type the key exactly as it appears on the remote server.
3. Triple-check for trailing spaces or hidden Unicode characters. I've seen a non-breaking space copied from a web form cause this error. Type it manually if you can.
4. On the remote server (firewall, router, or another Windows box running Routing and Remote Access), confirm the same key is set. For a Windows RRAS server, open Routing and Remote Access → Properties → Security → Authentication → Pre-shared key.
5. Restart the IPsec service on both sides with net stop PolicyAgent && net start PolicyAgent on Windows, or the equivalent on your firewall.

The reason step 3 matters is that Windows and many third-party VPN gateways treat the PSK as a case-sensitive string. A single wrong character will fail the HMAC-SHA1 or HMAC-SHA256 integrity check, giving you error 0xC0360006.

Certificate validation failure

If you're using certificate-based authentication instead of a pre-shared key, the integrity check can fail when the local machine certificate is revoked, expired, or doesn't chain to a trusted root. The IPsec stack doesn't just check the signature—it also validates the certificate chain and revocation status. If any link in that chain breaks, the integrity check fails.

This happens a lot on domain-joined Windows 10/11 machines where a Group Policy pushed a new certificate but the old one hasn't been removed yet, or when a CA root certificate expires silently.

Fix: Check certificate health

1. Open certlm.msc (Local Machine certificate store). Browse to Personal → Certificates.
2. Find the certificate used for IPsec. It usually has the name of your VPN server or a custom-friendly name. Double-click it.
3. Check the General tab—make sure the certificate isn't expired and that it says "This certificate is OK."
4. Go to the Certification Path tab. Every certificate in the chain should show a green checkmark. If you see a red X, that's your problem—the root CA isn't trusted.
5. If revocation checking is on (default), Windows calls CRL/OCSP. If the CA's CRL distribution point is unreachable, you'll get an integrity failure. You can temporarily turn off revocation checking for IPsec by setting the registry key HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\StrongCRLCheck to 0. Don't leave it off permanently.
6. Re-import the root CA certificate if it's missing. Export it from a working client or ask your network admin for the .cer file.

Windows caches certificate validation results. After fixing the certificate issue, clear the cache with certutil -delstore -user CA * and restart the IPsec service.

MTU or fragmentation mismatch

This one's sneaky. Sometimes the integrity check isn't failing because the keys or certs are wrong—it's failing because the packet got fragmented in transit and the receiver can't reassemble it properly. The IPsec integrity hash covers the entire payload, including headers. If a fragment arrives out of order or gets dropped, the hash won't match on the other end.

You'll see this pattern on connections that pass through a router with a smaller MTU than the VPN link. Real-world trigger: using a PPPoE connection (MTU 1492) with an IPsec VPN that assumes 1500.

Fix: Set MTU manually on the tunnel interface

1. Open PowerShell as Admin. Run Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*IPsec*"} to find your tunnel interface. The description usually contains "IPsec" or "VPN".
2. Set the MTU to 1400 to leave room for IPsec overhead: Set-NetIPInterface -InterfaceAlias "YourInterfaceName" -NlMtuBytes 1400. Replace YourInterfaceName with the actual name from step 1.
3. If you don't have a tunnel interface visible, you can set the MTU on your physical adapter instead. The IPsec stack will fragment before encrypting if the MTU is low enough.
4. Test the connection. If it works, gradually increase the MTU in 10-byte increments until it fails again, then drop back by 20 bytes. That's your sweet spot.

You can also check for fragmentation issues by running ping -f -l 1472 [VPN gateway IP]. If you get "Packet needs to be fragmented but DF set," your MTU is too high. Reduce the -l value until it passes, then add 28 to get the safe MTU.

Quick-reference summary table

One last thing: If you're using a third-party VPN client (Cisco AnyConnect, SonicWall Mobile Connect) and you get this error, check whether the client is configured to use the Windows IPsec stack or its own. Some clients bypass Windows' built-in IPsec and use their own driver stack—in that case, the fix might be an update to the client itself, not the OS. Look at the client logs for the real error. Windows Event Viewer under Applications and Services Logs → Microsoft → Windows → RasClient → Operational will also show the raw error code and a description of which connection failed.