IPsec SA Mismatch Error 0xC0360003 Fix

Quick answer for advanced users: Reboot both endpoints, then delete and recreate the IPsec security association using netsh ipsec static delete all on the Windows side.

This error — STATUS_IPSEC_WRONG_SA (0xC0360003) — happens when a packet arrives at the IPsec layer, but the security association (SA) it's matched to doesn't actually match the packet's properties. Think of it like this: you hand a delivery driver a package with the right address but the wrong apartment number. The system knows something doesn't line up. This usually pops up in VPN connections, especially between Windows and third-party firewalls like Check Point, Cisco ASA, or Fortinet. I've also seen it on Windows Server 2019 and Windows 11 after a Windows Update changed IPsec behavior.

Why You're Seeing This

Most of the time, this stems from a mismatch in the IPsec policy definition. Maybe one side expects AES-256 but the other uses AES-128. Or the traffic selector is off — the SA covers 192.168.1.0/24 but the packet is headed to 10.0.0.5. Another common trigger: a stale SA that wasn't torn down properly when the VPN renegotiated. I've debugged this on a client's Windows 10 laptop connecting to a Cisco ASA 5508 — the SA stuck around after a network change, and every packet after that hit this error until we cleared the SA manually.

How to Fix STATUS_IPSEC_WRONG_SA

Start with the simplest fix and work your way down. Don't skip steps.

Step 1: Clear the IPsec SA

Open an elevated Command Prompt (run as Administrator) and run:

netsh ipsec static delete all

This wipes all IPsec policies and SAs. Then restart the IPsec service:

net stop PolicyAgent && net start PolicyAgent

If you're using a VPN client, disconnect and reconnect after this. I've seen this fix the error instantly on Windows 10 22H2.

Step 2: Verify Traffic Selectors on Both Sides

On the Windows side, check your IPsec policy with:

netsh ipsec static show policy all

Look for FilterList entries. Make sure the source and destination IP ranges match what your VPN or firewall expects. For example, if your VPN tunnel should cover 10.0.0.0/8, but your Windows policy has 192.168.1.0/24, you'll get this error. Fix it by editing the policy or creating a new one with correct selectors.

On the firewall side, check the peer's SA selectors. I've had to adjust a Check Point R81 policy because its proxy IDs didn't align with Windows' settings.

Step 3: Match Encryption and Integrity Algorithms

Run this to see what Windows is using:

netsh ipsec dynamic show all

Look under Active SAs for ESP or AH entries. The algorithms listed (like ESP: 3DES/SHA1) must match exactly with the firewall. If Windows says AES256/SHA256 but the firewall expects AES128/SHA1, you'll get the mismatch. Reconfigure one side to match. I recommend using the Windows Group Policy editor if you're not comfortable with netsh — set it under Computer Configuration > Windows Settings > Security Settings > IP Security Policies.

Step 4: Reboot Both Endpoints

I know this sounds basic, but I've seen a simple reboot flush a stuck SA that netsh couldn't clear. Reboot the Windows machine and the firewall (if you have access). This forces a fresh IKE negotiation.

Alternative Fixes If the Main Steps Fail

If you're still hitting the error, try these in order:

• Disable IPsec offloading: Some NICs with hardware IPsec offload cause this. Go to Device Manager, find your network adapter, Properties > Advanced > IPsec Offload, set to Disabled.
• Turn off Windows Defender Firewall temporarily: I don't like doing this, but if the firewall is interfering with IPsec, it can cause SA mismatches. Test with it off for 30 seconds. If the error stops, you need to adjust your firewall rules to allow IPsec traffic (UDP 500, 4500, and ESP protocol 50).
• Check for Windows Updates: A known issue on Windows 11 23H2 (KB5032190) introduced this bug. Uninstall the update if it's recent, or install the latest cumulative update that fixes it.
• Use a different VPN protocol: If you can, switch from IPsec to WireGuard or OpenVPN. It's a workaround, not a fix, but it gets you online.

How to Prevent This From Coming Back

Once you're connected again, lock in your configuration to stop this from recurring:

• Document the exact algorithms and selectors on both sides. Use a tool like Wireshark to capture the IKE negotiation (filter esp or isakmp) and verify both sides agree.
• Set up a scheduled task to clear stale SAs weekly: netsh ipsec dynamic delete all in a script.
• If you control the firewall, reduce the SA lifetime to 8 hours (or less) so renegotiation happens more often, preventing long-lived stale SAs.

This error is frustrating, but nine times out of ten it's a policy mismatch or a stuck SA. Start with the clear command and work through the steps. You'll be back online in under 15 minutes.