How to Inspect and Capture Windows Filtering Platform (WFP) Firewall Diagnostics Using netsh in Windows 11

Troubleshooting intermittent network connection drops, application port blocking, and unexpected firewall denials on Windows 11 often proves frustrating when standard Windows Defender Firewall logs fail to explain packet drops. Behind the graphical firewall interface sits a powerful, low-level network traffic arbitration subsystem known as the Windows Filtering Platform (WFP). Operating directly within the Windows kernel network stack between the Transport Driver Interface (TDI) and Network Driver Interface Specification (NDIS), WFP processes packets through a complex pipeline of layers, sub-layers, filter providers, and callout drivers. Third-party endpoint security software, VPN clients, and local security policies all inject custom filters into WFP. Mastering the native netsh wfp command suite allows network engineers and security administrators to capture diagnostic state dumps and isolate silent packet discards.

Understanding WFP Architecture and Filtering Hierarchy

The Windows Filtering Platform provides a modular architecture that manages packet processing rules across multiple networking layers. Every incoming and outgoing packet traverses discrete inspection checkpoints, including ALPC (Advanced Local Procedure Call) connection establishment, transport layer binding (TCP/UDP), network layer routing (IPv4/IPv6), and MAC framing.

Within each layer, WFP organizes rules into hierarchical structures:

• Providers: The entity that registered the filter rule (such as Microsoft Windows Defender Firewall, a corporate EDR sensor, or a third-party antivirus suite).
• Sub-layers: Determine execution precedence. Filters situated in higher-weight sub-layers evaluate packets before lower-weight sub-layers.
• Filter Rules: The individual condition statements evaluating IP 5-tuples (source IP, destination IP, source port, destination port, protocol). Filter actions evaluate to Permit, Block, or Callout (which passes the packet to a kernel driver for deep packet inspection).

When an application fails to establish a TCP socket despite the standard firewall displaying an “Allow” rule, a conflicting third-party callout or low-weight WFP sub-layer filter is almost always the silent culprit.

Capturing an Instantaneous WFP Diagnostic State Dump

The netsh wfp context includes a dedicated operational verb—capture—that exports the entire kernel filtering database into a structured XML archive.

1. Click the Start button, type cmd, right-click Command Prompt, and select Run as administrator.
2. Create a dedicated directory to store the diagnostic output:

   mkdir C:\WFP-Audit

3. Execute the following diagnostic capture command:

   netsh wfp capture state file=C:\WFP-Audit\wfpstate.xml

4. The utility interrogates the kernel filtering engine and exports an exhaustive XML document detailing every active filter provider, sub-layer, active filter ID, and active IPsec security association.

Capturing Real-Time Network Packet Drop Events

While an instantaneous state dump reveals existing rules, identifying which specific rule dropped a packet during a reproduction attempt requires real-time event tracing.

1. Open an elevated Command Prompt and initiate a live drop event trace:

   netsh wfp capture start file=C:\WFP-Audit\wfpdrops.cab

2. With the capture actively listening, reproduce the network failure on the Windows 11 workstation (e.g. launch the failing client application, initiate a blocked SSH connection, or execute a rejected API call).
3. Immediately return to Command Prompt and stop the capture:

   netsh wfp capture stop

4. The netsh utility consolidates the kernel trace buffers, generating an uncompressed cabinet archive containing wfpdiag.xml alongside associated Event Tracing for Windows (ETW) logs.

Analysing wfpdiag.xml to Identify Discarding Filter IDs

The generated wfpdiag.xml file documents the exact moment of packet denial and identifies the responsible filter ID.

1. Open Windows PowerShell as administrator and navigate to your audit directory:

   cd C:\WFP-Audit

2. Extract the cabinet file if inspecting a packaged trace:

   expand wfpdrops.cab -F:* .\

3. Search the XML output for discarded events by querying the <netEvent> nodes:

   Select-String -Path .\wfpdiag.xml -Pattern "FWPM_NET_EVENT_TYPE_CLASSIFY_DROP" -Context 0,15

4. Inspect the extracted event block. Locate the <filterId> element (for example, <filterId>70412</filterId>). This numeric identifier represents the exact rule that discarded the packet.
5. Next, query wfpdiag.xml or wfpstate.xml using the discovered filter ID to locate its descriptive name and provider:

   Select-String -Path .\wfpstate.xml -Pattern "<filterId>70412</filterId>" -Context 10,25

The resulting XML snippet displays the human-readable <name>, the owning <providerKey> (identifying whether Microsoft Defender Firewall, a VPN agent, or an endpoint security vendor dropped the packet), and the specific conditions that triggered the block.

Inspecting Active Security Associations and Firewall Providers

For quick terminal audits without parsing full XML files, use direct netsh wfp show commands:

• Display Active Filter Providers:

  netsh wfp show providers

  Outputs all registered security vendors injecting kernel hooks into the networking stack.

• Display Registered Sub-layers and Weights:

  netsh wfp show sublayers

  Reveals the evaluation order of security sub-systems, identifying which software suite holds overriding precedence over Windows Defender Firewall.

• Display Active IPsec Main Mode Associations:

  netsh wfp show mmsas

  Inspects active cryptographic associations for domain-isolated corporate IPsec tunnels.

Mastering netsh wfp diagnostics empowers systems administrators to see past generic connection timeout errors, definitively pinpointing kernel-level packet drops across modern Windows 11 environments.