On Mon, Jan 6, 2020 at 8:45 AM Eric Garver <egarver@xxxxxxxxxx> wrote: > > 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@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. > > 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. > No, it's definitely related, I can reproduce it. The problem is, I can also reproduce the problem going away after doing the backend switcheroo too. That confuses me a bit. > > 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? > There's also a Debian bug (in which that systemd "RFE" links to) that definitely also shows similar problems. -- 真実はいつも一つ！/ 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
