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, robinleepow...@gmail.com 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-c809db227...@redhat.com/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.
