The Windows Filtering Platform: How Windows Firewall Actually Works Under the Hood

Windows Firewall is the visible, user-facing piece of network filtering on Windows, but underneath it sits the Windows Filtering Platform (WFP) — a considerably more general, extensible framework for inspecting and filtering network traffic at multiple layers of the stack, which both Windows Firewall itself and most third-party security software (antivirus network protection, VPN clients, endpoint security agents) build on rather than each implementing their own separate, competing low-level network hooks.

The problem WFP solves: too many things wanting to filter the same traffic

Before WFP, network filtering software on Windows typically worked by installing its own low-level network driver, hooking into the network stack at whatever point that specific vendor’s implementation chose. With multiple such products installed simultaneously — an antivirus’s network protection alongside a VPN client alongside a corporate endpoint security agent — these independently-implemented hooks could conflict, interact unpredictably, or cause outright instability, since each was inserting itself into the network stack with no coordination with any of the others doing the same thing.

What WFP provides instead: a shared, layered filtering framework

WFP defines a specific, well-documented set of layers throughout the network stack — from very low-level layers close to the network interface, up through transport-layer (TCP/UDP) filtering, up to application-layer visibility — and lets multiple independent filtering applications register callouts and filters at whichever specific layers are relevant to what they’re doing, all coordinated through the same underlying framework rather than each competing for the same insertion points independently. This is the core architectural improvement: filtering software integrates with a shared platform rather than fighting over undocumented hook points with every other filtering product installed on the same machine.

How Windows Firewall itself uses WFP

Windows Firewall’s own rule-based filtering (the rules configurable through the GUI, PowerShell’s New-NetFirewallRule, or netsh advfirewall) is implemented as filters registered against WFP, not as some separate, Firewall-specific mechanism sitting alongside WFP. This means Windows Firewall and third-party WFP-based filtering software are genuine peers within the same framework, both expressing their filtering intent through the same underlying platform, rather than Windows Firewall having privileged, special-cased access that other software has to work around.

Callouts: where custom filtering logic actually runs

Beyond simple allow/block rules based on address and port (which WFP’s basic filter conditions handle natively), WFP supports callouts — custom driver code that WFP invokes to make more complex filtering decisions requiring logic beyond simple static conditions. This is how deep-packet-inspection-style security software integrates: rather than needing its own separate network driver architecture, it registers a callout that WFP invokes at the appropriate layer, receiving the relevant packet or connection data and returning a filtering decision that WFP then enforces.

Why this matters for diagnosing network filtering conflicts

Understanding that Windows Firewall and third-party security software are typically both WFP participants, rather than entirely separate, competing mechanisms, changes how you’d actually diagnose an unexpected network blocking issue — checking netsh wfp show filters (which dumps the actual, currently active WFP filters from every registered participant, not just Windows Firewall’s own rules) reveals the complete picture of what’s actually filtering traffic on a system, including third-party software’s WFP-based filters that wouldn’t show up at all if you only checked Windows Firewall’s own rule list through its GUI.

The practical diagnostic command

netsh wfp show filters

This produces an XML dump of every active WFP filter from every registered provider on the system — considerably more complete than Windows Firewall’s own management console, which only shows Windows Firewall’s own rules and gives no visibility into what other WFP participants (third-party security software, VPN clients) might also be filtering the same traffic.

What WFP actually replaced: TDI filters and NDIS intermediate drivers

Before WFP, Windows network filtering software had exactly two realistic low-level integration points, and both were genuinely difficult to build on safely. TDI (Transport Driver Interface) filter drivers hooked into the older transport-driver model used by TCP/IP and other protocol stacks, while NDIS intermediate drivers inserted themselves into the network stack at the adapter layer, effectively pretending to be a virtual network adapter stacked on top of the real one. Both approaches required deep, largely undocumented knowledge of Windows’s internal networking architecture to implement correctly, and — because neither model was designed with multiple simultaneous filtering vendors in mind — installing more than one product built on either mechanism was a common source of blue screens and unpredictable network behavior. Windows Vista replaced both mechanisms at once: WFP superseded TDI filtering for the connection- and application-layer visibility vendors actually wanted, while NDIS 6.0 simultaneously introduced lightweight filter (LWF) drivers as the direct replacement for NDIS intermediate drivers, offering simpler registration and cleaner lifecycle management at the adapter layer. Microsoft spent years afterward trying to fully retire TDI support in later Windows versions specifically because of how failure-prone the old model had been, though full removal took considerably longer than WFP’s initial introduction, given how much legacy third-party software still depended on it.

Why building this as a shared platform, rather than leaving vendors to their own hooks, was the right call

The alternative — every network security vendor implementing independent, uncoordinated low-level network hooks — was a genuine, recurring source of system instability and unpredictable interaction effects on pre-WFP Windows versions, precisely because there was no shared framework governing how multiple simultaneous filtering mechanisms should coexist. WFP’s layered, coordinated architecture directly addresses that failure mode by giving every filtering participant, Microsoft’s own Windows Firewall included, the same well-defined integration points rather than leaving each vendor to invent and defend its own undocumented hooking approach.

Related:

Sources: