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. > > > > > > > > > [1] https://bugs.debian.org/1090355 > > > > 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 :|
