< Changes
= Libvirt Virtual Network NFTables
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
The default firewall backend for the default libvirt virtual network (the virbr0 bridge device), will change from 'iptables' to 'nftables'.
Owner
- Name: Daniel Berrange
- Email: berrange@redhat.com
Current status
- Targeted release: Fedora Linux 41
- Last updated: 2024-06-07
- [Announced]
- [<will be assigned by the Wrangler> Discussion thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
A default installation of libvirt will create an isolated bridge device (virbr0), to which guest virtual machines can have their NIC connected. Firewall rules are used to provide NAT based connectivity on this bridge device.
Historically libvirt has always used the iptables tools for configuring the required firewall rules for its virtual networks. When firewalld was introduced, libvirt added the ability to associate its bridge with a firewalld 'libvirt' zone. Firewalld switched to use nftables for its own firewall rules, and the default iptables userspace utilizes the kernel's nftables functionality. This change brings libvirt into alignment by making it use the nftables userspace too.
Feedback
TBD
Benefit to Fedora
- Libvirt will be using the same nftables userspace as firewalld instead of the legacy iptables compatibility tools.
- All the libvirt nftables rules will be self-contained in a dedicated 'libvirt_network' nftables table, reducing the scope for other applications accidentally changing/removing them.
Scope
- Proposal owners: Change the libvirt RPM spec to set the 'nftables' backend as the preferred dfault
- Other developers: N/A
- Release engineering: N/A
- Policies and guidelines: N/A
- Trademark approval: N/A
- Alignment with the Fedora Strategy:
Upgrade/compatibility impact
Existing hosts when libvirt deployed will be using iptables for their firewall rules. When libvirt is upgraded and detects the switch to nftables, it will attempt to remove the historically created iptables rules, and create new nftables rules providing equivalent functionality.
A number of iptables chains will remain present
- Chain LIBVIRT_FWI
- Chain LIBVIRT_FWO
- Chain LIBVIRT_FWX
- Chain LIBVIRT_INP
- Chain LIBVIRT_OUT
These chains should not contain and rules and thus should be harmless. They will go away permanently the next time the host is rebooted, or can be deleted manually if desired.
Contingency for incompatibilies
If an incompatibility is discovered between libvirt's nftables backend and some other use case, it is possible to tell libvirt to revert to its iptbles backend.
- Edit /etc/libvirt/network.conf and set 'firewall_backend = "iptbles"'
- systemctl restart virtnetworkd
Libvirt should then automatically delete its nftables rules and create equivalent iptables rules as present on previous Fedora.
Known issue: docker
The Docker iptables integration force changes the iptables FORWARD chain policy from ACCEPT to DENY. This makes Docker incompatible with any application that is using nftables to try to allow forwarding:
https://docs.docker.com/network/packet-filtering-firewalls/#docker-on-a-router
When libvirt uses its iptables backend, its FORWARD rules will end up in the same table as dockers', and so override the DENY policy docker had created. When libvirt uses its nftables backend, its FORWARD rules end up in a separate table from dockers'. Since nftables requires a packet to be allowed by *all* tables, docker's DENY rules will block the libvirt traffic.
The possible workarounds are:
- Reconfigure libvirt to use iptables when compatibility with docker is required
- Use podman instead of docker, since podman does not create problematic iptables rules
- TBD: whether libvirt can do something automagic to workaround docker's DENY policy
Early Testing (Optional)
Do you require 'QA Blueprint' support? N
How To Test
- Perform a default libvirt KVM install 'dnf groupinstall @Virtualization'
- Create a KVM guest using virt-install, virt-manager, or cockpit, and configure it to use the 'default' virtual network
- Boot the KVM guest
- Login to the KVM guest graphical console, and attempt to connect to the internet. eg curl https://google.com
- Configure the KVM guest to enable SSH (if not already allowed & started)
- Attempt to SSH to the guest from the host
User Experience
- Libvirt firewall rules will no longer be present when running 'iptables -L'
- A new 'libvirt_network' table will be present when running 'nft list ruleset'
Dependencies
None
Contingency Plan
- Contingency mechanism: Libvirt maintainers to change the libvirt.spec to set 'prefer_nftables' variable to '0' for Fedora 41
- Contingency deadline: Final freeze
- Blocks release? No
Documentation
General libvirt network documentation at https://libvirt.org/formatnetwork.html
Release Notes
The libvirt virtual network has been changed to prefer use of the nftables firewall backend instead of iptables.