Re: [iptables PATCH] extensions: libxt_conntrack: Fail on untranslatable state match

[Phil Sutter <phil@nwl.cc>]

Hi Pablo,

On Wed, Oct 21, 2026 at 12:31:08PM +0200, Pablo Neira Ayuso wrote:
> On Wed, Oct 21, 2026 at 12:17:25PM +0200, Phil Sutter wrote:
> > On Thu, Oct 08, 2026 at 08:23:51PM +0200, Phil Sutter wrote:
> > > Iptables' conntrack match supports combined matching on ct->state bits
> > > as well as the NAT bits in ct->status. The kernel extension matches if
> > > any of the bits is set, i.e. '-m conntrack --ctstate NEW,DNAT' matches
> > > packets in either NEW state or DNAT status or both. Therefore,
> > > translating this sample match into 'ct status dnat ct state new' is
> > > wrong: The nftables rule matches only if both statements match.
> > > 
> > > The only way to achieve this in nftables seems to be by duplicating the
> > > rule which is not feasible within the xlate infrastructure. So instead
> > > just abort the translation.
> > > 
> > > This is a partial revert of commit 1a13277f88099 ("extensions:
> > > libxt_conntrack: Fix for ignored ctstates in translation") which turned
> > > an incomplete translation into an incorrect one.
> > > 
> > > Cc: Balazs Gulacsi <m2gulbal@gmail.com>
> > > Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1826
> > > Fixes: 26ec09bf6b9b6 ("extensions: libxt_conntrack: provide translation for DNAT and SNAT --ctstate")
> > > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > 
> > Patch applied.
> 
> Thanks.
> 
> I wonder if it is worth filling the gap and expose snat and dnat
> through ct state in nftables.

If it's only for the purpose of providing a translation, I don't think
it's worth the effort. IMO it's just a niche feature of iptables and we
don't know how many people actually use it at all.

> This will take time to propagate before we can expose it via userspace
> (we have here the dilemma of exposing a feature which would be not
> available in old kernel, but it would in newer ones... without having
> an easy way to reject from control plane given the cmp and lookup
> expressions do not have context on the acceptables values.
> 
> Such patch should be relatively small.

I would rather spend the effort on a more fundamental issue in nftables
I found while searching for a fix, namely the lack of an OR operation.
When looking at that ticket for the first time, I assumed a(n anonymous)
helper chain could solve it, but it seems not. To implement an "a OR b"
rule, we would need verdicts which tell the calling chain it should
continue with the next statement or break. Let's try with an example:

chain c {
	jump { a return; b return; drop; } next_match verdict
	next_rule
}

This serves the 'a || b' requirement in that if either a or b (or both)
are true, evaluation continues at next_match. But the failing case does
not work: instead of continuing at next_rule, packet is dropped. Using
'accept' as the final anonymous chain's rule, we jump to the next hook.

Do we have to introduce a new verdict (possibly reactivating an existing
NF_* kernel value)?

Cheers, Phil