All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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.