Adding an nftables backend in addition to iptables?
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
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 :|
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
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
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
participants (3)
-
Aljoscha Lautenbach -
Daniel P. Berrangé -
Laine Stump