On Tue, Oct 29, 2024 at 06:29:55PM +0100, Phil Sutter wrote:
On Tue, Oct 29, 2024 at 03:38:08PM +0000, Daniel P. Berrangé wrote:
> On Tue, Oct 29, 2024 at 04:12:16PM +0100, Phil Sutter wrote:
> > Hi,
> >
> > On Tue, Oct 29, 2024 at 09:30:27AM -0400, Laine Stump wrote:
> > > So when the extra rules are removed, then those same guests begin
> > > working? (You can easily remove the checksum rules with:
> > >
> > > nft delete chain ip libvirt_network postroute_mangle
> > >
> > > BTW, I just now tried an e1000e NIC on Fedora guest and it continues to
> > > work with the 0-checksum rules removed. In this case tcpdump on virbr0
> > > shows "bad cksum", but when I look at tcpdump on the guest, it
shows
> > > "udp cksum ok" though, so something else somewhere is setting
the
> > > checksum to the correct value.
> >
> > FWIW, I just tested an alternative workaround using tc. This works for
> > me with a FreeBSD guest and NIC switched to either e1000 or virtio:
> >
> > # tc qd add dev vnetbr0 root handle 1: htb
> > # tc filter add dev vnetbr0 prio 1 protocol ip parent 1: \
> > u32 match ip sport 67 ffff match ip dport 68 ffff \
> > action csum ip and udp
>
> This feels like it is functionally closest to what we've had historically,
> even though it is annoying to have to deal with 'tc' tool, in addition
> to 'nft'. So I'm thinking this is probably the way we'll have to
go.
Another ugly detail (inherent to 'tc') is that you have to attach a
classful qdisc to the interface since otherwise you can't add a filter
with attached action. While this may not be a problem in practice, there
is this side-effect of setting up a HTB on the bridge which by default
runs a "noqueue" qdisc.
I'm not that familiar with 'tc'.
Can you explain the functional effect of those 'qdisc' settings on
virbr0, as if I know nothing :-)
> > Another alternative might be to add the nftables rule for
virtio-based
> > guests only.
>
> The firewall rules are in a chain that's applied to all guests,
> so we have no where to add a per-guest rule.
With nftables, you may create a chain in netdev family which binds to
the specific device(s) needing the hack. It needs maintenance after
guest startup and shutdown, though.
BTW: libvirt supports configurations which don't involve a 'vnetbr0'
bridge. In this case, you will have to setup tc on the actual tap
device, right?
In those cases, we haven't historically set firewall rules, so
users were on their own, so in that sense, it isn't a regression
we need to solve. Also in those cases, the DHCP daemon would be
off-host, and so packets we're getting back from it ought to
have a checksum present, as they've been over a physical link.
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 :|