connection tracking state in rules

connection tracking state in rules

[Thomas Köller]

Hi,

tried to create a rule using the conntrack state of a packet:

[root@sarkovy nftables]# cat ruleset-own.txt
create table netdev world
add set netdev world blacklist { type ipv4_addr; flags dynamic,timeout; 
timeout 1h; gc-interval 6h; size 256; }
create chain netdev world ingress { type filter hook ingress device 
"eth_cable" priority filter; policy drop; }
add rule netdev world ingress ip protocol tcp ip saddr @blacklist 
counter drop
add rule netdev world ingress ct state established,related counter accept
[root@sarkovy nftables]# nft -cf ruleset-own.txt
ruleset-own.txt:5:31-38: Error: Could not process rule: Protocol error
add rule netdev world ingress ct state established,related counter accept
                               ^^^^^^^^
This is rejected, but why?

And, btw., which one is correct, 'ct state established,related' or 'ct 
state { established,related }'?

Thomas

Re: connection tracking state in rules

[Florian Westphal]

Thomas Köller <thomas@koeller.dyndns.org> wrote:
> tried to create a rule using the conntrack state of a packet:
> 
> [root@sarkovy nftables]# cat ruleset-own.txt
> create table netdev world
> add set netdev world blacklist { type ipv4_addr; flags dynamic,timeout;
> timeout 1h; gc-interval 6h; size 256; }
> create chain netdev world ingress { type filter hook ingress device
> "eth_cable" priority filter; policy drop; }
> add rule netdev world ingress ip protocol tcp ip saddr @blacklist counter
> drop
> add rule netdev world ingress ct state established,related counter accept
> [root@sarkovy nftables]# nft -cf ruleset-own.txt
> ruleset-own.txt:5:31-38: Error: Could not process rule: Protocol error
> add rule netdev world ingress ct state established,related counter accept
>                               ^^^^^^^^
> This is rejected, but why?

Conntrack state isn't available in ingress hook.

> And, btw., which one is correct, 'ct state established,related' or 'ct state
> { established,related }'?

Both work: related and established state are mutually exclusive.

established,related is a bit more compact and doesn't need the anonymous
set.

Re: connection tracking state in rules

[Pablo Neira Ayuso]

On Tue, Nov 12, 2024 at 06:56:30PM +0100, Thomas Köller wrote:
> Hi,
> 
> tried to create a rule using the conntrack state of a packet:
> 
> [root@sarkovy nftables]# cat ruleset-own.txt
> create table netdev world
> add set netdev world blacklist { type ipv4_addr; flags dynamic,timeout;
> timeout 1h; gc-interval 6h; size 256; }
> create chain netdev world ingress { type filter hook ingress device
> "eth_cable" priority filter; policy drop; }
> add rule netdev world ingress ip protocol tcp ip saddr @blacklist counter
> drop
> add rule netdev world ingress ct state established,related counter accept
> [root@sarkovy nftables]# nft -cf ruleset-own.txt
> ruleset-own.txt:5:31-38: Error: Could not process rule: Protocol error
> add rule netdev world ingress ct state established,related counter accept
>                               ^^^^^^^^
> This is rejected, but why?

Because there is currently no support for connection tracking at
ingress.

> And, btw., which one is correct, 'ct state established,related' or 'ct state
> { established,related }'?

Use of { } implies a set instance.

# nft describe ct state
ct expression, datatype ct_state (conntrack state) (basetype bitmask, integer), 32 bits

pre-defined symbolic constants (in hexadecimal):
        invalid                         0x00000001
        new                             0x00000008
        established                     0x00000002
        related                         0x00000004
        untracked                       0x00000040

Use of:

        ct state established,related

(just like in iptables --m --state) is perfectly fine for this
particular case.

Re: connection tracking state in rules

[Thomas Köller]

Am 12.11.24 um 19:24 schrieb Pablo Neira Ayuso:
> Because there is currently no support for connection tracking at
> ingress.

O.k., I guess this is probably obvious to people more familiar with the 
kernel's netfilter subsystem. For the benefit of all others, it might be 
desirable to have it documented somewhere in the nft man page (or did I 
just miss it?).

So, does this mean that I cannot use conntrack state in netdev tables, 
since these only allow for the filter/ingress combo? What I wanted to 
achieve was to create a firewall that just protects one particular 
interface, the one connected to the internet at large. Netdev seemed 
like the way to go.

Re: connection tracking state in rules

[Kerin Millar]

On Tue, 12 Nov 2024, at 7:04 PM, Thomas Köller wrote:
> Am 12.11.24 um 19:24 schrieb Pablo Neira Ayuso:
>> Because there is currently no support for connection tracking at
>> ingress.
>
> O.k., I guess this is probably obvious to people more familiar with the 
> kernel's netfilter subsystem. For the benefit of all others, it might be 
> desirable to have it documented somewhere in the nft man page (or did I 
> just miss it?).

You didn't. This constraint is formally undocumented, as are various other aspects of nft.

>
> So, does this mean that I cannot use conntrack state in netdev tables, 
> since these only allow for the filter/ingress combo? What I wanted to 
> achieve was to create a firewall that just protects one particular 
> interface, the one connected to the internet at large. Netdev seemed 
> like the way to go.

It very likely isn't, but it also depends on what the term, protects, entails in your case. You might not even need connection tracking to satisfy whatever your requirements are.

In general, I would say that, if at all in doubt, you should avoid using the netdev family. To use it effectively requires for some understanding of its raison d'être and where it fits into Netfilter at large. There is a modicum of text in the wiki that may help to better understand its strengths and weaknesses.

https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev

--
Kerin Millar