9:39 a.m.
Hi!
First of all, thanks for your work on libvirt, it is highly appreciated!
When I wanted to create a new VM using virt-manager on my Debian
Testing machine yesterday, I ran into the following problem:
~# virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
default inactive yes yes
~# virsh net-start default
error: Failed to start network default
error: internal error: Failed to apply firewall rules
/usr/sbin/iptables --table filter --list-rules: iptables v1.8.6
(nf_tables): table `filter' is incompatible, use 'nft' tool.
It turns out the Debian package for iptables includes two versions of
iptables: iptables-nft and iptables-legacy. It looks like iptables-nft
has been the default in Debian for a while, which led to the error
above.
After setting iptables-legacy to be the default and restarting the
libvirtd service, everything worked as expected.
But it did make me wonder, are there any plans to add a backend for nftables?
Thanks,
Aljoscha
7:08 a.m.
On Sat, Nov 28, 2020 at 04:39:26PM +0100, Aljoscha Lautenbach wrote:
Hi!
First of all, thanks for your work on libvirt, it is highly appreciated!
When I wanted to create a new VM using virt-manager on my Debian
Testing machine yesterday, I ran into the following problem:
~# virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
default inactive yes yes
~# virsh net-start default
error: Failed to start network default
error: internal error: Failed to apply firewall rules
/usr/sbin/iptables --table filter --list-rules: iptables v1.8.6
(nf_tables): table `filter' is incompatible, use 'nft' tool.
It turns out the Debian package for iptables includes two versions of
iptables: iptables-nft and iptables-legacy. It looks like iptables-nft
has been the default in Debian for a while, which led to the error
above.
This doesn't make much sense. The whole point of iptables-nft is that
apps can continue using the (fake) iptables userspace tools and they
magically turn into NFT rules at the kernel level.
IOW, libvirt should "just work" with both iptables-legacy and
iptables-nft - that's certainly the case on Fedora/RHEL, so I
wonder what's broken on Debian to cause this error message.
After setting iptables-legacy to be the default and restarting the
libvirtd service, everything worked as expected.
But it did make me wonder, are there any plans to add a backend for nftables?
Regardless of whether iptables-nft works or not, at some point it would
be nice to directly use the "nft" tool for creating rules. We don't have
anyone with active plans to work on this, so there's no ETA though.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:25 p.m.
Hi,
IOW, libvirt should "just work" with both iptables-legacy
and
iptables-nft - that's certainly the case on Fedora/RHEL, so I
wonder what's broken on Debian to cause this error message.
I see, thank you! Based on the error message I wrongly assumed that
this was an intentionally forced transition from iptables to nft...
I confirmed that the same invocation works fine on my Kali machine, so
it certainly looks like a Debian specific bug. Out of curiosity, I
built the same version that I tried on Kali (v1.8.5) directly from the
Netfilter git repo which gives me the same error. But it is linked to
the same libnftnl library, so a wild guess would be that there's a bug
in the Debian Testing version of libnftnl.
Anyway, that is clearly off-topic for this list, I will file a bug
report for the Debian package.
Thanks again,
Aljoscha
12:55 p.m.
Hi,
sorry for the noise, I just want to follow up with the solution in
case someone else runs into this problem and finds this thread.
It turns out this is not a bug, but intended behaviour by iptables: If
you have used nft to create the same tables that iptables uses,
iptables-nft refuses to work with those. At some point I converted my
iptables rules to nft rules using "iptables-translate", which ends up
using the same namespace. In other words, the solution was to rename
the tables in my firewall rules.
Once again, thanks for your work on libvir! :)
Best regards,
Aljoscha
10:45 p.m.
On 1/11/21 1:55 PM, Aljoscha Lautenbach wrote:
Hi,
sorry for the noise, I just want to follow up with the solution in
case someone else runs into this problem and finds this thread.
It turns out this is not a bug, but intended behaviour by iptables: If
you have used nft to create the same tables that iptables uses,
iptables-nft refuses to work with those. At some point I converted my
iptables rules to nft rules using "iptables-translate", which ends up
using the same namespace. In other words, the solution was to rename
the tables in my firewall rules.
Interesting! Thanks so much for taking the often-forgotten step of
getting back to us with the new information! It will make it much easier
to deal with the next time someone reports the same problem.
Once again, thanks for your work on libvir! :)
Best regards,
Aljoscha
1442
days inactive
1487
days old
4 comments
3 participants
participants (3)
-
Aljoscha Lautenbach -
Daniel P. Berrangé -
Laine Stump