[nftables,0/8] Support for shifted port-ranges in NAT

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`.

Patches 1-3 add support for shifted ranges to the NAT statements.
Patches 4-5 add JSON support for shifted ranges.
Patches 6-7 update the NAT documentation to cover shifted ranges.
Patch 8 adds some Python test-cases for shifted ranges.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970672
Link: https://bugzilla.netfilter.org/show_bug.cgi?id=1501

libnftnl & kernel patch-sets to follow.

Jeremy Sowden (8):
  nat: add support for shifted port-ranges
  masq: add support for shifted port-ranges
  redir: add support for shifted port-ranges
  json: formatting fixes
  json: add support for shifted nat port-ranges
  doc: correct NAT statement description
  doc: add shifted port-ranges to nat statements
  test: py: add tests for shifted nat port-ranges

 doc/statements.txt                    | 11 +++-
 include/statement.h                   |  1 +
 src/evaluate.c                        | 10 +++
 src/json.c                            |  4 ++
 src/netlink_delinearize.c             | 48 +++++++++++++-
 src/netlink_linearize.c               | 29 ++++++---
 src/parser_bison.y                    | 55 +++++++++++++++-
 src/parser_json.c                     | 49 ++++++++-------
 src/statement.c                       |  4 ++
 tests/py/inet/dnat.t                  |  3 +
 tests/py/inet/dnat.t.json             | 91 +++++++++++++++++++++++++++
 tests/py/inet/dnat.t.payload          | 33 ++++++++++
 tests/py/inet/snat.t                  |  3 +
 tests/py/inet/snat.t.json             | 91 +++++++++++++++++++++++++++
 tests/py/inet/snat.t.payload          | 34 ++++++++++
 tests/py/ip/masquerade.t              |  1 +
 tests/py/ip/masquerade.t.json         | 26 ++++++++
 tests/py/ip/masquerade.t.payload      |  8 +++
 tests/py/ip/redirect.t                |  1 +
 tests/py/ip/redirect.t.json           | 26 ++++++++
 tests/py/ip/redirect.t.payload        |  8 +++
 tests/py/ip6/masquerade.t             |  1 +
 tests/py/ip6/masquerade.t.json        | 25 ++++++++
 tests/py/ip6/masquerade.t.payload.ip6 |  8 +++
 tests/py/ip6/redirect.t               |  1 +
 tests/py/ip6/redirect.t.json          | 26 ++++++++
 tests/py/ip6/redirect.t.payload.ip6   |  8 +++
 27 files changed, 569 insertions(+), 36 deletions(-)

Jeremy Sowden <jeremy@azazel.net> 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.

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.

Thanks.

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.