ipset vs. nftables set

ipset vs. nftables set

[Thomas Koeller]

Hi,

migrating my existing firewall setup from iptables + ipset to nftables, I ran into a problem.

The firewall uses an ipset containing ipv4 source addresses to implement a dynamic blacklist. There are multiple rules that use this
ipset, and these rules are in chains that belong to different tables. This doesn't seem to be possible with nftables sets, that
apparently always have to belong to one and only one table, is this correct? At least I couldn't figure out how to create a set that
is accessible throughout the entire ruleset.

Thomas

Re: ipset vs. nftables set

[Kerin Millar]

On Tue, 12 Nov 2024, at 2:55 PM, Thomas Koeller wrote:
> Hi,
>
> migrating my existing firewall setup from iptables + ipset to nftables, 
> I ran into a problem.
>
> The firewall uses an ipset containing ipv4 source addresses to 
> implement a dynamic blacklist. There are multiple rules that use this
> ipset, and these rules are in chains that belong to different tables. 
> This doesn't seem to be possible with nftables sets, that
> apparently always have to belong to one and only one table, is this 
> correct? At least I couldn't figure out how to create a set that
> is accessible throughout the entire ruleset.

Yes. Rules may only reference a named set from the enclosing table.

https://bugzilla.netfilter.org/show_bug.cgi?id=1472

-- 
Kerin Millar

Re: ipset vs. nftables set

[Slavko]

On 12. novembra 2024 17:31:11 UTC, Kerin Millar <kfm@plushkava.net> wrote:
>On Tue, 12 Nov 2024, at 2:55 PM, Thomas Koeller wrote:

>Yes. Rules may only reference a named set from the enclosing table,

But one can have multiple hooks (chains) in one table, even with the
same priority (i not suggest that). Thus one can combine multiple
tables into one and share sets, eg. in raw & filter hooks.

Or one can mix iptables-nft with nftables, it requites more carefull
settings (hardcoded iptables hook's priorities, flush, etc) but it
works.

regards


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

Re: ipset vs. nftables set

[Pablo Neira Ayuso]

On Tue, Nov 12, 2024 at 05:46:50PM +0000, Slavko wrote:
> On 12. novembra 2024 17:31:11 UTC, Kerin Millar <kfm@plushkava.net> wrote:
> >On Tue, 12 Nov 2024, at 2:55 PM, Thomas Koeller wrote:
> 
> >Yes. Rules may only reference a named set from the enclosing table,
> 
> But one can have multiple hooks (chains) in one table, even with the
> same priority (i not suggest that). Thus one can combine multiple
> tables into one and share sets, eg. in raw & filter hooks.

Don't do that, please.

> Or one can mix iptables-nft with nftables, it requites more carefull
> settings (hardcoded iptables hook's priorities, flush, etc) but it
> works.

No, that is not a good idea.

Re: ipset vs. nftables set

[Florian Westphal]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > But one can have multiple hooks (chains) in one table, even with the
> > same priority (i not suggest that). Thus one can combine multiple
> > tables into one and share sets, eg. in raw & filter hooks.
> 
> Don't do that, please.

Why not?  Single-table approach makes sense, in my opinion,
provided that single table is controlled by single entity, be
that a program like firewalld or traditional sysadmin.

With multi-table things become awkward due to the imposed
scoping rules that prevent cross-table use of sets/maps.

Re: ipset vs. nftables set

[Pablo Neira Ayuso]

On Tue, Nov 12, 2024 at 07:18:55PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > But one can have multiple hooks (chains) in one table, even with the
> > > same priority (i not suggest that). Thus one can combine multiple
> > > tables into one and share sets, eg. in raw & filter hooks.
> > 
> > Don't do that, please.
> 
> Why not?  Single-table approach makes sense, in my opinion,
> provided that single table is controlled by single entity, be
> that a program like firewalld or traditional sysadmin.
>
> With multi-table things become awkward due to the imposed
> scoping rules that prevent cross-table use of sets/maps.

Sorry, I misread this email.

Single table is indeed the way to go.

Re: ipset vs. nftables set

[Kerin Millar]

On Tue, 12 Nov 2024, at 6:18 PM, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>> > But one can have multiple hooks (chains) in one table, even with the
>> > same priority (i not suggest that). Thus one can combine multiple
>> > tables into one and share sets, eg. in raw & filter hooks.
>> 
>> Don't do that, please.
>
> Why not?  Single-table approach makes sense, in my opinion,
> provided that single table is controlled by single entity, be
> that a program like firewalld or traditional sysadmin.
>
> With multi-table things become awkward due to the imposed
> scoping rules that prevent cross-table use of sets/maps.

I read it as being an objection to (potentially) using hooks that duplicate one another exactly. Mind you, if it be considered so objectionable, why doesn't nft refuse to compile rulesets that do this? Or, at least, raise a warning.

-- 
Kerin Millar

Re: ipset vs. nftables set

[Pablo Neira Ayuso]

On Tue, Nov 12, 2024 at 07:44:17PM +0000, Kerin Millar wrote:
> On Tue, 12 Nov 2024, at 6:18 PM, Florian Westphal wrote:
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >> > But one can have multiple hooks (chains) in one table, even with the
> >> > same priority (i not suggest that). Thus one can combine multiple
> >> > tables into one and share sets, eg. in raw & filter hooks.
> >> 
> >> Don't do that, please.
> >
> > Why not?  Single-table approach makes sense, in my opinion,
> > provided that single table is controlled by single entity, be
> > that a program like firewalld or traditional sysadmin.
> >
> > With multi-table things become awkward due to the imposed
> > scoping rules that prevent cross-table use of sets/maps.
> 
> I read it as being an objection to (potentially) using hooks that
> duplicate one another exactly. Mind you, if it be considered so
> objectionable, why doesn't nft refuse to compile rulesets that do
> this? Or, at least, raise a warning.

A warning to what? example?

Re: ipset vs. nftables set

[Kerin Millar]

On Tue, 12 Nov 2024, at 7:57 PM, Pablo Neira Ayuso wrote:
> On Tue, Nov 12, 2024 at 07:44:17PM +0000, Kerin Millar wrote:
>> On Tue, 12 Nov 2024, at 6:18 PM, Florian Westphal wrote:
>> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>> >> > But one can have multiple hooks (chains) in one table, even with the
>> >> > same priority (i not suggest that). Thus one can combine multiple
>> >> > tables into one and share sets, eg. in raw & filter hooks.
>> >> 
>> >> Don't do that, please.
>> >
>> > Why not?  Single-table approach makes sense, in my opinion,
>> > provided that single table is controlled by single entity, be
>> > that a program like firewalld or traditional sysadmin.
>> >
>> > With multi-table things become awkward due to the imposed
>> > scoping rules that prevent cross-table use of sets/maps.
>> 
>> I read it as being an objection to (potentially) using hooks that
>> duplicate one another exactly. Mind you, if it be considered so
>> objectionable, why doesn't nft refuse to compile rulesets that do
>> this? Or, at least, raise a warning.
>
> A warning to what? example?

First of all, what was the nature of the objection? The use of the word, that, was unclear.

If my interpretation that you were objecting to the use of multiple, equivalent hooks - with the same priority - was correct, then I'm effectively posing the question, "why doesn't the tooling reflect the underlying philosophy?"

If my interpretation was incorrect, then my post can be disregarded. However, I would still be none the wiser as to what you were instructing Slavko not to do.

--
Kerin Millar

Re: ipset vs. nftables set

[Slavko]

On 12. novembra 2024 20:23:27 UTC, Kerin Millar <kfm@plushkava.net> wrote:

>If my interpretation was incorrect, then my post can be disregarded. However, I would still be none the wiser as to what you were instructing Slavko not to do.

My intent was, that when coming from iptables, one is using
the same tables in nft as he had in iptables, and that results
in four (or more) nft's tables -- raw, nat, mangle and filter.

But in nft one can take all (needed) iptables's chains and
place them into one nft's table (per protocol or in common
inet table), as one is free to set appropriate chain's hooks
and priority. That wasn't possible in iptables, as its hooks
and priorities was hardcoded. In other words, the iptables's
tables have different purpose as nft's tables (only grouping).

And as one is free to set chain's/hook's priority, he even
can set the same priority (and hook) for multiple chains in
the same table and it will not be error, but often it is not what
one want, as its order is then undefined.

regards


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

Re: ipset vs. nftables set

[Pablo Neira Ayuso]

On Tue, Nov 12, 2024 at 03:55:13PM +0100, Thomas Koeller wrote:
> Hi,
> 
> migrating my existing firewall setup from iptables + ipset to nftables, I ran into a problem.
> 
> The firewall uses an ipset containing ipv4 source addresses to implement a dynamic blacklist. There are multiple rules that use this
> ipset, and these rules are in chains that belong to different tables. This doesn't seem to be possible with nftables sets, that
> apparently always have to belong to one and only one table, is this correct? At least I couldn't figure out how to create a set that
> is accessible throughout the entire ruleset.

Then, unify your tables in one global inet table.