Fedora 32 System-Wide Change proposal: Firewalld Default to nftables

<a href="" title=""></a>

== Summary ==
This change will toggle the default firewalld backend from iptables to
nftables. All of firewalld's primitives will use nftables while direct
rules continue to use iptables/ebtables.

== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>

== Detailed Description ==
Firewalld upstream has used nftables as the default backend for the
past two minor releases. It is also the default in other distributions
(e.g. RHEL-8). This change will bring Fedora in line with upstream.

Using nftables bring many advantages. See firewalld's upstream
[ blog post]. It also
highlights a few behavioral changes.

== Benefit to Fedora ==
* Fewer firewall rules (rule consolidation)
All of firewalld's primitives will use the same underlying firewall
(nftables) instead of duplicating rules both in iptables and
ip6tables. In nftables rules can match both IPv4 and IPv6 packets.
This reduces the number of firewall rules by half.
* firewalld's rules are namespaced
With nftables firewalld's rules are isolated to a "firewalld" table. A
separate firewall (or user) can create its own independent ruleset and
firewalld will never touch it.
* Netfilter upstream is focusing on nftables, not iptables

== Scope ==
* Proposal owners: firewalld (erig0, Eric Garver)
Currently the firewalld package has a Fedora downstream patch to hide
the nftables backend. The only firewalld change required is to remove
that patch from the package and rebuild.

* Other developers: libvirt, podman, docker
** libvirt
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** podman
*** libvirt already cooperates with the firewalld nftables backend.
The only thing needed is to test/verify.
** docker
*** Docker currently does not cooperate with the nftables backend. It
currently side-steps firewalld by injecting its own rules in iptables
ahead of firewalld's rules. However, with the nftables backend
firewalld's rule will still be evaluated. Netfilter in the kernel will
call iptables, then nftables for the same packet. This means
firewalld/nftables is likely to drop the packet even if docker has
iptables rules to ACCEPT.
*** Proposed fix 1: Docker package should provide a firewalld zone
definition that includes the docker interfaces (e.g. docker0). The
zone should use the "ACCEPT" policy (firewalld --set-target). This
will allow docker's traffic to pass through firewalld/nftables.
**** Issue 1: If a user has configured a different docker bridge name,
then they'll have to manually add the bridge to the docker zone (or
firewalld's trusted zone).
*** Proposed fix 2: Just like "Proposed fix 1", but instead of adding
the zone definition to docker we created a "docker-firewalld" (or
firewalld-docker?) package that has the zone definition. This could be
installed by default when docker is installed.
* Policies and guidelines: No updated needed.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
When users are upgraded to firewalld with nftables enabled (f32) all
their firewall rules will exist in nftables instead of iptables. All
of firewalld's primitives (zones, services, ports, rich rules, etc.)
are 100% compatible between backends.

Users of direct rules may need to consider the
[ behavioral changes]
that were announced upstream. Some are also highlighted here:

* direct rules execute before _all_ firewalld rules
** This has been requested by users
* packets dropped in iptables (or direct rules) will never be seen by firewalld
* packets accepted in iptables (or direct rules) are still subject to
firewalld's rules

== How To Test ==
Testing should mostly be integration based. Firewalld upstream has a
fairly comprehensive testsuite that covers functional testing.

The following are packages known to integrate with firewalld. They
should be tested with the nftables backend.

* libvirt
** verify VMs with different network types (bridged, routed) have
working network access
** newer version of libvirt should create and use a "libvirt"
firewalld zone. Interfaces should be dynamically added to the zone.
* podman
** verify podman adds container bridge interface to the "trusted" zone
** verify container still has network access
* docker
** known to not work with the firewalld nftables backend out of the box
** verify new package docker-firewalld installs firewalld docker zone
and has "docker0" interface added
** verify container still has network access
* fail2ban-firewalld
** verify the direct rules added to firewalld by fail2ban still block traffic

== User Experience ==
In general users shouldn't notice the change. Occasional a user will
look at the iptables rule that firewalld generates. They'll now have
to look at nftables instead.

== Dependencies ==
* libvirt >= 5.1.0
* CNI >= 0.8.0 (used by podman)
* docker-firewalld (new package)

== Contingency Plan ==
* Contingency mechanism: firewalld maintainer (erig0) will reinstate
the current patch to default to the iptables backend.
* Contingency deadline: beta freeze

== Documentation ==
* [ Firewalld blog post]