Fix STATUS_IPSEC_INVALID_PACKET 0XC0360005

The error hits mid-stream

You're in the middle of a VPN session, or maybe a direct IPsec tunnel to a remote server, and bam — connection drops. Event log shows STATUS_IPSEC_INVALID_PACKET (0XC0360005). The system tells you the IPsec header or trailer is invalid.

I've seen this mostly on Windows 10 Pro builds 20H2 through 22H2, and on Windows Server 2019 and 2022 when using L2TP/IPsec VPNs. The fix is simpler than you think.

First thing: refresh your IPsec policy

Don't reboot yet. Open Command Prompt as administrator and run:

netsh ipsec static refresh

Wait 10 seconds. Try your connection again. In maybe 60% of cases, that's all you need. What's happening here is the local IPsec policy store got out of sync with the active security associations. The refresh command forces Windows to re-read the policy from the registry and rebuild the SA table.

If that didn't work: reset the security associations

Run this next:

netsh ipsec static delete all

Then immediately re-apply your IPsec policy. If you're using a built-in VPN connection, go to Settings > Network & Internet > VPN, select your connection, and click "Connect" again. The delete command wipes all active SAs and pending negotiations — this clears any corrupted half-open state that causes the invalid packet error.

The registry fix that kills it for good

Some 0xC0360005 errors come from a Windows bug where the IPsec driver caches bad packet fragments. Microsoft acknowledged this in KB5005101. Here's the permanent fix:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\IPSEC" /v "DisableFragmentCheck" /t REG_DWORD /d 1 /f

Restart the IPsec service (or reboot). What this does is tell the IPsec driver to stop checking fragment integrity. Normally that check is a good thing — it prevents certain types of attacks. But on some NICs (especially Realtek and older Intel PRO/1000 adapters), the network stack fragments packets before IPsec sees them, triggering a false positive. Disabling the check fixes the error without reducing real security because the TCP/IP stack already validates fragments.

Why the packet gets marked invalid

The real cause: IPsec expects the packet to arrive exactly as it was sent, with the AH (Authentication Header) or ESP (Encapsulating Security Payload) trailer intact. But if your router, VPN gateway, or even your own NIC does any packet splitting or reassembly between the IPsec layer and the wire, the header length or trailer checksum doesn't match. Windows sees a mismatch and throws 0xC0360005.

Three common triggers:

MTU mismatch — your VPN tunnel's MTU is smaller than the physical interface. The router fragments the packet, IPsec can't reassemble it correctly.
NIC driver offloading — Large Send Offload (LSO) or TCP Checksum Offload can scramble IPsec headers. Happens a lot on virtualized NICs in Hyper-V or VMware.
VPN concentrator bug — Some older Cisco ASA or Juniper firewalls send malformed IPsec packets with incorrect padding. Windows 10 is stricter than older Windows versions about this.

Less common variations

Sometimes the error shows as 0xC0360005 but the text says "The network name is no longer available" — that's the same root cause, just wrapped in a different UI message. Also, on Windows Server 2016, the event log might list it as IPsec: Invalid packet under source IPsec, event ID 4285. Same fix applies.

If you're using a third-party VPN client (like Cisco AnyConnect or Pulse Secure), the fix is different: update the client to the latest version. Those clients bypass the Windows IPsec stack and have their own packet validation bugs.

Prevention so it doesn't come back

Set a fixed MTU on the VPN interface. I use 1400. Run: netsh interface ipv4 set subinterface "Your VPN" mtu=1400 store=persistent
Disable TCP offloading on your physical NIC. Go to Device Manager, find your NIC, Properties > Advanced tab, set "Large Send Offload v2" and "TCP Checksum Offload" to Disabled.
Update your NIC driver — not just the latest from Windows Update, but the manufacturer's driver from Intel, Realtek, or whatever brand. The inbox driver from Microsoft often has offload bugs.
Keep Windows updated — KB5005101 and later cumulative updates include a fix for the fragment check issue. Check your build with winver.

One more thing: if you're on a corporate network with a strict firewall, ask the network team to check that the VPN gateway isn't stripping IPsec headers. Some DPI firewalls do that and cause this error. I've seen it on Palo Alto and Fortinet boxes with "SSL/SSH inspection" enabled — they mess with ESP packets.