simplewall: a WFP-based firewall front end for Windows

What simplewall actually filters, and for whom

simplewall is not a control UI over Windows Firewall. The README states this plainly: it does not interact with Windows Firewall at any level. Instead it configures Windows Filtering Platform (WFP), the set of internal APIs and system services that Microsoft documents as a platform for building network filtering applications. WFP is a development technology, not a firewall by itself, and simplewall is the application that drives it. That distinction matters when you troubleshoot: you will not find simplewall's rules in the Windows Firewall console, and a Windows Firewall rule will not describe what simplewall is doing.

The intended audience is stated in the README itself, under the project name: definitely for advanced users. The default posture is total block. According to the FAQ, simplewall blocks all applications by default, so you do not create rules to block specific programs; you create rules to let them out. The application is under a megabyte, supports Windows 7 SP1 and later including ARM64, and requires administrator rights to work correctly. It is a desktop tool for one machine, not a fleet product.

Inside the filter lifecycle: install, persist, disable

The mechanism to understand is that filters are installed into WFP and then live independently of the simplewall process. The FAQ answers the obvious worry directly: are internet connections blocked when simplewall is not running? Yes. Installed filters keep working even if simplewall is terminated. The GUI is a configuration surface, not the enforcement engine.

Installation of rules comes in two modes. Permanent rules stay in effect until you disable them manually. Temporary rules reset after the next reboot. This is the whole lifecycle model, and it explains the uninstall behaviour: when you uninstall simplewall, all previously configured filters stay alive in the system. To remove them, you start simplewall and press Disable filters. An uninstaller that leaves enforcement behind is a deliberate consequence of where the filters live, but it is also the single easiest way to lock yourself out of your own network and blame the wrong component.

Beyond the default block, simplewall provides a rules editor with global rules that apply to every application and special rules that apply only to named applications. Dropped packets can be logged to a file with notifications on Windows 7 and later, and allowed packets can be logged on Windows 8 and later. Windows Subsystem for Linux, Windows Store apps, Windows services, IPv6 and localization are listed as supported, and an internal blocklist aimed at Windows telemetry is available.

Installing simplewall and writing a first rule

The README points to the releases page for downloads and offers either an installer or a portable version. Administrator rights are required for correct working. For portable use, the README gives this instruction: create simplewall.ini in the application folder, or move it there from %APPDATA%\Henry++\simplewall.

# portable mode: create simplewall.ini next to the executable
# or move it from %APPDATA%\Henry++\simplewall

Filtering can also be toggled from the command line. The README lists four switches, reproduced exactly as given:

-install - enable filtering.
-install -temp - enable filtering until next reboot.
-install -silent - enable filtering without prompt.
-uninstall - remove all installed filters.

The -temp variant is the safer first experiment, because the filters disappear on the next reboot rather than persisting until you remember to disable them. The -silent variant enables filtering without a prompt.

Custom rules are entered in the rules editor, and the Apps tab of a rule sets which applications it applies to. The rule syntax accepts several forms, separated by semicolons when you need more than one entry:

192.168.0.1; [fc00::]
192.168.0.1:80; [fc00::]:443;
192.168.0.1-192.168.0.255;
192.168.0.0/16; fe80::/10
21; 80; 443;
20-21; 49152-65534;

Those lines cover bare IP addresses, IP with port, IP ranges, CIDR prefix lengths, single ports and port ranges. The README includes a full IPv4 CIDR-to-mask table and links out to a MediaWiki page for IPv6 range blocks. After enabling filtering, expect most applications to lose connectivity until you add an allow rule; that is the default-deny design working as described, not a fault.

Where simplewall is the wrong choice

The first limitation is the one the README wears as a badge: this is a tool for advanced users, and the interface assumes you know what a WFP filter is. There is no wizard that walks a non-technical user through per-application decisions. If you want a firewall that prompts you the first time an application opens a socket, the README lists the absence of annoying pop-ups as a feature, which means the prompting workflow you may expect is deliberately not there.

The second is the persistence model. Filters survive process termination and survive uninstallation. If you remove the application without pressing Disable filters first, you leave enforcement in place with no GUI to explain it. The README documents the remedy, but only in the uninstall section, and only for someone who reads it before deleting the program.

The third is scope. simplewall is Windows-only, from Windows 7 SP1 upward, and it is not a cross-platform client. Anyone searching for a macOS build is looking at the wrong project; the README lists no such target. It is also not a managed policy layer: nothing in the README describes central configuration, reporting or multi-machine deployment. For a single workstation it is a complete answer. For an organisation that needs auditable, centrally pushed rules, it is not.

simplewall vs TinyWall and Portmaster: different layers

The comparison people search for is simplewall vs TinyWall, and the difference is architectural rather than cosmetic. simplewall installs filters through Windows Filtering Platform directly and, per its own nota bene, does not interact with Windows Firewall at any level. TinyWall is commonly understood as a front end that manages Windows Firewall itself, so its rules live in the Windows Firewall rule store and are visible to Windows tooling. With simplewall you get a separate enforcement path and a separate place to look when something is blocked; with a Windows Firewall front end you get the built-in rule store and its integration. Neither approach is strictly better, but they fail differently, and the debugging steps are not interchangeable.

Against Portmaster the split is scope. Portmaster is a broader privacy and network monitoring suite, while simplewall stays close to one job: configure WFP so that applications can or cannot reach the network. If your requirement is application-level allow and deny with a small binary and no background service beyond the installed filters, simplewall's narrower surface is the point. If you want DNS-level filtering, connection inspection or a dashboard, you are shopping in a different category and simplewall will look thin.

One more distinction the README insists on: simplewall is not a control UI over Windows Firewall. If that sentence describes what you actually want, stop here.

Maintenance, packaging and the GPL-3.0 licence

simplewall is licensed under GPL-3.0, and the repository ships a LICENSE file at the top level. The practical implication for most users is minimal, since the project is distributed as a compiled Windows executable. If you modify and redistribute the code, the GPL-3.0 obligations attach to that distribution. This is a description of the licence identifier and where it lives in the repository, not legal advice; read the LICENSE file for the actual terms.

The repository is not archived, and the last push was on 2026-09-18. Recent releases are v.3.9.1 on 2026-07-22, v.3.9 on 2026-07-21 and v.3.8.7 on 2025-08-08, so the gap between 3.8.7 and 3.9 was roughly a year, followed by two releases a day apart. That pattern suggests bursts of activity rather than a steady cadence, which is worth knowing if you depend on fast fixes. The codebase is C, built from simplewall.sln with build.bat and build_vc.bat, and the README notes that the binaries carry a GPG signature, simplewall.exe.sig, in the application folder. Key ID 0x5635B5FD, fingerprint D985 2361 1524 AB29 BE73 30AC 2881 20A7 5635 B5FD. Verifying that signature before running the executable is the one upgrade-hygiene step the project itself makes possible.

Editorial conclusion

simplewall suits advanced Windows users who want per-application WFP filtering, portable mode via simplewall.ini, and a default-deny posture, and who accept that filters outlive both the process and the uninstaller. It is the wrong tool for anyone expecting a guided setup, a cross-platform client, or a managed enterprise policy layer, since the README states it is definitely for advanced users and the project targets Windows only. Before adopting it, verify the GPG signature of simplewall.exe against key ID 0x5635B5FD, and confirm that the Disable filters button in the installed build removes the filters you create.

Frequently asked questions

Official sources

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