FIX: STATUS_FWP_TRAFFIC_MISMATCH (0XC022001A)

What’s Actually Happening Here

This error shows up when Windows Defender Firewall with Advanced Security (WFAS) sees a packet that doesn’t match the IPsec security association (SA) it expects. The SA is like a handshake agreement between two machines – it says “we agreed on port X, protocol Y, and encryption Z.” When that packet shows up with different parameters, Windows drops it and logs 0XC022001A.

Real-world trigger: You disconnect from a corporate VPN, then try to access a local network share. Or you switch from a metered Wi-Fi to ethernet, and some app keeps sending old tunneled traffic. The firewall still thinks the old SA is active and rejects the new packets.

This isn’t a hardware problem. Your NIC is fine. The issue is purely in the Windows Filtering Platform (WFP) state machine.

Fix 1: Restart the Firewall Service (30 seconds)

This clears all cached SAs and forces the firewall to rebuild its state. It’s the simplest fix and works about 60% of the time.

Open Command Prompt as Administrator (Win+X > Terminal Admin).
Type:
```
net stop MpsSvc && net start MpsSvc
```
Hit Enter. Wait 5 seconds. Test your connection.

Why this works: The MpsSvc service is the Windows Defender Firewall service. Stopping it kills all active SAs in memory. Starting it reloads the policy from scratch. No old SA, no mismatch.

If the error comes back after a few minutes, move to Fix 2.

Fix 2: Reset the WFP State (5 minutes)

Sometimes restarting the service isn’t enough because the WFP driver layer holds onto stale state. You need to flush it directly.

Open PowerShell as Administrator.
Run:
```
netsh wfp show state
```
– this dumps current WFP state to a file. Not required for the fix, but useful for logging.
Then run:
```
netsh int ip reset
```
followed by
```
netsh winsock reset
```
Restart your computer.

The netsh int ip reset command rewrites the TCP/IP stack registry keys. The netsh winsock reset command resets the Winsock catalog, which is the API layer between apps and the network stack. Both commands force WFP to reinitialize its filter table. This clears any stuck SA entries.

This fix is more thorough than Fix 1 because it touches the kernel-level state, not just the user-mode service.

Fix 3: Delete Stale Security Associations Manually (15+ minutes)

If the error persists after resets, the SA is likely locked by a specific app or driver. You need to find it and kill it manually.

Open PowerShell as Administrator.
Run:
```
Get-NetSecurityAssociation
```
– this lists all active SAs. Look for ones with Status showing Offload or Pending. Those are the problematic ones.

Run:

Remove-NetSecurityAssociation -Confirm:$false

– this deletes every SA on the system.

Now check which app is creating bad SAs:

Get-NetFirewallRule | Where-Object {$_.Enabled -eq $true -and $_.Action -eq 'Block'}

Look for third-party firewall rules or leftover VPN rules. Disable any that reference old VPN adapters:
```
Disable-NetFirewallRule -DisplayName "Old VPN Rule"
```
Reboot.

The reason step 3 works is that Remove-NetSecurityAssociation directly calls the WFP API to tear down each SA object in the kernel. The firewall can’t drop traffic for a SA that doesn’t exist. Once you reboot, Windows rebuilds SAs fresh.

If you’re still stuck, check Event Viewer under Applications and Services Logs > Microsoft > Windows > Windows Firewall with Advanced Security. Look for event ID 5371 or 5372. Those log exactly which filter caused the drop.

When to Give Up and Reinstall the Driver

This is rare, but some third-party VPN clients leave behind WFP callout drivers that corrupt the state. Check Device Manager > Network adapters. If you see a “WFP Lightweight Filter” or “Virtual Miniport” from a VPN you uninstalled, right-click and uninstall it. Then reboot. The error should vanish.

Skip Fix 1 and 2 if you know you recently uninstalled a VPN – go straight to Fix 3, then check drivers.