OpenSnitch: An Interactive Application Firewall for GNU/Linux

The problem OpenSnitch solves: outbound traffic you never see

Classic Linux firewalls, including ufw and firewalld, are built around inbound policy. They decide who may reach a service you are running. They say very little about what the programs on your machine are sending out, and they have no concept of a process identity tied to a connection.

OpenSnitch inverts that. The README describes it as a GNU/Linux application firewall with interactive outbound connections filtering. When a program opens a connection, you get a decision to make, and the decision can be attached to that program rather than to a port number. The intended audience is the desktop or workstation user who wants to know why a background daemon is talking to an address they do not recognize, and the administrator who wants that same view across several machines.

The project also lists ad, tracker and malware domain blocking, system firewall configuration from the GUI via nftables, management of multiple nodes from one GUI, and SIEM integration. Those are separate capabilities layered on the same interception path, not alternative modes.

How the daemon, the UI and the rules directory fit together

The repository is split into daemon/, ui/, proto/ and ebpf_prog/. That layout is the architecture. The daemon is the component that sits in the connection path and enforces decisions. The UI is a separate process that presents the prompt and stores your answer. The proto/ directory holds the message definitions that the two use to talk, and the Makefile builds it first, before the daemon and the GUI, which tells you the protocol is a build-time dependency of both.

The Makefile's run target shows how the pieces are wired during development. The UI is started with a socket argument, and the daemon is started with a rules path and the same socket:

opensnitch-ui --socket unix:///tmp/osui.sock &
./daemon/opensnitchd -rules-path /etc/opensnitchd/rules -ui-socket unix:///tmp/osui.sock

Both flags matter. If the socket paths disagree, the daemon has nowhere to send a prompt and the GUI has nothing to display. The rules path is where the daemon reads its configuration from, and the Makefile's test target creates a rules directory before building, which suggests the daemon expects that path to exist rather than creating it. The ebpf_prog/ directory points at the interception mechanism on modern kernels, and the README's mention of nftables for system rules confirms that OpenSnitch configures the kernel firewall rather than replacing it.

Installing OpenSnitch on Ubuntu, Fedora and Arch-based systems

The README does not document a source install for end users. It points at the releases page for deb and rpm packages and says to refer to the wiki for detailed information. On Debian and Ubuntu, the README gives this command, which installs both the daemon and the Python UI package:

sudo apt install ./opensnitch*.deb ./python3-opensnitch-ui*.deb

On Fedora and other rpm distributions, the README gives a single install line:

sudo dnf install opensnitch*.rpm

After either install, the README says to run the GUI directly or launch it from the Applications menu:

opensnitch-ui

What you should see is the OpenSnitch window, and then, as you use the machine, prompts for outbound connections that do not yet have a rule. The README does not state which service manager unit starts the daemon after a package install, so check your distribution's package contents rather than assuming. Distribution-specific packages exist beyond deb and rpm. The related searches include Opensnitch Arch, opensnitch ubuntu, Opensnitch Fedora and opensnitch nixos, and the README links a packaging status badge on repology, which is the honest place to confirm whether your distribution carries it.

Where OpenSnitch gets in your way

The cost of per-connection prompting is prompting. Every new binary that opens a socket is a decision, and a desktop session generates a lot of them. The README offers no bulk-approval workflow and no documented default-allow period, so the first hours after install are noisy by design. Rules are the escape hatch, and they live under the rules path you pass to the daemon.

The second limitation is scope. OpenSnitch is a GNU/Linux application firewall. The related searches for opensnitch windows, opensnitch macos and opensnitch mac exist because people look for it there, but the README describes no Windows or macOS support, and the daemon's build targets are Linux. If you need that, you are looking at the wrong project.

The third is operational. The UI is a GUI process, and the Makefile starts it as one. On a headless server, nobody is there to answer a prompt. The README does not describe a headless approval mode, so treat the interactive filtering feature as desktop-oriented until you find otherwise in the wiki.

Finally, the README does not document rollback, an uninstall procedure, or what happens to in-flight connections when the daemon stops. That silence is worth taking seriously before you deploy it on a machine you cannot easily reach.

OpenSnitch compared with ufw, gufw and Little Snitch

The comparison people search for most is opensnitch vs ufw, and the difference is structural rather than a matter of degree. ufw manages netfilter rules: ports, addresses, protocols, interfaces. It has no notion of which process opened a connection, because that information is not in the packet. OpenSnitch asks about the process. You can run both, and the README's nftables integration suggests OpenSnitch expects to coexist with the system firewall rather than replace it.

gufw is a graphical front end for ufw, so the same distinction applies: it makes port rules easier to write, it does not make them process-aware.

Little Snitch is the reference point the project itself invokes, and the comparison is a platform one. Little Snitch is a macOS product. OpenSnitch is the GNU/Linux answer to it, and the FAQ question about a Little Snitch alternative for Linux is essentially the project's origin story. If you are on macOS, neither OpenSnitch nor a Linux firewall helps you.

Portmaster and firewalld appear in the same searches. The README does not discuss either, so any claim about how OpenSnitch compares to them would be speculation rather than something this repository supports.

Maintenance, licensing and what an upgrade costs you

The last push to the master branch was on 2026-07-26, and the most recent release listed is v1.8.0 from 2025-12-15, following v1.7.2 in August 2025 and v1.7.1 in July 2025. That is a project with a release cadence measured in months, not weeks. The README names gustavo-iniguez-goya in the sponsorship section and points at the commit history for current maintainers, which is the honest way to see who is actually doing the work.

OpenSnitch is GPL-3.0. For most users installing a distribution package, that changes nothing about how you run it. It matters if you plan to ship OpenSnitch inside a product, link against the daemon's protocol, or modify and redistribute it, because the copyleft terms attach to derivative distribution. This is a description of the licence identifier in the repository, not legal advice; talk to someone qualified if you are embedding it.

Upgrade cost is low on the package path, since both the deb and rpm instructions are single commands over downloaded files. The risk sits in the rules directory. The Makefile passes -rules-path explicitly, so if a future release changes the expected rule format, your accumulated allow and deny decisions are the thing that breaks, and the README does not describe a migration path.

Editorial conclusion

Adopt OpenSnitch if you run a GNU/Linux desktop or workstation and want per-process visibility into outbound traffic, and you accept that every new binary will prompt you until you write a rule for it. Do not adopt it on a headless server with no one watching the GUI, on Windows or macOS where it does not run, or as a replacement for an inbound firewall policy. Verify first that a package for your distribution exists on the releases page, that the daemon and the UI can talk over the socket you configure, and that your eBPF or nftables path is available on your kernel, since the README does not document a fallback for either.

Frequently asked questions

Official sources

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