Fort Firewall: a standalone Windows firewall with its own driver

What Fort Firewall is for, and who it is aimed at

Windows ships a firewall, and it works. The complaint that Fort answers is not that the built-in one is broken but that it is awkward to reason about per application. Fort is a standalone firewall for Windows 7 and later, and the README lists what it adds on top of the system one: rules per application or global, matched on addresses, ports and protocols; wildcards in application path names; rules keyed to a parent process; filtering by SvcHost.exe service names; speed limit groups; blocklists through Zones; saved traffic statistics; and a graphical bandwidth display.

The audience is the person who wants to decide which binary reaches the network, not just which port is open. Parent-process rules and SvcHost service-name filtering are the two features that separate it from a port-and-address firewall: they let a rule follow how a process was launched or which service is running inside the shared host process, rather than trusting a path alone. Wildcards in application paths help when an application updates itself into a new versioned directory.

It is not a network appliance and it is not a router. It is a Windows endpoint firewall with a GUI, and the README frames it as both simple and robust, which is the author's claim rather than a measured result.

The driver is the architecture, and the architecture is the constraint

Fort is described in the README as a standalone firewall with its own driver. That single line explains most of its behaviour. The filtering does not ride on the Windows Filtering Platform rules you would manage through the built-in firewall console; Fort installs its own kernel component and the GUI configures that. The repository layout matches: src/ holds the C++ sources, deploy/ holds deployment material, and the README points to a wiki page on building.

The cost of that design is stated plainly in the system requirements. On Windows 10 and later, HVCI (Core Isolation: Memory Integrity) must be disabled. HVCI is a virtualization-based security feature that restricts what kernel code may execute, and a third-party driver of this kind is exactly the sort of code it is designed to constrain. So Fort asks you to turn off a Windows security mitigation to run.

That is a real trade, not a footnote. On a managed corporate laptop where memory integrity is enforced by policy, Fort is the wrong tool, and no amount of rule flexibility compensates. On a personal machine where the user accepts the trade in exchange for per-application control, it is a coherent choice. The README links a dedicated wiki page on HVCI, which suggests the author knows this is the first thing users hit.

Installing Fort Firewall and setting a first rule

The README does not give a command-line install procedure. It gives two prerequisites and a choice of installer. First, install the latest Visual C++ redistributable packages for your architecture; the README links x64, x86 and ARM64 builds from Microsoft. Second, on Windows 10 or later, disable HVCI (Core Isolation: Memory Integrity); the README points to a wiki page explaining how.

For the installer, the README's table is explicit. Windows 10 1809 or newer takes the x86_64 build; Windows 7 or newer takes the x86 build. Both are attached to the latest GitHub release, so the download URL is the releases page rather than a package manager. There is no documented winget, Chocolatey or scoop package in the README, and no portable archive is mentioned.

After installation the work happens in the GUI, which is why the README sends readers to the User Guide and the Rules wiki page instead of showing a config file. The features you configure there map one-to-one to the feature list: application rules, wildcards in paths, parent-process rules, SvcHost service names, Zones for blocklists, and speed limit groups. Because the README documents no configuration file format and no CLI flags, any rule you create lives in the application's own storage, and the wiki is the reference for what each field means. If you are evaluating Fort, budget time for the Rules page before you start writing rules.

Where Fort is the wrong tool

Three cases stand out.

The first is HVCI. If memory integrity must stay on, Fort cannot be installed as documented. That rules out a large share of managed endpoints, and it is worth checking before you read any further.

The second is auditability. Fort is a GUI-driven firewall with its own driver and no documented plain-text rule file or CLI in the README. If your workflow depends on rules living in version control, being reviewed in a pull request, or being deployed by a configuration management tool, Fort does not fit that workflow as documented. The wiki may cover more, but the README does not, and the README is what a new user has.

The third is scope. Fort is a Windows 7 and later product written in C++. There is no Linux, macOS or BSD build in the repository layout, and no server or gateway mode described. If you need to filter traffic for a fleet of mixed-OS machines from one policy, Fort is a per-machine tool, not a fleet tool. Its blocklists via Zones are useful for blocking address ranges on one host; they are not a substitute for DNS filtering or a network-level blocklist.

Fort Firewall against Simplewall and the built-in Windows firewall

The obvious comparison, and one people search for, is Simplewall. Both are Windows application firewalls, and the difference is in what they sit on. Simplewall is built on the Windows Filtering Platform, the same filtering engine the built-in Windows firewall uses. Fort takes the other route: the README states it is a standalone firewall with its own driver. That difference has consequences in both directions. A WFP-based tool inherits the platform's integration and does not ask you to disable HVCI for its own driver, because it is not installing one. Fort's own driver is what lets it offer parent-process rules and SvcHost service-name filtering as first-class concepts, and it is also why the HVCI requirement exists.

The second comparison is the built-in Windows firewall itself. It supports per-application rules, and for many users it is enough. Fort's additions over it are the ones the README lists: wildcards in application path names, parent process based rules, SvcHost.exe service name filtering, speed limit application groups, and Zones for blocklists. If none of those five matter to you, the built-in firewall is already installed, already integrated, and already covered by Windows Update. Fort earns its place when at least one of them does.

Maintenance, releases and the licence

Fort is not archived, and the last push to the master branch was on 2026-09-05. Releases are frequent: v3.19.7 on 2025-09-11, v3.19.8 on 2025-10-01, v3.19.9 on 2025-10-11. The version numbering suggests a steady patch cadence on top of a 3.x line rather than long gaps between major rewrites, and the README carries a ChangeLog file at the repository root for the detail.

The upgrade cost is the part that deserves attention. Because Fort installs a kernel driver, an upgrade is not just replacing an executable; the driver is replaced too, and a machine that has just changed its filtering driver is a machine worth restarting before you trust the result. The README does not document a rollback procedure for a driver upgrade, and it does not describe how to revert to the built-in firewall if you uninstall. Check the wiki before you upgrade a machine you cannot easily rebuild.

The licence is GPL-3.0, per the repository's LICENSE file. That matters most if you plan to redistribute Fort inside a product or bundle it into an image you ship. GPL-3.0 carries obligations that a permissive licence does not, and the specifics depend on your distribution model. This is not legal advice; read the LICENSE file and, if you are shipping it, talk to someone qualified. For an individual running it on their own machine, the licence is a non-issue.

Editorial conclusion

Adopt Fort if you want per-application rule control, parent-process matching and bandwidth groups on Windows 7 through current Windows 10 and 11 builds, and you are willing to disable HVCI to load its driver. Do not adopt it if memory integrity is a hard requirement on your machines, or if you want a firewall whose rules you can audit without reading a wiki. Before installing, verify three things: that the Visual C++ redistributable for your architecture is present, that Core Isolation: Memory Integrity is off, and that the installer you downloaded matches your Windows version (x86_64 for Windows 10 1809 or newer, x86 for Windows 7 or newer).

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tnodir/fort on GitHub