UPDATE: iptables-nft
(rather than iptables-legacy
) is using the nftables kernel API and in addition a compatibility layer to reuse xtables kernel modules (those described in iptables-extensions
) when there's no native nftables translation available. It should be treated as nftables in most regards, except for this question that it has fixed priorities like the legacy version, so nftables' priorities still matter here.
iptables (legacy) and nftables both rely on the same netfilter infrastructure, and use hooks at various places. it's explained there: Netfilter hooks, or there's this systemtap manpage, which documents a bit of the hook handling:
PRIORITY is an integer priority giving the order in which the probe
point should be triggered relative to any other netfilter hook
functions which trigger on the same packet. Hook functions execute on
each packet in order from smallest priority number to largest priority
number. [...]
or also this blog about netfilter: How to Filter Network Packets using Netfilter–Part 1 Netfilter Hooks (blog disappeared, using a Wayback Machine link instead.)
All this together tell that various modules/functionalities can register at each of the five possible hooks (for the IPv4 case), and in each hook they'll be called by order of the registered priority for this hook.
Those hooks are not only for iptables or nftables. There are various other users, like systemtap above, or even netfilter's own submodules. For example, with IPv4 when using NAT either with iptables or nftables, nf_conntrack_ipv4
will register in 4 hooks at various priorities for a total of 6 times. This module will in turn pull nf_defrag_ipv4
which registers at NF_INET_PRE_ROUTING/NF_IP_PRI_CONNTRACK_DEFRAG
and NF_INET_LOCAL_OUT/NF_IP_PRI_CONNTRACK_DEFRAG
.
So yes, the priority is relevant only within the same hook. But in this same hook there are several users, and they have already their predefined priority (with often but not always the same value reused across different hooks), so to interact correctly around them, a compatible priority has to be used.
For example, if rules have to be done early on non-defragmented packets, then later (as usual) with defragmented packets, just register two nftables chains in prerouting, one <= -401
(eg -450
), the other between -399
and -201
(eg -300
). The best iptables could do until recently was -300
, ie it couldn't see fragmented packets whenever conntrack, thus early defragmentation was in use (since kernel 4.15 with option raw_before_defrag
it will register at -450
instead, but can't do both, but iptables-nft
doesn't appear to offer such choice).
So now about the interactions between nftables and iptables: both can be used together, with the exception of NAT in older kernels where they both compete over netfilter's nat ressource: only one should register nat, unless using a kernel >= 4.18 as explained in the wiki. The examples nftables settings just ship with the same priorities as iptables with minor differences.
If both iptables and nftables are used together and one should be used before the other because there are interactions and order of effect needed, just sligthly lower or increase nftables' priority accordingly, since iptables' can't be changed.
For example in a mostly iptables setting, one can use nftables with a specific match feature not available in iptables to mark a packet, and then handle this mark in iptables, because it has support for a specific target (eg the fancy iptables LED target to blink a led) no available in nftables. Just register a sligthly lower priority value for the nftables hook to be sure it's done before. For an usual input filter rule, that would be for example -5
instead of 0
. Then again, this value shouldn't be lower than -149
or it will execute before iptables' INPUT mangle chain which is perhaps not what is intended. That's the only other low value that would matter in the input case. For example there's no NF_IP_PRI_CONNTRACK
threshold to consider, because conntrack doesn't register something at this priority in NF_INET_LOCAL_IN
, neither does SELinux register something in this hook if something related to it did matter, so -225
has no special meaning here.