From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Julius Bairaktaris <julius@bairaktaris.de>
Cc: netfilter-devel@vger.kernel.org, kadlec@netfilter.org,
fw@strlen.de, coreteam@netfilter.org, netdev@vger.kernel.org,
geldot@protonmail.com, shuah@kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH nf-next v2 1/4] netfilter: conntrack: pick up a TCP flow whose SYN was never answered
Date: Sun, 18 Oct 2026 03:36:11 +0200 [thread overview]
Message-ID: <atQii0cO-HJb5TQ7@chamomile> (raw)
In-Reply-To: <20261004171628.3544978-2-julius@bairaktaris.de>
On Sun, Oct 04, 2026 at 07:16:25PM +0200, Julius Bairaktaris wrote:
> From: Gary Dotzler <geldot@protonmail.com>
>
> When only one direction of a connection passes the host, conntrack sees
> the SYN but not the SYN/ACK. The client's next ACK is invalid in
> SYN_SENT, as is every packet after it.
>
> Had the SYN not been seen, the loose pickup in tcp_new() would have
> taken that ACK, with window checks off in both directions. Delete the
> SYN_SENT entry and look the packet up again so that tcp_new() picks it
> up. This applies only with nf_conntrack_tcp_loose, without synproxy,
> before any reply, and to an original direction ACK at the expected
> sequence number. No TCP state or transition is added.
>
> Signed-off-by: Gary Dotzler <geldot@protonmail.com>
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
> ---
> net/netfilter/nf_conntrack_proto_tcp.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> index ad6f1986d52a..31bd4b926e48 100644
> --- a/net/netfilter/nf_conntrack_proto_tcp.c
> +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> @@ -1173,6 +1173,22 @@ int nf_conntrack_tcp_packet(struct nf_conn *ct,
> return NF_ACCEPT;
> }
>
> + /* No reply seen and the client continues after its SYN: the
> + * reply takes another path. Recreate the entry through the
> + * loose pickup in tcp_new().
> + */
> + if (tn->tcp_loose && !nfct_synproxy(ct) &&
> + old_state == TCP_CONNTRACK_SYN_SENT &&
> + index == TCP_ACK_SET && dir == IP_CT_DIR_ORIGINAL &&
> + !test_bit(IPS_SEEN_REPLY_BIT, &ct->status) &&
> + ntohl(th->seq) == ct->proto.tcp.seen[dir].td_end) {
> + spin_unlock_bh(&ct->lock);
> +
> + if (nf_ct_kill(ct))
> + return -NF_REPEAT;
> + return NF_DROP;
> + }
I bet we will get more workaround patches like this soon to make this
work.
What is the point of TCP tracking this flow if it does not see all
traffic?
> +
> /* Invalid packet */
> spin_unlock_bh(&ct->lock);
> nf_ct_l4proto_log_invalid(skb, ct, state,
> --
> 2.53.0
>
next prev parent reply other threads:[~2026-10-18 1:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 17:16 [PATCH nf-next v2 0/4] netfilter: offload a TCP flow whose reply is never seen Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 1/4] netfilter: conntrack: pick up a TCP flow whose SYN was never answered Julius Bairaktaris
2026-10-18 1:36 ` Pablo Neira Ayuso [this message]
2026-10-04 17:16 ` [PATCH nf-next v2 2/4] netfilter: flowtable: promote a flow offloaded in one direction only Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 3/4] netfilter: nft_flow_offload: offload a TCP flow that has no reply Julius Bairaktaris
2026-10-04 17:16 ` [PATCH nf-next v2 4/4] selftests: netfilter: cover a TCP flow whose reply is never seen Julius Bairaktaris
2026-10-17 10:37 ` [PATCH nf-next v2 0/4] netfilter: offload " Julius Bairaktaris
2026-10-18 1:42 ` Pablo Neira Ayuso
2026-10-18 1:54 ` Julius Bairaktaris
2026-10-18 2:00 ` Pablo Neira Ayuso
2026-10-18 2:02 ` Julius Bairaktaris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atQii0cO-HJb5TQ7@chamomile \
--to=pablo@netfilter.org \
--cc=coreteam@netfilter.org \
--cc=fw@strlen.de \
--cc=geldot@protonmail.com \
--cc=julius@bairaktaris.de \
--cc=kadlec@netfilter.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.