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. > 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? > > [1]: https://ml.mageia.org/l/arc/dev/2019-12/msg00109.html > [2]: https://github.com/systemd/systemd/issues/13307 _______________________________________________ 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
