“System-level enforcement” is a specific claim. Here’s what backs it.
Some tools that call themselves firewalls mostly watch traffic and leave the real blocking to something else. Ferrite’s per-app blocking is done by Windows itself, through a mechanism you can inspect on your own machine.
The Windows Filtering Platform, not an add-on
Windows itself ships a connection-filtering framework called the Windows Filtering Platform (WFP) — it’s been part of every edition since Vista, and it’s the same framework the firewall built into Windows is built on. Ferrite’s background service talks to it directly: it opens the WFP filter engine and adds ALE filters (Application Layer Enforcement) keyed to each application’s binary identity. From that point on, Windows itself evaluates every connection attempt against those filters before the connection is allowed to proceed — not Ferrite watching after the fact and reacting.
That’s the practical difference between enforcement and observation. A tool that watches netstat output and kills processes it doesn’t like is always a step behind — there’s a window where the connection already happened. Filters registered at WFP’s connect-time layer close that window: the decision is made before the connection completes, evaluated by the OS, for that specific app.
You can see them. Ferrite’s filters sit in a WFP sublayer named Ferrite. From an elevated PowerShell, netsh wfp show filters file=filters.xml writes every filter on the machine to a file you can search for that name.
What runs through it
Per-app allow and block, destination IP and CIDR rules (v4 and v6), port and port-range rules, TCP or UDP scoping, and inbound rules are all expressed as WFP filters, in every edition including Free (Free is capped at 25 rules; Pro is unlimited). The exception is DNS-layer domain blocking, which happens in Ferrite’s own DNS: a blocked name simply gets no answer. The one thing every plan needs is a single elevation prompt at install, because adding filters to WFP requires admin rights. That’s Windows’ requirement, not a license gate.
What Ferrite adds to WFP: a packet-capture driver
WFP filters act on connection metadata — the app, the remote address, the port. They don’t see inside the traffic. For seeing, Ferrite bundles WinDivert, an open-source packet-capture driver (LGPL-3.0, loaded as a separate DLL). Ferrite’s background service loads it on every install, Free included. It is how Ferrite sees each connection’s first packet and names its protocol, and it is what the features that read or drop individual packets run on: deep inspection and DNS bypass prevention.
What Free does not get is the deep results. The server names, fingerprints, headers and payload previews the capture reads are hidden on Free and shown with Pro. The capture stays on your PC: Ferrite sends none of it anywhere, and you can check that yourself. Its license terms, the corresponding source, how to replace it and who signs it are in the Open-Source & Third-Party Notices and in section 7 of the EULA.
What Pro adds on top
Pro adds the reading-inside and the rules on it: the TLS server name, JA3, JA4 and JA4H fingerprints, HTTP headers and payload patterns, shown on each connection and usable in rules, which Ferrite enforces by dropping the packets that match. That’s a genuinely different capability from the enforcement every edition already gets, which is why it’s the paid tier — not a crippled version of that enforcement.
Where the limits are
Country/geo rules expand to that country’s published IP block set and install as the same kind of system-level filters — proven on real hardware. But WFP has a practical filter budget, and the largest IP allocators (16 of them, including the US, UK, and Germany) exceed it. Ferrite flags those as “not enforced” rather than silently pretending the block is in place. A block that isn’t real is worse than no block at all if you don’t know it isn’t real.