Laine Stump wrote: > On 6/12/24 2:32 PM, Roman Bogorodskiy wrote: > > Laine Stump wrote: > > > > > On 6/10/24 2:54 PM, Roman Bogorodskiy wrote: > > > > Laine Stump wrote: > > > > > > > > > This patch series enables libvirt to use nftables rules rather than > > > > > iptables *when setting up virtual networks* (it does *not* add > > > > > nftables support to the nwfilter driver). It accomplishes this by > > > > > abstracting several iptables functions (from viriptables.[ch] called > > > > > by the virtual network driver into a rudimentary "virNetfilter API" > > > > > (in virnetfilter.[ch], having the virtual network driver call the > > > > > virNetFilter API rather than calling the existing iptables functions > > > > > directly, and then finally adding an equivalent virNftables backend > > > > > that can be used instead of iptables (selected manually via a > > > > > network.conf setting, or automatically if iptables isn't found on the > > > > > host). > > > > > > > > Hi, > > > > > > > > Apparently, I'm late to the discussion. > > > > > > > > I noticed that now I cannot use the bridge driver on FreeBSD as it's > > > > failing to initialize both iptables and nftables backends (which is > > > > expect). > > > > > > Yeah, previously we wouldn't check if iptables was available until someone > > > tried to start a network that would need to use it, and would then log an > > > error (and just fail starting that network, but the network driver would > > > remain running). But now we figure out which firewall backend to use > > > immediately when the driver is loaded, and if we fail to fin a workable > > > backend we fail the entire driver init.r > > > > > > How did you use the network driver before? With a <forward mode='open'/> > > > network? Truthfully I hadn't ever considered the case of someone using it > > > with only network types that didn't need firewall rules. I wonder if there > > > are other platforms we support that have a usable network driver for > > > <forward mode='open'/> (MacOS?) > > > > I'm using it with the following network configuration: > > > > virsh # net-dumpxml default > > <network> > > <name>default</name> > > <uuid>2a1415c9-325b-41e4-82c6-e805162d8934</uuid> > > <forward mode='nat'/> > > <bridge name='virbr0' stp='on' delay='0'/> > > <mac address='52:54:00:24:fa:43'/> > > <ip address='192.168.122.1' netmask='255.255.255.0'> > > <dhcp> > > <range start='192.168.122.2' end='192.168.122.254'/> > > </dhcp> > > </ip> > > </network> > > > > So basically all the mechanics like creating tap devices, bridges, > > serving dhcp, etc, all these work for me. On top of that I had a few > > iterations of manual firewall configurations (with both ipfw and pf) > > to implement NAT on guests. > > Okay, so essentially it was effectively <forward mode='open'/> (since the > only difference is the lack of libvirt-added firewall rules). Yes, I've changed it to mode='open' and it still works for me, i.e. I have host<->guest connectivity. So it would make more sense to change the default to 'open', at least until nat is not supported. I think I'd better do that on the packaging level. Roman > > > > Unfortunately, I don't have access to that setup anymore and I haven't > > re-created it yet. IIRC, it could probably show some warnings about > > missing iptables, but it didn't affect anything for me. > > I'm surprised that there wasn't a fatal error while starting the network > though. > > > > > I'm about to be offline for 3 weeks, but in the meantime if you'd like to > > > try making a NULL backend that is only an option if it's listed in > > > firewall_backend_priority (you'll need to remove the compile-time check that > > > all possible backends are accounted for - I think that is the first of the > > > two G_STATIC_ASSERTS at the top of virNetworkLoadDriverConfig()), always > > > initializes successfully in bridge_driver_conf.c if it is listed in the > > > options, and then in networkAddFirewallRules add a check to log an error and > > > fail if backend == NULL (something about attempting to start a network type > > > that would require firewall rules, but the system not having any of the > > > supported types of firewallbackend or something - it's too late now and my > > > brain is too fried and sleepy to think of good wording :-)). As long as it > > > isn't a valid selection on Linux builds that are done with > > > firewall_backend_priority=nftables,iptables, but *is* a valid selection if > > > the setting is "firewall_backend_priority=null" that shouldn't be *too* > > > controversial. > > > > Ok, I think I can try making the NULL backend. > > Yeah, Daniel's patch will actually disable the network driver completely, > which will allow the rest of libvirt to still work, but sounds like it's not > completely what you want. I think even with a NULL firewall backend it still > should log an error and fail if someone tries to start a network that > requires firewall rules though (i.e. your above config would still fail, > unless it's changed to <forward mode='open'/>) > > > > > > > Later we can talk about pf and ipfw backends :-) > > > > Yeah, that sounds good. My main problem with the choice is that ipfw is > > the most actively supported firewall, but it relies quite heavily on the > > rule numbering, which makes it a little hard to integrate with > > user-specific rules (i.e. defined outside of libvirt). > > Well, there is a difficulty with any of the filtering systems wrt > coordinating rules from multiple independent users, so nothing new there > :-). > > > The "pf" seem to > > be better in this regard (at least to my taste), but it's not "native" > > FreeBSD firewall and is not as active (at least, to my impression). > > I guess I should read up on both of those - I haven't done anything with > packet filtering in a BSD since ipfilter back in the mid-90's :-) >
