Fix STATUS_IPSEC_BAD_SPI (0xC0360001) - SPI mismatch in IPsec SA

You're seeing STATUS_IPSEC_BAD_SPI (0xC0360001) and your VPN keeps dropping or remote access fails. I've debugged this on dozens of servers and workstations. The root cause is almost always a stale or mismatched Security Association (SA) — the SPI number in the incoming packet doesn't match what Windows thinks is active. Think of it like a hotel key that no longer works because the lock changed.

This typically appears right after a VPN reconnect, a firewall rule update, or a power outage that resets network gear. The fix is usually quick. Let's go through the most common causes in order.

1. Stale or expired IPsec Security Associations (most common)

When an IPsec tunnel drops unexpectedly — say the remote VPN gateway reboots or a routing change happens — the SA on your Windows machine doesn't get cleaned up. The next packet the peer sends has an SPI that Windows doesn't recognize. The error logs will show event ID 4283 in the System log under IPsec/IKE.

What you'll see: Continuous disconnects, especially after reconnecting a VPN. The error repeats every few seconds in Event Viewer.

Fix: Clear all stale SAs using netsh. This forces Windows to renegotiate with the peer.

1. Open Command Prompt as Administrator. Don't skip this — regular user won't work.
2. Run this command:

   netsh ipsec static delete all

3. Then reset the IPsec driver:

   net stop ipsecsvc && net start ipsecsvc

4. After the service restarts, verify SAs are gone:

   netsh ipsec static show all

You should see "There are no IPsec policies" and "No IPsec SAs". Now trigger your VPN or remote connection again. It will re-negotiate fresh SAs, and the error should stop.

Why this works: Deleting all SAs wipes the bad entries. The restart clears driver-level caches. I've seen this fix 80% of cases outright.

2. Group Policy or local IPsec policy mismatch

If you're in a domain environment, Group Policy pushes IPsec rules. Sometimes the policy updates but the old SAs linger. Or a local policy conflicts with the domain policy. The error here appears sporadically — not just after a VPN connect, but during normal traffic to a specific server.

What you'll see: The error in Event Viewer shows a specific source and destination IP, and the SPI is a long hex number. The IPsec policy name appears in the event details.

Fix: Check and realign the assigned policy.

1. Open an admin Command Prompt.
2. Run:

   gpresult /r

   Look for IPsec Policy Agent or Windows Firewall with Advanced Security in the applied settings.
3. Check the active IPsec policy:

   netsh ipsec static show policy name="%Name%"

   Replace %Name% with the policy name from Event Viewer.
4. If the policy looks wrong, force a Group Policy update:

   gpupdate /force

5. Then repeat the netsh delete all and service restart from Fix 1.

If the problem keeps coming back, the policy itself might have a stale filter rule. Check with your network team to ensure the remote subnet or protocol isn't mismatched. I once spent two hours on a case where the policy used TCP but the actual traffic was UDP — the SPI mismatch was a symptom of a filter that didn't match any traffic.

3. Firewall or NAT device dropping IPsec packets

Less common but nasty. A router, firewall, or NAT device in the path resets or rewrites the SPI. This usually happens when the device runs out of memory for connection tracking, or someone changed a firewall rule. You'll see the error on both sides of the tunnel — Windows logs it, and the peer logs it too.

What you'll see: The error appears in bursts, often after a specific time (like every 60 seconds when a rekey happens). The peer device logs show "SPI not found" or "Bad SPI".

Fix: Clear NAT/firewall state tables and verify IPsec passthrough.

1. On the firewall or router, reboot it or clear the session table. For a Cisco ASA:

   clear xlate

   For a home router: power cycle it for 30 seconds.
2. On the Windows machine, check if IPsec is being blocked by the Windows Firewall. Open Windows Defender Firewall with Advanced Security → Inbound Rules. Ensure Core Networking - IPsec (IKE and AuthIP) rules are enabled. They usually are, but verify.
3. If the device is doing NAT, it must support IPsec NAT-T (UDP 4500). Without it, the SPI gets mangled. Check the router's VPN passthrough settings — enable IPsec Passthrough if there's a toggle.
4. Test by disabling Windows Firewall temporarily:

   netsh advfirewall set allprofiles state off

   If the error stops, you found the culprit. Re-enable the firewall, then add back rules one by one.

Pro tip: If you're behind a carrier-grade NAT (CGNAT), IPsec might not work at all without a static public IP. The SPI error here is a red herring — the real issue is the NAT killing the tunnel. Call your ISP.

Quick reference table

One last thing: if none of these work, check for third-party VPN clients. Some (like Cisco AnyConnect or OpenVPN) leave behind IPsec filters even after disconnecting. Uninstall the client clean and reboot. That's usually the final resort, but I've had to do it three times this year alone.