tl;dr - The goal is to have a basic firewall module with nixified rules and provide back-end modules like iptables and nftables that can implement the rules from the firewall module or be used on their own (for extended functionality). While thinking of a new design we should try to solve as much current problems as possible and consider as many use-cases as possible.

Issue description

Note: Consider this an early preview, I haven't yet to read through all issues/PRs again. Feel free to come back later if you don't want to actively participate in the discussion.

Currently we have one module services.networking.firewall that does all the work. The complete module is based around iptables and limited in functionality.

Imho we might have to rethink this in order to allow more complex setups without disabling the firewall and managing it manually (by using systemd services or nix hacks).

Currently there are the multiple ways to configure a firewall on a GNU/Linux system, the most known solutions are probably:

• iptables (the current "default")
• nftables (the successor of iptables)
• ufw (uncomplicated firewall, based on iptables)
• There are multiple console and GUI frontends for iptables (a list can e.g. be fond on the Arch-Wiki)

This list can change (and most likely will at some point). Even only both iptables and nftables would probably unnecessarily complicate the firewall module. It would therefore probably be a good idea to write a generic firewall module (which would require nixifying (basic) firewall rules) and having separate "extension" modules (like iptables and nftables) that can provide back-ends for implementing the rules from the firewall module. That way we only have to specify our firewall rules only once and a user can use an option to choose between the different back-ends. Since different back-ends can provide different functionality/extensions we should probably make sure that a user can simply disable the firewall module and e.g. use the nftables module directly.

Currently we also have the problem that we can't control the complete firewall because some other "things" (official modules like virtualisation.xen-dom0, user/custom modules(?), programs, etc.) are directly interacting with the firewall. Imho we should try to solve this by making an announcement on nix-dev and ask everyone to check whether their modules/programs require this and if we could solve this (e.g. by printing warnings/errors when a user is using an incompatible program/module together with networking.firewall.enable = true or by using the firewall module instead of the direct interaction.

Also there are some use cases which we're not covering ATM like providing a script for iptables-restore or preserving the firewall state (i.e. saving the rules via iptables-save) before shutting down.

Please let me know what you think, I would be grateful for any feedback 😄
Feel free to point out anything I missed, let me know if you disagree with something, add suggestions/questions, etc.
It might be a good idea to quote parts of this when relevant because this is a pretty complex topic (imho) and I might have to heavily edit this text (it would probably make sense to use something like Etherpad - feel free to create one or provide other suggestions).

Related

PRs

• Finer-grained firewall: allow specific hosts, in particular to SSH
• Firewall: Add support for arbitrary rules for input, output and forward
• nftables module: Add new module for nftables firewall settings

Issues

• NixOS Firewall should automatically allow ports for enabled services.
• nixos/{firewall,nat}: Standardize around an iptables-restore / nftables solution
• for nixos-rebuild, old value of firewall.extraStopCommands should be used.
• Create a "high security" profile