What is *supposed* to happen with automated nftables accept rules?

What is *supposed* to happen with automated nftables accept rules?

[robinleepowell]

So I'm working with a libvirt issue that partly turned out, after
many hours, to be "libvirt is adding rules to make its VMs work but
it can't override my default reject in my main nftables rule set so
nothing works for the VMs".

There are many many posts with libvirt specifically about problems
like this with nftables.  I assume similar things happen with docker
and anything else that needs to be like "yeah I know you want to
reject traffic but this system I'm managing needs to work".

The "problem" is that I have "reject with icmpx type
port-unreachable" in my INPUT chain.  Which, by the way, I got
straight from /etc/nftables/main.nft in the nftables RPM on Fedora
41 (which is what I am running).  30 years of sysadminning leads me
to believe that default-deny anything that isn't explicitely
accepted is the correct move.  :)

So my question is, what *should* happen here?  As far as I can tell,
there is absolutely nothing the libvirt tooling can do to override
my reject.  I can't jump between tables so I can't do like "jump
libvert_inp" in my chain.  What's the right move?  Options I've
thought of; I'm hoping there's something better:

- I try to add a very generic blanket accept for "traffic that's
  probably libvirt related"; I dunno can I add a rule for virbr0 if
  libvirt hasn't set it up yet?, that seems unlikely to work, and I
  can't see what else I could do for such a rule

- libvirt and I both move to firewalld which I gather doesn't have
  this problem?

- It's just expected that I have to copy the libvirt rules in
  details into my chain so the accepts happen in the right place

Surely this comes up regularly and there must be a standard
response?, but I definitely couldn't find anything on the nftables
wiki.

Re: What is *supposed* to happen with automated nftables accept rules?

[Slavko]

Hi,

On 21. februára 2025 15:40:51 UTC, robinleepowell@gmail.com wrote:

>So my question is, what *should* happen here?  As far as I can tell,
>there is absolutely nothing the libvirt tooling can do to override
>my reject.  I can't jump between tables so I can't do like "jump
>libvert_inp" in my chain.  What's the right move?  Options I've
>thought of; I'm hoping there's something better:

Basicaly, you can "overide" reject in two steps:

1. mark packets accepted by libvirt (or generaly in any other rule)
2. exlude these marks from your reject

You must check in libvirt docs, If it is able to set some mark...

regards


-- 
Slavko
https://www.slavino.sk/

Re: What is *supposed* to happen with automated nftables accept rules?

[Robin Powell]

libvirt doesn't have that currently, but that's the sort of better
solution I had in mind; I'll talk to them about it.  Thanks!

On Fri, Feb 21, 2025 at 03:50:37PM -0800, Robin Powell wrote:
> libvirt doesn't have that currently, but that's the sort of better solution
> I had in mind; I'll talk to them about it.
> 
> On Fri, Feb 21, 2025 at 9:18 AM Slavko <linux@slavino.sk> wrote:
> 
> > Hi,
> >
> > On 21. februára 2025 15:40:51 UTC, robinleepowell@gmail.com wrote:
> >
> > >So my question is, what *should* happen here?  As far as I can tell,
> > >there is absolutely nothing the libvirt tooling can do to override
> > >my reject.  I can't jump between tables so I can't do like "jump
> > >libvert_inp" in my chain.  What's the right move?  Options I've
> > >thought of; I'm hoping there's something better:
> >
> > Basicaly, you can "overide" reject in two steps:
> >
> > 1. mark packets accepted by libvirt (or generaly in any other rule)
> > 2. exlude these marks from your reject
> >
> > You must check in libvirt docs, If it is able to set some mark...
> >
> > regards
> >
> >
> > --
> > Slavko
> > https://www.slavino.sk/
> >
> >

Re: What is *supposed* to happen with automated nftables accept rules?

[Dan Winship]

On 2/21/25 10:40, robinleepowell@gmail.com wrote:
> So my question is, what *should* happen here?  As far as I can tell,
> there is absolutely nothing the libvirt tooling can do to override
> my reject.

The libvirt *tooling* can't do anything about it, but the libvirt
*documentation* can. Rather than changing your firewall rules without
telling you (!!!), libvirt should just document what network traffic
requirements it has, and let you update your firewall appropriately
yourself.

For example, [1] is the documentation from OpenShift explaining what
sort of node-to-node traffic needs to be allowed, so people creating
their own firewalls (via any technology) can avoid blocking critical
cluster traffic.

-- Dan

[1]
https://docs.openshift.com/container-platform/4.16/installing/install_config/configuring-firewall.html#network-flow-matrix_configuring-firewall