WFP & BFE, a deep dive

Filtering & firewalling introduced WFP's layers, filters, and callouts at a conceptual level. This chapter goes one level deeper: the actual components involved, how filter configuration is stored and secured, and — notably — how some filtering works before most of Windows has even started.

Two halves: kernel enforcement, user-mode coordination

WFP splits cleanly across the same kernel/user boundary this whole course keeps returning to:

• Kernel-mode shims and the filter engine actually sit inline in the packet path, at each defined layer, matching traffic against active filters and invoking any registered callouts — this is where enforcement genuinely happens, in real time, as packets flow.
• BFE (the Base Filtering Engine, a user-mode service) coordinates configuration: it manages filter objects, handles their security (who's allowed to add, remove, or query filters — itself an access-controlled operation, per Security descriptors & ACLs), and plumbs that configuration down into the kernel-mode enforcement path.

This split matters because it means the actual, security-critical enforcement decision doesn't depend on a user-mode service being fully operational — which is exactly what makes the next section possible.

Persistent, dynamic, and boot-time filters

Filter objects in WFP aren't all created equal in terms of lifetime and timing:

• Dynamic filters are added and removed at runtime, by applications and services as needed — the most common case for ordinary firewall rule changes.
• Persistent filters survive across reboots, stored so they're available again the moment the relevant components initialize.
• Boot-time filters are the most interesting case for understanding why WFP is architected the way it is: certain critical filters can be enforced in kernel mode extremely early in boot — before BFE, a user-mode service, has even started. This closes a real security gap: without boot-time filtering, there would be a window during startup where kernel-mode networking was active but no firewall policy was yet enforced, a window a sufficiently early-running attacker could exploit.

Why this design choice matters

The alternative architecture — making all filtering purely a user-mode-configured, user-mode-enforced feature — would mean firewall protection simply wasn't present until deep into the boot sequence, after the relevant service had fully started. WFP's kernel-resident enforcement path, combined with boot-time filter persistence, closes that gap directly: the kernel can enforce policy that was configured and persisted before the current boot even began, without waiting for BFE to come online first.

A worked example: why some filtering "just works" before logon

Network traffic that needs to be blocked or permitted according to policy during early boot — before any user has signed in, before most services have started — can still be correctly filtered, because the relevant filters were marked persistent (or boot-time) and are enforced directly by the kernel-mode filter engine the moment networking becomes active, independent of BFE's own startup timing. This is a deliberate, structural property of the design, not an incidental side effect.

A common mistake

Assuming firewall rules are "just user-mode settings," fully dependent on a running service to have any effect, misses the entire reason WFP is split the way it is. The persistent and boot-time filter categories exist specifically to provide continuous enforcement across exactly the gap — early boot, before user-mode services are up — where a purely user-mode-dependent firewall implementation would otherwise leave the system unprotected.

Where this connects

• Services & background infrastructure covers BFE's own lifecycle as an ordinary Windows service, and how its startup relates to (but doesn't fully gate) WFP enforcement.
• Startup & shutdown covers where, in the overall boot sequence, kernel networking and boot-time filtering actually become active relative to user-mode service startup.