On Tue, Feb 25, 2025 at 02:26:44PM +0000, Daniel P. Berrangé wrote: > 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) I had exactly the same response as both of you. :) Which is why I didn't bother replying to that part.
