[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aPi8h_Ervgips4X4@strlen.de>
Date: Wed, 22 Oct 2025 13:14:23 +0200
From: Florian Westphal <fw@...len.de>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Andrii Melnychenko <a.melnychenko@...s.io>, kadlec@...filter.org,
phil@....cc, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/1] nft_ct: Added nfct_seqadj_ext_add() for NAT'ed
conntrack.
Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > so client will eventually retransmit the connection request.
> >
> > I can also mangle this locally, let me know.
>
> BTW, this fixes DNAT case, but SNAT case is still broken because flag
> is set at a later stage, right?
Hmm, why? nf_nat_setup_info() will add seqadj extension if a helper
is assigned. I only see two nat cases:
The helper is assigned, no NAT was requested.
Then, in postrouting, a NAT rule gets triggered.
nf_nat_setup_info() will add the seqadj extension for us.
This case doesn't need this patch. Broken scenario:
NAT rule gets triggered, no helper is assigned yet.
Then, 'helper set foo' rule gets triggered.
This case missed the seqadj extension add.
An alternative would be to reject 'helper set foo' rule add unless the
expression is called from prerouting or output with a priority that is
after conntrack but before nat.
But its more risky change, it would surely break some setups.
Powered by blists - more mailing lists