All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>,
	Jeremy Sowden <jeremy@azazel.net>,
	Netfilter Devel <netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges
Date: Tue, 11 Apr 2023 12:25:32 +0200	[thread overview]
Message-ID: <20230411102532.GC21051@breakpoint.cc> (raw)
In-Reply-To: <ZDUaIa0N2R1Ay7o/@calendula>

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Fri, Mar 24, 2023 at 11:59:04PM +0100, Florian Westphal wrote:
> > Jeremy Sowden <jeremy@azazel.net> wrote:
> > > +ip daddr 10.0.0.1 tcp dport 55900-55910 dnat ip to 192.168.127.1:5900-5910/55900;ok
> > > +ip6 daddr 10::1 tcp dport 55900-55910 dnat ip6 to [::c0:a8:7f:1]:5900-5910/55900;ok
> > 
> > This syntax is horrible (yes, I know, xtables fault).
> > 
> > Do you think this series could be changed to grab the offset register from the
> > left edge of the range rather than requiring the user to specify it a
> > second time?  Something like:
> > 
> > ip daddr 10.0.0.1 tcp dport 55900-55910 dnat ip to 192.168.127.1:5900-5910
> > 
> > I'm open to other suggestions of course.
> 
> To allow to mix this with maps, I think the best approach is to add a
> new flag (port-shift) and then allow the user to specify the
> port-shift 'delta'.
> 
> ip daddr 10.0.0.1 tcp dport 55900-55910 dnat ip to ip saddr map { \
>         192.168.127.0-129.168.127.128 : 1.2.3.4 . -55000 } port-shift

Sorry, I don't see the usecase for different deltas.
But even if we assume that, kernel already takes the dnat target port
number from a register.

> where -55000 means, subtract -55000 to the tcp dport in the packet, it
> is an incremental update.
> 
> This requires a kernel patch to add the new port-shift flag.

... so I don't see why we need a new port-shift flag at all.
I think best approach is to provide the actual new dport in a register,
like we already do right now.

So we need an 'add' operation in kernel to compute

portreg = sreg_with_port + sreg_with_offset
> 
> Florian, this is based on your idea to support 'add' command, which is
> still needed for other usecases. I think nat is special in the sense
> that the goal is to feed the registers that instruct the NAT engine
> what kind of mangling is needed.

See above.  I don't think we should go with the existing NAT flag,
its very much a hack to overcome iptables design limitations.

  reply	other threads:[~2023-04-11 10:25 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-05 10:14 [PATCH nftables 0/8] Support for shifted port-ranges in NAT Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 1/8] nat: add support for shifted port-ranges Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 2/8] masq: " Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 3/8] redir: " Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 4/8] json: formatting fixes Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 5/8] json: add support for shifted nat port-ranges Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 6/8] doc: correct NAT statement description Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 7/8] doc: add shifted port-ranges to nat statements Jeremy Sowden
2023-03-05 10:14 ` [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges Jeremy Sowden
2023-03-24 22:59   ` Florian Westphal
2023-03-25 10:35     ` Phil Sutter
2023-03-25 11:10       ` Jeremy Sowden
2023-03-26 20:41         ` Pablo Neira Ayuso
2023-03-26 20:39     ` Pablo Neira Ayuso
2023-03-27 11:08       ` Jeremy Sowden
2023-04-11 12:21       ` Jeremy Sowden
2023-04-12 11:06         ` Pablo Neira Ayuso
2023-04-25 19:51           ` Jeremy Sowden
2023-05-03 20:54             ` Pablo Neira Ayuso
2023-05-08 17:58               ` Jeremy Sowden
2023-05-08 19:47                 ` Pablo Neira Ayuso
2023-04-11  8:28     ` Pablo Neira Ayuso
2023-04-11 10:25       ` Florian Westphal [this message]
2023-04-11 10:53         ` Pablo Neira Ayuso
2023-04-11 11:20           ` Florian Westphal
2023-04-11 11:43             ` Pablo Neira Ayuso
2023-04-11 12:28               ` Florian Westphal
2023-04-11 12:36       ` Florian Westphal
2023-04-12 11:22         ` Pablo Neira Ayuso
2023-04-12 11:43           ` Florian Westphal
2023-04-12 12:54             ` Pablo Neira Ayuso
2023-03-24 14:18 ` [PATCH nftables 0/8] Support for shifted port-ranges in NAT Florian Westphal
2023-03-24 16:07   ` Jeremy Sowden

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=20230411102532.GC21051@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=jeremy@azazel.net \
    --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 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.