2

I'm about to migrate a Debian Stretch host using qemu-kvm to Debian Buster.

I've seen people complaining on the Internet about issues due to nftables becoming default in place of iptables and libvirt using iptables rules. Rules automatically written by libvirt are not understood by nftables.

I can move back to iptables after the upgrade if needed:

# update-alternatives --set iptables /usr/sbin/iptables-legacy
# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
# update-alternatives --set arptables /usr/sbin/arptables-legacy
# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Would that be enough to get my system running?

From the docs and this GH comment firewalld support was added in libvirt 5.1.0. And it is unclear to me whether the minimal firewalld version required for the whole thing to work is 0.6.0 or 0.7.0.

Here are the versions shipped by Debian:

firewalld

  • stretch 0.4.4.2-1
  • buster 0.6.3-5
  • bullseye 0.7.2-1

libvirt-daemon

  • stretch 3.0.0-4+deb9u4
  • buster 5.0.0-4
  • bullseye 5.6.0-2

So I guess things should be fine in bullseye. Except for the existing rules.

Is the following plan the way to go?

  • Migrate to Buster and stick to iptables using the update-alternatives trick above.

  • When Bullseye is out, migrate and stick to iptables for now.

  • Translate rules manually and migrate to nftables later.

Edit:

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Local network
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
    bridge_ports eth0
    bridge_maxwait 0
    address 192.168.10.27
    netmask 255.255.255.0
    gateway 192.168.10.1
    dns-nameservers 192.168.10.8 192.168.1.9 8.8.8.8
    dns-domain my_domain.local
    dns-search my_domain.local

# External network
auto eth1
iface eth1 inet manual

auto br1
iface br1 inet manual
    bridge_ports eth1
    bridge_maxwait 0
Jérôme
  • 565
  • 1
  • 5
  • 18
  • @A.B You're right about firewalld, I'm not using it. I got mislead by the phrasing "libvirt 5.1.0 has native integration with firewalld and as such works well with the nftables backend." in https://github.com/firewalld/firewalld/issues/397#issuecomment-518264850. This could be a wrong lead. – Jérôme Dec 09 '19 at 11:20
  • @A.B are you implying that I'm overthinking it and it should work fine out of the box? I didn't find much posts about such issues, so maybe they only affect corner cases. – Jérôme Dec 09 '19 at 11:24
  • Thaks @A.B. We setup a bridge in the host. The host had two network interfaces, one on the local network, the other one directly connected to the outside world. The host is only accessible internally, but the guest VMs inside are accessible from the Internet but not from the local network. I added the network config file to the question. We didn't do anything related to firewalling. And I don't think we did anything specific about firewall rules when configuring virtual machines. – Jérôme Dec 09 '19 at 13:12
  • Are there any iptables rules automatically created by libvirt? Where would they be? How can I check they work with nftables (or nftables + compat layer, this iss a bit blurry to me)? Is the compatibility be maintained temporarily? Do I need to convert some rules on the long run? – Jérôme Dec 09 '19 at 13:14
  • How did you get on? AFAICT, libvirt appears to be incompatible with systems that directly use nftables (but not firewalld): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994127 But if instead you do choose to use firewalld, you get a different problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942368 – James Youngman Oct 23 '21 at 19:26
  • @JamesYoungman Well I still haven't updated yet... I was willing to do it soon, blind update, fingers crossed and see how it goes, eventually using update-alternatives for legacy compatibility. Thanks for the links, I'll look into them. – Jérôme Oct 26 '21 at 08:30
  • @JamesYoungman I just dit the Stretch -> Buster upgrade. I checked that iptables point to iptables-nft and firewalld is not installed. My old VM seem to work fine. I haven't tried to create a new VM yet. I don't know what a virtual network is so it is possible that I'm just not affected by the issue you posted above and by all those things I read on the Internet back then that made me fear the upgrade could get me into trouble. – Jérôme May 16 '22 at 13:21

1 Answers1

0

The strategy I have taken on this is to migrate the filtering rules used for VMs from nftables to libvirt's nwfilter rules. The effect of this is that libvirt manages iptables filters. In effect this is a downgrade from nftables to iptables, but my hope is that libvirt will support a later migration to nftables.

Documentation here: https://libvirt.org/formatnwfilter.html

James Youngman
  • 334
  • 1
  • 8
  • Since I've never creted a rule and I've only ever been using rules automatically created by libvirt (if any), I'm in fact wondering if I even need to do anything. – Jérôme Oct 27 '21 at 09:36