Re: [PATCH nf-next 0/4] netfilter: offload a TCP flow whose reply is never seen

Hi Julius,

On Fri, Sep 11, 2026 at 12:10:04PM +0000, Julius Bairaktaris wrote:

Hi Pablo,

thanks for taking your time to review.

quoted

conntrack needs to see packets in both directions, are you assuming a
packet-based load balancer in front of it?

No, an asymmetric route is in front of it, with two subnets sharing one
L2 segment and the server answering over that link, so the router only
ever sees one direction.

I see this requirement to support asymmetric path keeps coming, but
how hard is really to maintain this TCP state machine to deal with all
possible scenarios? ie. invalid transitions, retransmissions, etc.
this all without having access to full TCP connection.  Is it that you
need NAT and the stateless NAT in nftables does not fulfill your
requirements?

Conntrack already picks such a connection up when it misses the
handshake entirely, and patch 1 routes the SYN-seen case into that same
path, under the same nf_conntrack_tcp_loose gate.

  net/netfilter/nf_conntrack_proto_tcp.c, tcp_new():

    } else if (tn->tcp_loose == 0) {
        /* Don't try to pick up connections. */
        return false;
    } else {
        ...
        ct->proto.tcp.seen[0].flags =
        ct->proto.tcp.seen[1].flags = IP_CT_TCP_FLAG_SACK_PERM |
                                      IP_CT_TCP_FLAG_BE_LIBERAL;

Julius



Am Fr., 11. Sept. 2026 um 11:42 Uhr schrieb Pablo Neira Ayuso
[off-list ref]:

quoted

On Thu, Sep 10, 2026 at 11:00:48AM +0200, Julius Bairaktaris wrote:

quoted

A host that forwards one direction of a TCP connection only sees the
client's SYN and then an ACK continuing from it; the answer took another
path. That ACK has no entry in the transition table, so it and every
packet after it are invalid, the conntrack entry stays in SYN_SENT
[UNREPLIED] with a single packet, and the connection reaches neither the
stateful part of a ruleset nor a flowtable.

conntrack needs to see packets in both directions, are you assuming a
packet-based load balancer in front of it?

quoted

Patch 1 takes such a connection over as the mid-stream pickup it is.
Patch 2 withholds the reply direction of a flow offloaded in one
direction until conntrack has seen a reply, and offloads it once
conntrack has. Patch 3 offers a connection whose reply was never seen to
the flowtable in the original direction. Patch 4 adds a selftest arm for
the path; without patches 1 to 3 it fails, with the router forwarding the
SYN of the connection and nothing else.

Verified on an IPQ8074 router with hardware flow offload, iperf3 -P2
between two hosts on different subnets of one bridge with the reply
direction bypassing the router:

                                  CPU port    switch port   throughput
  asymmetric, without the series   81k pps       81k pps    944-947 Mbit/s
  asymmetric, with the series      2-11 pps      81k pps    948-949 Mbit/s
  symmetric, with the series      11-38 pps      81k pps    926-948 Mbit/s

I wrote this series with the help of an AI coding assistant, as the
Assisted-by tags record. I have reviewed and tested it myself.

Gary Dotzler (2):
  netfilter: conntrack: pick up a TCP flow whose SYN was never answered
  netfilter: nft_flow_offload: offload a TCP flow that has no reply

Julius Bairaktaris (2):
  netfilter: flowtable: promote a flow offloaded in one direction only
  selftests: netfilter: cover a TCP flow whose reply is never seen

 include/net/netfilter/nf_conntrack_l4proto.h  |  7 ++
 net/netfilter/nf_conntrack_proto_tcp.c        | 19 +++++
 net/netfilter/nf_flow_table_ip.c              | 26 +++++++
 net/netfilter/nft_flow_offload.c              |  6 +-
 .../selftests/net/netfilter/nft_flowtable.sh  | 73 +++++++++++++++++++
 5 files changed, 129 insertions(+), 2 deletions(-)

--
2.53.0