Portmaster: an application firewall that intercepts every packet on Windows and Linux

What Portmaster actually filters, and who it is for

Portmaster is an application firewall for Windows and Linux desktops. The README describes it as "a privacy suite for your Windows and Linux desktop", and that phrasing sets the boundary: this is not a router firmware, not a mobile app, and not an antivirus. The problem it addresses is that a desktop has dozens of processes opening sockets, and the operating system's own firewall gives you little visibility into which process owns which connection. Portmaster intercepts at the packet level, finds the owning process, and lets you write rules per application.

The intended user is someone who wants default blocking of trackers and malware domains without building a ruleset by hand, but who also wants the option to go granular. The README lists per-app settings, allowed network scopes (Localhost, LAN, Internet, P2P, Inbound), and rules based on domains, IPs and countries. A second audience is the person who wants a record of what happened: the Network History feature stores connections in a local database that you can search later, and auto-delete old entries or delete on demand. That feature is marked with a dollar sign in the README, so it sits behind the paid tier.

One design point deserves attention because it shapes everything else. The README states that everything is 100 percent local on your device, except the SPN, and that updates and intelligence data (block lists, geoip) are downloaded and applied automatically. So the filtering decision is local, but the lists it filters against arrive from Safing's infrastructure. That is a normal trade for a firewall with curated block lists, and it is worth knowing before you assume the tool is fully offline.

Packet interception, process ownership and the two-platform split

The mechanism differs by platform, and the README is explicit about both paths. On Linux, Portmaster integrates into the network stack using nfqueue; on Windows it uses a kernel driver based on the Windows Filtering Platform. Packets are intercepted at the raw packet level, which the README says means "every packet is seen and can be stopped".

Seeing a packet is not the same as knowing which program sent it. Portmaster solves that separately: on Linux it uses eBPF and /proc, and on Windows it uses a kernel driver plus the IP Helper API (iphlpapi.dll). This second step is what makes per-app rules possible. Without it you would only have IP-level rules, which is what most host firewalls give you.

The README also calls out processes whose paths are awkward to resolve: Snap, AppImage and scripts on Linux, and Windows Store apps plus svchost.exe system services on Windows. Those are exactly the cases where naive process attribution fails, so the fact that the project names them is a sign the authors hit them in practice.

The repository layout matches this split. Top-level entries include service/, runtime/, base/, spn/, cmds/, desktop/, packaging/, windows_kext/ and windows_core_dll/. The Go module is github.com/safing/portmaster, and go.mod requires Go 1.26.0 with toolchain go1.26.3. Dependencies visible in go.mod include github.com/florianl/go-nfqueue for the Linux queue path, github.com/cilium/ebpf for eBPF, github.com/google/gopacket for packet parsing, github.com/miekg/dns for DNS handling, and github.com/oschwald/maxminddb-golang for geoip lookups. The core service runs as a system service while the UI elements run in user context, which is the right split for something that needs elevated access to the network stack.

On the DNS side, the README says Portmaster intercepts "astray" DNS queries and reroutes them to itself, then resolves them through the configured DoT or DoH resolver. It also claims full support for split horizon and horizon validation to defend against rebinding attacks. That is a meaningful detail: DNS interception is where a lot of privacy tools quietly break local name resolution, and horizon handling is the part that usually goes wrong.

How to install Portmaster and set your first per-app rule

The README does not carry install commands. It points to a download page at safing.io/download and to the wiki, which has separate Install pages for Windows and Linux. Follow those pages rather than any command you find elsewhere, because the package names and repository setup are maintained there.

After installation, the README's feature list gives the order of operations. Monitoring comes first, rules second. The app shows network activity per process, and the Privacy Filter is where you define allowed network scopes and rules. The README names the scopes exactly: Localhost, LAN, Internet, P2P, Inbound. A typical first change is to take one chatty application and restrict it to the Internet scope, which stops it from reaching other machines on your LAN.

If you want to build the project from source instead of downloading a package, the README's build section is short and marked WIP. It requires Earthly and Docker Engine:

# after installing the Earthly CLI and Docker Engine
earthly +release
ls ./dist

The README says the artifacts land in ./dist. Treat this as a developer path, not an end-user install: it needs Docker, it builds the whole tree, and the README itself labels the section work in progress.

For scripting against the running service, the README links a developer API at docs.safing.io/portmaster/api and a settings handbook at docs.safing.io/portmaster/settings. Those two pages are where the actual key names live. The README does not reproduce them, so do not guess at config keys.

Where Portmaster gets in the way

The most concrete limitation is stated by the project itself: the README links a VPN Compatibility page under the wiki's Compatibility section. A tool that hooks the packet path will interact with anything else that hooks the packet path, and Safing documents that page rather than claiming there is no issue. If you run a VPN client, read that page before you install, not after.

The same applies to the Software Compatibility page, which the README also links. Portmaster intercepts DNS and reroutes queries to itself, so software with its own resolver behavior, or software that expects a specific DNS setup, is the category most likely to need attention.

A second limitation is the user interface. The README says the main UI still uses Electron as a wrapper, with a " :/ " in the sentence, and that this will change in the future. It does note you can open the UI in the browser instead. That is a real option if you dislike the desktop wrapper, but it also means the interface is a web app either way.

Platform coverage is the third constraint. The README says Windows and Linux desktop, and nothing else. There is no macOS build described, and no mobile build described. Anyone searching for Portmaster on Android, or on a handheld gaming device, is looking at a different project with a similar name.

Finally, three of the eight listed features carry a dollar sign: Network History, Per-App Bandwidth Usage, and SPN. The core firewall and the tracker and malware block lists are presented as free, but the historical record and the bandwidth view are not. If your reason for choosing Portmaster is auditing what your machine did last week, that is the paid tier, not the free one.

Portmaster compared with a plain host firewall and with a VPN

The obvious alternative is the firewall already in your operating system. Windows Firewall and nftables or iptables on Linux both filter traffic, and both are already installed. The difference in approach is attribution. A conventional host firewall matches on addresses, ports and interfaces; you write a rule for a port, and any process can use that port. Portmaster's whole design is built around the opposite question: which application opened this connection, and should it be allowed to. That is why it needs eBPF and /proc on Linux and a kernel driver plus iphlpapi.dll on Windows. If you only need to close inbound ports, the built-in firewall does that with no extra component in the packet path.

The second comparison is a VPN. A VPN moves your traffic through another endpoint and changes what the destination sees. It does not tell you which local process made a request, and it does not block a tracker inside a page you chose to open. Portmaster's SPN feature is closer to a VPN, but the README positions it separately as a network "between" VPN and Tor, with onion encryption over multiple hops, routes chosen to cover distance inside the network, and exits chosen near the destination. The README notes this automatically geo-unblocks in many cases. So SPN is an anonymizing transport, while the firewall is a local policy engine. They solve different problems, and the SPN is a paid feature hosted partly by Safing and partly by community nodes.

A third point of comparison is DNS filtering. Many privacy setups use a filtering resolver alone. That blocks domains but not IP-literal connections, and it cannot see which application asked. Portmaster's Secure DNS is one feature among several rather than the whole product, and it sits on top of packet-level interception. The trade is complexity: a filtering resolver is a single setting, whereas Portmaster puts a system service, a kernel component and a UI in the path.

Licence, maintenance and what upgrades cost you

Portmaster is licensed GPL-3.0. The repository also carries a TRADEMARKS file at the top level, which is worth noting: the code licence and the right to use the project's name and marks are separate questions, and the trademark file is where the project states its position. This is not legal advice, and if you plan to redistribute a modified build or ship it inside a product, read LICENSE and TRADEMARKS together and get your own advice.

On maintenance, the last push to the repository was on 2026-09-10, and the most recent release listed is v2.2.3 from 2026-08-14, preceded by v2.2.1 on 2026-06-16 and v2.1.19 on 2026-05-18. The repository is not archived. The release cadence visible in that list is roughly every one to two months, which is a normal rhythm for a project of this size.

The upgrade cost is not zero, and the architecture explains why. Portmaster installs a system service and, on Windows, a kernel driver; on Linux it depends on nfqueue and eBPF. Kernel-adjacent components are the ones most likely to need attention across OS updates, and the go.mod pins Go 1.26.0 with toolchain go1.26.3, so building from source tracks a recent Go release. The README says updates are fully signed and downloaded automatically, which reduces the operational burden for end users. For anyone building from source, the Earthly and Docker path in the README is the supported route, and the README marks it WIP, so expect to read the Earthfile rather than only the README.

Editorial conclusion

Adopt Portmaster if you run a Windows or Linux desktop and want per-app network rules with a local database and no cloud dependency for the core filtering. Do not adopt it if you need Android, macOS, or a handheld console, or if you want an antivirus rather than a firewall. Before installing, read the wiki's VPN Compatibility page and the Software Compatibility page, because Portmaster hooks the network stack and those two pages are where the project documents the conflicts. Then check the Settings Handbook for the exact keys of the rules you intend to write, since the README does not list them.

Frequently asked questions

Official sources

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