From Fedora Project Wiki


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.

Also see Changes/iptables-nft-default.

Owner

Current status

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.
  • Release engineering: [1]
  • 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
  • Blocks release? No
  • Blocks product? No

Documentation


Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/firewalld_default_to_nftables&oldid=557965"