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).
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 :-)
