Filtering & firewalling

NDIS and network adapters introduced filter drivers as one of several roles in the driver chain. This chapter is about the specific, heavily-used purpose most people associate with network filtering: inspecting, permitting, blocking, or transforming traffic — the mechanism underneath Windows Firewall and most third-party network security products.

Filtering as checkpoints, not a separate universe

The most important reframing this chapter offers: the firewall is not a separate system sitting apart from the rest of networking — it's implemented as a set of checkpoints integrated directly into the same packet path covered in the TCP/IP stack and NDIS chapters. The Windows Filtering Platform (WFP) exposes these checkpoints — filtering layers — at multiple points along that path: as a connection is being established, as packets are being sent or received, at various protocol layers. A filter is a rule attached to one of these layers; a callout is an extension point that lets code (Windows Firewall's own engine, or a third-party security product) actually inspect or modify traffic at that point, rather than just matching against simple static rule criteria.

Why this matters for more than just "allow" and "block"

Because filtering happens at real, integrated checkpoints in the actual packet path — not via some separate, bolted-on interception mechanism — the same infrastructure supports far more than simple allow/deny firewall rules. Deep packet inspection, traffic redirection, encryption enforcement, and various forms of network-level security monitoring are all built on exactly the same WFP layer-and-callout model, differing only in what the registered callout actually does once it's invoked for a given piece of traffic.

A worked example: blocking an outbound connection

When Windows Firewall blocks an application's outbound connection attempt, that decision isn't happening in some separate, abstracted "firewall service" disconnected from the actual networking path — it's a filter evaluation occurring at one of WFP's real layers, directly inline with the connection attempt itself, before the attempt is allowed to proceed any further down the stack. This is exactly why firewall decisions can be made this precisely (per-application, per-port, per-destination) and this early (before a connection is even established) — the checkpoint genuinely sits at that exact point in the flow, not somewhere downstream inspecting already-sent traffic after the fact.

A common mistake

Imagining firewall rules as purely a user-mode configuration concept — settings stored somewhere and consulted abstractly — misses that enforcement genuinely happens in the kernel packet path itself, at defined WFP layers, as traffic actually flows through. This distinction matters practically: it's exactly why firewall policy can be enforced even very early in boot, before most user-mode services have started (covered further in the next chapter), and why security products building on WFP can achieve genuinely reliable, hard-to-bypass enforcement rather than something an application could simply route around.

Where this connects

• WFP & BFE, a deep dive goes one level deeper into exactly how filters are stored, managed, and enforced — including the boot-time filtering behavior mentioned above.
• Security descriptors & ACLs covers the same general concept of ordered, matched rules applied to a request — a strong conceptual parallel to how WFP filters are evaluated.