From: Florian Westphal <fw@strlen.de>
To: netfilter-devel <netfilter-devel@vger.kernel.org>
Cc: pablo@netfilter.org, kadlec@netfilter.org, hmmsjan@kpnplanet.nl
Subject: TCP connection fails in a asymmetric routing situation
Date: Fri, 25 Feb 2022 13:30:30 +0100 [thread overview]
Message-ID: <20220225123030.GK28705@breakpoint.cc> (raw)
https://bugzilla.redhat.com/show_bug.cgi?id=2051413
Gist is:
as of 878aed8db324bec64f3c3f956e64d5ae7375a5de
(" netfilter: nat: force port remap to prevent shadowing well-known
port"), tcp connections won't get established with asymmetric routing
setups.
Workaround: Block conntrack for LAN-LAN2 traffic by
iptables -t raw -A PREROUTING -j CT --notrack
Or: echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
I'd guess that is because conntrack picks up the flow on syn-ack rather
than syn, snat check then thinks that source port is < 16384 and dest
port is large, so we do port rewrite but we do it on syn-ack and
connection cannot complete because client and server have different
views of the source ports involved.
Question is on how this can be prevented. I see a few solutions:
1. Change ct->local_origin to "ct->no_srcremap" (or a new status bit)
that indicates that this should not have src remap done, just like we
do for locally generated connections.
2. Add a new "mid-stream" status bit, then bypass the entire -t nat
logic if its set. nf_nat_core would create a null binding for the
flow, this also bypasses the "src remap" code.
3. Simpler version: from tcp conntrack, set the nat-done status bits
if its a mid-stream pickup.
Downside: nat engine (as-is) won't create a null binding, so connection
will not be known to nat engine for masquerade source port clash
detection.
I would go for 2) unless you have a better suggestion/idea.
Thanks!
next reply other threads:[~2022-02-25 12:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 12:30 Florian Westphal [this message]
2022-03-02 10:59 ` TCP connection fails in a asymmetric routing situation Florian Westphal
2022-03-08 10:22 ` H.Janssen
2022-03-02 11:32 ` Pablo Neira Ayuso
2022-03-02 13:30 ` Florian Westphal
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=20220225123030.GK28705@breakpoint.cc \
--to=fw@strlen.de \
--cc=hmmsjan@kpnplanet.nl \
--cc=kadlec@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).