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.
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.
> >
> > What would be a good way to address that? I see at least two options:
> >
> > 1. Add a Noop firewall driver
> > 2. Implement a "real" FreeBSD driver based either on pf or ipfw (that's
> > been on my TODO list forever, but I somehow got stuck on the very first
> > step on choosing between pf and ipfw).
>
> Why not both? :-)
>
> > This obviously will take much
> > more time.
> >
> > Maybe there are other options I'm missing.
>
> Obviously (2) would be nicest, but I guess in the short term some variation
> of (1) would be quicker.
>
> Another possibility could be to restore the old behavior of saving the error
> and only reporting it when a network requiring a firewall is loaded, but I
> think I remember a discussion about this during review of an earlier
> revision of the patches, and we agreed that it made the problem easier to
> find if it was reported immediately and the driver load failed.
>
> I suppose in the long run the build-time option firewall_backend_priority
> should be used to control which backends are included in the build (rather
> than just which ones are checked at runtime), so that FreeBSD could
> completely skip all the iptables and nftables code (and firewalld when
> that's done), and Linux platforms could skip pf and ipfw.
>
> >
> > What do you think?
>
> 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.
> 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). 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).
Roman
