netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kyle Swenson <kyle.swenson@est.tech>
To: "netfilter-devel@vger.kernel.org" <netfilter-devel@vger.kernel.org>
Cc: Kyle Swenson <kyle.swenson@est.tech>, "fw@strlen.de" <fw@strlen.de>
Subject: [RFC PATCH v2 0/1]  netfilter: nat: restore default DNAT behavior
Date: Mon, 29 Jan 2024 21:12:52 +0000	[thread overview]
Message-ID: <20240129211227.815253-1-kyle.swenson@est.tech> (raw)

Hello,

We have noticed what appears to be a regression from v4.4 in the DNAT port
selection logic in nf_nat_core.c.  Specifically, we're expecting an iptables
command like

    iptables -t nat -A PREROUTING -p tcp -d 10.0.0.2 -m tcp --dport 32000:32010
    -j DNAT --to-destination 192.168.0.10:21000-21010

to DNAT traffic sent to 10.0.0.2:32000-32010 to 192.168.0.10:21000-21010.  We
use the range on the LAN side to handle tuple collisions that might occur with
a single port specified via --to-destination.

The behavior we're seeing currently, however, is the behavior we'd expect if we
were passing --random to iptables (except without passing --random): the DNAT'd
port is random within the range.

Through my naive debugging, I've arrived at this RFC patch and have included it
mostly to illustrate the behavior our userspace is expecting with the above
iptables command.  The hope is that I can be educated with what other
folks expect the behavior to be, or what I can change in our iptables
command to get the behavior we're expecting.

Thanks so much for your time,
Kyle

--
v1 -> v2:
- Restrict to NF_NAT_MANIP_DST so that we don't have predictable source
  port conflict resolution, without changing the --range and --random
  override behavior.

             reply	other threads:[~2024-01-29 21:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29 21:12 Kyle Swenson [this message]
2024-01-29 21:12 ` [RFC PATCH v2 1/1] netfilter: nat: restore default DNAT behavior Kyle Swenson
2024-02-07 22:29   ` Pablo Neira Ayuso

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=20240129211227.815253-1-kyle.swenson@est.tech \
    --to=kyle.swenson@est.tech \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.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 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).