On Tue, Feb 25, 2025 at 09:20:41AM -0500, Laine Stump wrote: > On 2/25/25 1:58 AM, Robin Lee Powell wrote: > > > > On Mon, Feb 24, 2025 at 04:25:58PM -0500, Laine Stump wrote: > > > On 2/21/25 7:02 PM, robinleepowell@xxxxxxxxx wrote: > > > > So I, like many other people, have hit problems with nftables ordering, as has been discussed on this mailing list MANY TIMES. > > > > > > > > This whole thing seemed ridiculous so I asked the nftables people about what one is *supposed* to do in this situation. It turns out that the standard solution is for libvirt's nftables rules to set a packet mark (there's a collision possibility here but it's a 32 bit integer if you pick one at random it shouldn't be a problem) and then the user adds a rule to exclude packets with that mark from any reject rules they might have, or explicitly accept marked packets in their own chains, or whatever. > > > > > > Was the discussion on a public forum somewhere? I'd like to look at exactly > > > what they said. > > > > Yep! Sorry, thought I linked to it, oops. https://lore.kernel.org/netfilter/132daf73-668f-4321-8945-c809db2277f5@xxxxxxxxxx/T/#t > > Thanks! (I'm surprised I've never subscribed to that list, so that it could > be yet another folder with ever-increasing number of unread messages :-/. > Seriously though, I probably should be paying attention to it) > > My one comment about their response/advice is that, while they suggest that > libvirt shouldn't be adding any firewall rules but should instead just have > docs telling people what rules they need to add, the entire purpose of > libvirt's virtual networks was to provide essentially a single "That was > Easy" button that can be pushed which sets up *everything* needed for a > guest to communicate with the outside - the user can just say "create a > network using NAT forwarding" and libvirt creates the bridge device, sets up > the DHCP and DNS servers listening on that bridge device, turns on IP > forwarding (if it's off) and also adds all the rules necessary to allow the > traffic to pass (and to NAT the packets if that was requested). If we did > "all those things *except* the firewall rules" it would add another hurdle > for inexperienced users to get their VMs fully functional. (BTW, if someone > wants that, they can just define the network with <forward mode='open'/> and > it will setup everything except the firewall rules). Yes, that comment is really in denial about what users expect. Giving them a "bag of bits" and expecting them to assemble a working solution manually from the docs is not credible. We need this networking to "just work" out of the box. The virtual networking is/was one of the single biggest things that makes libvirt easy to use when needing serious networking capabilities, compared to direct use of QEMU (at least prior to passt, since slirp was never for serious use) 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 :|
