Portmaster: the desktop firewall that blocks at the packet layer

nfqueue on Linux, WFP on Windows, packets stopped early

Portmaster does not ask applications to behave. It joins the network stack from the kernel side, with nfqueue on Linux and a WFP kernel driver on Windows, and packets are intercepted at the raw packet level, so every packet is seen and can be stopped before it reaches the program that wanted it. The Go dependency list lines up with that description: the interception and parsing pieces are cilium/ebpf v0.20.0, florianl/go-nfqueue v1.3.2, google/gopacket v1.1.19 and miekg/dns v1.1.72.

github.com/cilium/ebpf v0.20.0
github.com/florianl/go-nfqueue v1.3.2
github.com/google/gopacket v1.1.19
github.com/miekg/dns v1.1.72

The scope is equally explicit. Portmaster calls itself a privacy suite for your Windows and Linux desktop, and the repository carries windows_core_dll, windows_kext, service, runtime, base, cmds, desktop, spn and packaging. Nothing here describes a macOS build, an Android build, or a handheld target, and the wiki publishes install pages only for Windows and Linux. Anyone arriving from a different platform has to settle that question with the wiki, because the source tree will not answer it.

eBPF and /proc decide which app owns a connection

Blocking by application is the whole selling point, and it rests on attribution. On Linux, ownership of connections is found with eBPF and /proc. On Windows it comes from a kernel driver plus the IP Helper API, iphlpapi.dll. Until the daemon can name the process behind a connection, every per-app setting is decoration, which is why the project spends a paragraph on processes that hide their identity: Snap, AppImage and Script support on Linux, Windows Store apps and svchost.exe system services on Windows.

That list is also the boundary of what the README promises. The project does not describe a fallback for unattributed traffic here; it points to a Software Compatibility page in the wiki and to the Settings Handbook on docs.safing.io, so whether a given executable is covered is something you check before you write a rule for it.

The service runs as system, the UI runs as your user

Two privilege levels, on purpose. The Portmaster Core Service runs as a system service, while the UI elements, named in the README as App and Notifier, run in user context. The service is the piece holding the kernel hooks, and the user-level pieces are the windows you interact with.

The desktop shell is the acknowledged weak point. The main UI still uses Electron as a wrapper, the README puts a :/ next to that sentence, and says the wrapper will change in the future. The other half of that admission is useful: you can also open the UI in the browser. That gives you a path for a machine where you would rather not run an Electron shell, and it makes the split explicit, since the browser window is only a client of a system service that has to be installed and running already.

Secure DNS reroutes the queries an app tried to keep private

A firewall that lets DNS leak is a firewall with a hole in it, so Portmaster takes the resolver path over. It intercepts "astray" DNS queries and reroutes them to itself, then resolves them through the default or configured DoT or DoH resolvers.

The part worth reading twice is split horizon support with horizon validation, which the README presents as defence against rebinding attacks. That is the mechanism that stops a name resolving to an address inside your own network while the firewall rules still see it as Internet traffic. The cost is that resolver behaviour now depends on Portmaster's interception, and apps that resolve over their own tunnel or expect a specific resolver will need the wiki's VPN Compatibility page, which the README links rather than summarizes.

Blocking a scope takes Localhost or LAN down with it

The privacy filter works by naming what a connection is allowed to reach. The scopes are Localhost, LAN, Internet, P2P and Inbound, and rules attach to Internet entities such as Domain, IP or Country. Filter Lists supply the blocklists for common malware, ad and tracker domains.

Scopes are where self-inflicted outages live. Take LAN away from an application and you have removed local network shares, local game lobbies and anything else that talks to a machine on the same segment, while a P2P scope closed takes out peer connections that a client may treat as Internet traffic. Inbound is a separate scope precisely because incoming connections are not covered by the outbound view of the rules. Nothing in the README documents a dry run, so the way to find out what a scope change costs you is the Settings Handbook on docs.safing.io/portmaster/settings plus the project's own compatibility pages.

Network history, bandwidth and SPN are the paid part

The feature list runs eight items and prices three of them with dollar signs. Record and Search Network Activity is marked with one, Per-App Bandwidth Usage with one, and the SPN privacy network with two. All three point at safing.io/pricing. The remaining five, monitoring activity, blocking anything, automatically blocking trackers and malware, global and per-app settings, and secure DNS, carry no price mark.

That split matters when you evaluate it. The free layer answers the question "what is this program doing on my network and can I stop it", and the paid layer answers "what did it do last Tuesday and which app ate my bandwidth". Network History records connections and their details in a local database that you can search later and delete automatically or on demand, which is the part you cannot reconstruct after the fact. If you are only deciding whether to try Portmaster, the free tier is enough to judge the interception model.

SPN is Tor's onion routing over Safing-hosted nodes

The SPN is described as a privacy network for use cases sitting between a VPN and Tor, and the mechanism is close to Tor's: onion encryption over multiple hops. The routing choices differ in two documented ways. Routes are chosen to cover most of the distance inside the network, and exits are picked near the destination server, which the README says geo-unblocks in many cases. You can exclude apps and domains from using SPN, and change the routing algorithm and focus per app.

Nodes are hosted by Safing, the company behind Portmaster, and by the community. The README puts speed at more than 100MBit/s and calls that decent; treat that as the project's claim rather than a measurement, since nothing here documents the hardware or the hops behind the number.

Building it yourself needs Earthly, Docker and Go 1.26

The source build is a four step list the README labels WIP. Install the Earthly CLI, install Docker Engine, run one command, then collect the artifacts.

earthly +release

The output lands in ./dist. The build is driven by the Earthfile at the repository root, with .earthlyignore keeping other paths out. The Go side is declared in go.mod as module github.com/safing/portmaster, requiring go 1.26.0 with toolchain go1.26.3. Treat the WIP label seriously if you plan to ship your own package: the supported path is the download at safing.io/download/ with wiki install pages for Windows and Linux, not a source build.

Editorial conclusion

Adopt Portmaster if you want per-app network control on a Windows or Linux desktop and accept a system service with kernel-level hooks, plus a paid tier for searchable history and SPN routing. Do not adopt it expecting file scanning, a macOS or Android build, or a free searchable history. Verify first which of the two interception paths your platform takes, nfqueue or WFP, and read the Settings Handbook at docs.safing.io/portmaster/settings before changing a scope.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. safing/portmaster on GitHub