On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton <bcotton@xxxxxxxxxx> 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@xxxxxxxxxx > > > == 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. There's an upstream bug report on systemd about it, too[2]. This needs to be addressed in some manner before Fedora 32 beta freeze... [1]: https://ml.mageia.org/l/arc/dev/2019-12/msg00109.html [2]: https://github.com/systemd/systemd/issues/13307 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
