Re: So hey let's talk about this nftables ordering situation.

On 2/21/25 7:02 PM, robinleepowell(a)gmail.com wrote: Was the discussion on a public forum somewhere? I'd like to look at exactly what they said. It does still require that the other utilities know this secret number, and agree to "anti-reject" it as we've requested, though. Also doesn't this require that libvirt's table is processed first, before the other utilities' tables? Otherwise, if the other tables are traversed before libvirt has a chance to mark the packet with the special number, they won't get the signal, so they'll reject the traffic. So I we would have set our table as a higher priority, but then what if someone else sets their table with an *even higher* priority? e.g. firewalld has "priority filter + 10" for its forwarding rules, so could make ours "priority filter + 20", but what if, e.g. docker decided to make theirs "priority filter +50"?). (yes, that's all a rhetorical question. I guess in the end everything like this that we do will chip away a bit more at the list of people who encounter problems; it will never reach 0, but it will at least get closer :-)) Aside from that, libvirt's nftables rules are default accept, and it has no rules looking at traffic that is destined for the host, only for forwarded traffic that is going *through* the host, mainly with the intent of rejecting stuff it doesn't like. So are you/they suggesting that this forwarded traffic be marked with the special "libvirt code"? Or that we should also add back rules that match input DNS/DHCP/TFTP on the libvirt-created bridges, and have them both accept and mark those packets? Just keep in mind that "iifname" has to fetch the name of the interface and do a string comparison for each packet, while "iif" just does a quick comparison of ifindex, which I think is already saved away in the skb (of course wildcards aren't possible in that case, but if you have just a couple of libvirt networks it's still more efficient to have a rule using "iif" for each interface. Yeah, that's my fault. When I added the nftables backend, I forgot to update https://libvirt.org/firewall.html (which is in docs/firewall.rst in the libvirt sources). (also at the time I wrote the code, I I keep remembering that I should do that, but only when I'm in the middle of something else and somehow I haven't managed to even write it down on a list. That's a kind of a broad solution though - libvirt's rules only reject specific traffic between libvirt-created bridges (and incoming traffic from outside a bridge's direct connects in the case of forward mode='nat'), Anywhere they allow traffic, they allow *all* of it. The real problematic stuff is traffic between the guests and the host (the rules we've had for iptables that are absent in nftables are those to allow inbound DNS, DHCP, and TFTP that are arriving on a virbr* interface, and destined for the host). If you allow *all* traffic for virbr*, then you're leaving the host wide open to all traffic from any guests (since libvirt's own rules are default accept). I think the suggestion needs to be more than just "allow all incoming on virbr*". firewall.rst should really be a shortened intro that links to the current firewall.html for iptables (maybe renaming it "iptables.rst/html"?), and to a new nftables.rst/html for information about nftables (including an explanation of the "many tables, all must resolve to 'accept' problem.) Since I've never gotten around to it in spite of wanting it done, I'd certainly be happy to review an update done by anyone else :-)