On Thu, Jan 30, 2025 at 12:47:41PM -0800, Andrea Bolognani wrote:
On Thu, Jan 30, 2025 at 01:20:40PM -0500, Laine Stump wrote:
On 1/30/25 10:48 AM, Andrea Bolognani wrote:
Debian 12 doesn't come with a new enough libvirt version anyway, but FYI a few months back I switched the default backend in Debian to nftables (matching Fedora) only to walk back the decision after getting several reports of it breaking software that's just too popular to ignore. See [1] for more details.
I don't expect that Debian will be able to move off the iptables backend any time soon, at least when it comes to the default. Changing the backend on a per-system basis is of course totally possible, as long as you understand the caveats.
Sigh.
In the days of iptables, there were 3 main tables (filter, nat, and mangle) and everybody's rules went into those same 3 tables. Within that single table, if a packet reached a REJECT or DROP rule before an ACCEPT rule (or the end of the table) then the packet would be dropped, but if it reached an ACCEPT rule first, then it would never see the REJECT rule, and be accepted.
But with nftables, there are an infinite number of "base tables", all traffic is evaluated against *all* tables *all the way* to either accept/reject in *all* cases, and it must get to the end of *every single table* without encountering a reject rule in order for the traffic to be accepted - there is no "early exit on accept" that skips all the rest of the tables if the traffic is accepted by one table.
[...]
There is no generic way to fix this problem. libvirt can't possible find every possible firewall system and add rules to the table of every single one that passes traffic from libvirt guests. I guess the best we can theoretically do is make a list of "supported firewall enemies" and add in extra stuff just like we currently do with firewalld - 1) attempt to autodetect if that enemy package is installed and active and then 2) add whatever rules are necessary to the enemy package's table (or the "filter" table if the enemy is still using iptables) in order to get our traffic through)
I'm not sure where I'm going with this, other than to say that, on a bad day, trying to win this seems like a losing battle - let's say we add something to counteract docker's rules, and ufw's rules (and later when those packages add nftables support then we'll need to detect whether each is using iptables or nftables, and add counteracting rules for those as well); then what's next? Sorry, it's only Thursday and I'm already feeling defeated :-/
If things really work the way you describe them, it sounds like an unsolvable problem indeed. Any scenario in which all possible components need to be aware of each other obviously doesn't scale.
That's not quite the case. libvirt shouldn't need to know about docker, and vica-verca. docker & libvirt both need to know about the base OS' choice of firewall mgmt tool (ufw, firewalld, initscripts, etc) and support whichever the base OS has used. A decent number of variations, but not a combinatorial expansion at least.
Have the nftables maintainers expressed their opinion about this? Surely they would have considered how to make filtering work without forcing extremely tight coupling.
Usage is a decision for userspace and I believe the firewalld maintainers would expect everyone to directly use firewalld's APIs to achieve their goals and not go behind its back with native calls.
I'll note that the nwfilter driver not having an nftables backend is another, if secondary, reason to stick with iptables by default. The main goal for most people is to create a deployment that's completely free of the legacy userspace, and if some other driver is going to drag it in anyway, a big part of the benefit is immediately lost...
The nwfilter driver is not a big deal as its firewall rules are entirely self-contained and attached to the vnetXXX devices which no other tool will be trying to put rules on, so there's no expected clash & I've never heard any reported. With 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 :|