Re: [PATCH nftables 0/8] Support for shifted port-ranges in NAT

[Jeremy Sowden <jeremy@azazel.net>]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On 2023-03-24, at 15:18:56 +0100, Florian Westphal wrote:
> Jeremy Sowden wrote:
> > Support for shifted port-ranges was added to iptables for DNAT in
> > 2018.  This allows one to redirect packets intended for one port to
> > another in a range in such a way that the new port chosen has the
> > same offset in the range as the original port had from a specified
> > base value.
> > 
> > For example, by using the base value 2000, one could redirect
> > packets intended for 10.0.0.1:2000-3000 to 10.10.0.1:12000-13000 so
> > that the old and new ports were at the same offset in their
> > respective ranges, i.e.:
> >
> >   10.0.0.1:2345 -> 10.10.0.1:12345
> > 
> > This patch-set adds support for doing likewise to nftables.  In
> > contrast to iptables, this works for `snat`, `redirect` and
> > `masquerade` statements as well as well as `dnat`.
> 
> Could you rebase and resend the kernel patches now that the
> refactoring patches have been merged?
> 
> I'd like to have another look at it now that the fixes and refactoring
> ones are in.

Yup, no problem.

> Background: I wonder if going with NF_NAT_RANGE_PROTO_OFFSET is really
> a good idea or not, because it seems rather iptables-kludgy.
> 
> But if its not much work it might be simpler to jsut go along with it.
> An alternate approach would be to support addition in nft, so one
> could do:
> 
> dnat to tcp dport + 2000
> 
> ... to get such a 'shift effect'.
> 
> [ yes, the bison parser might not like this syntax, I made it up for
> illustrative purposes. ]
> 
> Something like this would also allow to emulate TTL/HL target of
> iptables, ATM we can set a fixed value but cannot add or decrement
> them.

J.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]