Re: Problems understanding nftables part 2

["Kerin Millar" <kfm@plushkava.net>]

On Wed, 29 May 2024, at 4:46 PM, Wolfgang wrote:
> Hello all,
>
> I have asked already some questions about nftables.  While diving 
> deeper into it, there
> are arising more questions.
>
>
> In my last test I have hooked rules into the 5 inet hook filter 
> destinations
> ( prerouting, input, output,postrouting, forward), to watch how packets 
> are flowing to
> my rules. Now I extended that, to see packets also flowing through nat 
> destinations,
> but I have seen no packets.
>
> 1)  It looks like, that it needs at least one configured nat-rule, 
> which gets triggered
>     to see packets flowing through the kernel. It looks like, that 
> without such an initial
>     trigger, trace is either
>     a) not showing packets
>     b) packet flow through nat is enabled only, after a first nat rule 
> matched
>        When I have a matching rule like in example 1, I see packets not 
> only in prerouting,
>        but also in input, output and postrouting, even when the chain 
> contains no nat
>        specific rule. But: For tcp this seems to be valid only for 
> packets with SYN-Flag set,
>        others are not showing up.
>     c) As soon, as I had such a trigger-packet I see however all 
> udp-traffic from the system,
>        I have not seen, before the tcp rule triggered.
>     So I have the question, if there are other options to get trace 
> through nat-hooks enabled
>     without having an initial trigger?
>     Unfortunately the "dnat" option, does not allow to add a "meta 
> nftrace set 1" behind this
>     specific line, so i must trace in a more general way.

I wouldn't consider the nat hook to be an especially useful context in which to enable tracing, partly owing to its semantics.

https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)

Instead, I would recommend using the following hook for tracing packets that arrive.

type filter hook prerouting priority raw; policy accept;

And the following hook for tracing packets that are generated by your host.

type filter hook output priority raw; policy accept;

Going about it in this way should afford you the greatest degree of insight, as regards the traversal of any given packet through your ruleset.

> 2) Prerouting, postrouting and route allow for for symbolic priorities, 
> that seems to be broken
>    for
>    a) input  and
>    b) output
>    where I need to know the corresponding value. What is the reason 
> behind this inconsistent
>    behaviour?

Unlike iptables, the design of nftables is such that all Netfilter hooks must be explicitly defined by the ruleset. Consequently, it exposes some of the rougher edges of Netfilter to the user. In particular, not all hook type and priority combinations necessarily make sense in practice. This is compounded by the matter of the nft(8) man page having tended towards under-documenting such nuances, though it has gotten a little better as of the most recent release.

During the time in which I was learning nftables, I found it useful to consider iptables as a point of reference. For instance, iptables has a built-in raw table and a built-in PREROUTING chain. One may use iptables-nft to infer how its hook is set up, in a manner whereby it is rendered explicit.

# nft flush ruleset
# iptables-nft -t raw -A PREROUTING
# nft list ruleset
table ip raw {
        chain PREROUTING {
                type filter hook prerouting priority raw; policy accept;
                counter
        }
}

The wording of the TABLES section of the iptables(8) man page can thus also be useful as a point of reference. Such a chain is suitable for acting on packets that arrive before any routing decision is made, and before the conntrack table is consulted i.e. even before a nat hook is potentially attended to. These characteristics render it particularly useful for tracing.

-- 
Kerin Millar