STATUS_FWP_MATCH_TYPE_MISMATCH (0XC0220026) – The real fix

What actually triggers this

This error shows up when Windows Filtering Platform (WFP) can't apply a filter rule because the match type you've set doesn't line up with the operand you've given it. I've seen it most often in two places: a custom firewall rule that's trying to compare an IP address with a port range, or a VPN connection rule that's doing something like matching a string against a numeric value.

Had a client last month whose VPN client kept crashing with this. Turns out they'd imported a rule from an old Windows 8 machine that tried to match FWP_MATCH_EQUAL against a FWP_UINT32 for a subnet mask—it was a string in the rule file. Took me an hour to track down because the error message doesn't tell you which rule is broken. So you've got to hunt for it.

The most common cause: a mismatched firewall rule

If you've manually added firewall rules—especially through Group Policy or a third-party firewall tool—you've likely set a condition like "match this IP address" but the condition type expects a range or a subnet. WFP has strict types: FWP_MATCH_EQUAL only works with exact values, FWP_MATCH_RANGE needs a low and high, etc. Mix them up and you get 0xC0220026.

How to find the bad rule

1. Open an elevated PowerShell or Command Prompt.
2. Run netsh wfp show filters. This dumps every WFP filter. It's a lot of output, so pipe it to a file: netsh wfp show filters > C:\WFP_filters.txt
3. Search for the error in Event Viewer. Look under Windows Logs > System or Security with Event ID 5440 or 5446. Those events often name the filter that failed.
4. Once you've got the filter GUID, go back to your firewall tool or Group Policy and delete or correct that rule.

In Windows Defender Firewall with Advanced Security, right-click the rule, go to Properties > Conditions tab, and check the Interface types and Protocols and Ports sections. If you see something like "Any IP address" matched with "Equal to", that's your culprit. Change it to a valid match type for the field.

Second cause: VPN or IPsec policy rule mismatch

This is the one that trips up people using built-in Windows VPN or DirectAccess. The IPsec policy rules in WFP are picky about match types. If you've configured a connection security rule in Windows Defender Firewall that says "Match a specific IP address" but the rule is for a tunnel mode that expects a subnet range, you get this error.

Fix it by checking your connection security rules

1. Open Windows Defender Firewall with Advanced Security.
2. Click Connection Security Rules in the left pane.
3. Right-click any rule that's misbehaving and choose Properties.
4. Go to the Advanced tab and look at the IPsec tunneling settings. If it's set to Specific IP address but your endpoints are subnets, change it to Subnet or IP address range.
5. Also check the Authentication tab—sometimes a certificate match type got set to FWP_MATCH_EQUAL when it needed FWP_MATCH_FLAGS_ALL_SET.

Third cause: third-party security software creating bad rules

I've seen this with older versions of Symantec Endpoint Protection, McAfee, and even some VPN clients (looking at you, OpenVPN GUI). They inject WFP filters on install and can create rules with invalid match types if the software's database gets corrupted or is from an old version.

Quick test

1. Temporarily disable the third-party firewall or VPN client.
2. Reboot and see if the error goes away.
3. If it does, update the software to the latest version or reinstall it cleanly.
4. If you can't update, you may need to manually delete the filter. Run netsh wfp show filters again, find the filter GUID associated with that software, then delete it with netsh wfp delete filter guid={GUID}. But be careful—deleting the wrong one can break internet access.

Quick-reference summary table