On Sat, Dec 28, 2019 at 09:58:50AM -0500, Neal Gompa wrote:
On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton <bcotton(a)redhat.com>
wrote:
>
>
https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
>
> == 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: egarver(a)redhat.com
>
>
> == 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
> [
https://firewalld.org/2018/07/nftables-backend 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
> [
https://firewalld.org/2018/07/nftables-backend 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 ==
> * [
https://firewalld.org/2018/07/nftables-backend Firewalld blog post]
>
I realize I'm commenting quite late on this and it's already been
accepted, but did anyone realize that nspawn and networkd were not
compatible with firewalld in nftables mode? I didn't until it came up
in the Mageia dev mailing list[1], where someone tried to build a
firewalld-based firewall on a Mageia-based server using networkd for
network management and firewall rules were not working because
systemd's firewall-util functions are using libiptc instead of
libnftables.
The latest on the Mageia thread states it works as expected (both
iptables and nftables backends). The issue the reporter saw seems to be
unrelated to nspawn/networkd.
There's an upstream bug report on systemd about it,
too[2].
This is an RFE, not a bug.
This needs to be addressed in some manner before Fedora 32
beta freeze...
I'm not aware of any Fedora reports. Are we sure there is actually an
issue?