Upgrading to libvirt breaks the internett access to my guest machines
using NAT forwarding. Default firewalld is installed.

I attached the iptables rules from libvirt 10.10.0-1 (using iptables as
firewall backend) and the new one after the upgrade with the nftables as
backend.

Workaround: enable setting 'firewall_backend = "iptables"' in
/etc/libvirt/network.conf restores the old behavior.

[...]

Thanks for reaching out.

I'm no firewall expert but I see that there are some Docker rules in
there, so I think you might be hitting the same issue mentioned here:

https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables#Known_issue:_docker

Can you try disabling Docker and checking whether the libvirt
nftables backend works as expected then?

We might need to document this incompatibility more prominently, for
example in the release notes.

I see the same behavior by simply having ufw installed and enabled, no special
rules, no docker installed. Disabling ufw or manually adding blanket INPUT and
FORWARD rules to enable incoming and outgoing traffic from/to the virbr+
interfaces fixes this, but neither is a good solution.

It seems that libvirt should provide extra firewall rules if it wants to play
nicely with nftables. Having ufw (or docker, or anything else really) installed
should not prevent NAT from working. On the other hand, if for some reason this
is the new intended behavior, then the change should be documented together
with the precise list of rules needed to enable NAT when the default for INPUT
and FORWARD is DROP (i.e. usually whenever a firewall is active).

[re-added the bug report]

When using the nftables backend, the rules will not be created using
iptables so that tool won't know about them.

If you run "nftables list ruleset" you should see a bunch of
libvirt-related rules.

Note that iptables is using the same kernel API as nftables these
days, at least unless you go out of your way to tell it not to:

  $ update-alternatives --query iptables
  Name: iptables
  Link: /usr/sbin/iptables
  Slaves:
   iptables-restore /usr/sbin/iptables-restore
   iptables-save /usr/sbin/iptables-save
  Status: auto
  Best: /usr/sbin/iptables-nft
  Value: /usr/sbin/iptables-nft

  Alternative: /usr/sbin/iptables-legacy
  Priority: 10
  Slaves:
   iptables-restore /usr/sbin/iptables-legacy-restore
   iptables-save /usr/sbin/iptables-legacy-save

  Alternative: /usr/sbin/iptables-nft
  Priority: 20
  Slaves:
   iptables-restore /usr/sbin/iptables-nft-restore
   iptables-save /usr/sbin/iptables-nft-save

I agree.

This too is a known issue:

https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables#Known_issue:_non-firewalld_firewall_mgmt_tools

Both this and the Docker incompatibility are probably fine in the
context of a distro such as Fedora, where firewalld and Podman are
the "blessed" solutions in their respective fields, but Debian is
much less opinionated than that.

I need to spend some more time thinking about this, but switching the
default network backend back to iptables might be the most reasonable
solution.

Package: libvirt-daemon-driver-network
Version: 10.10.0-3
Followup-For: Bug #1090355
X-Debbugs-Cc: noisycoil@tutanota.com

Confirmed. DHCP not working is how I first learned about this issue, and the
behavior I see is that described in [1]. With respect to distros, one of the
libvirt maintainers says:

Debian has no default firewall, but ufw's popcon is 20990 vs firewalld's 5010.


[1] https://gitlab.com/libvirt/libvirt/-/issues/644

Additional data point. ufw is installed and enabled by default on
Ubuntu server. Docker is one of the documented alternatives among
container runtimes; Podman isn't.

I think it's obvious at this point that the default should go back to
iptables. Users can easily switch to nftables if desired, but things
should work reasonably well out of the box.

I'll prepare a patch and an upload over the next few days.

Thanks Andrea!