mbox series

[nf-next,00/13] Support for shifted port-ranges in NAT

Message ID 20230305121817.2234734-1-jeremy@azazel.net
Headers show
Series Support for shifted port-ranges in NAT | expand

Message

Jeremy Sowden March 5, 2023, 12:18 p.m. UTC
Commit 2eb0f624b709 ("netfilter: add NAT support for shifted portmap
ranges") introduced support for shifting port-ranges in DNAT.  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

However, while support for this was added to the common DNAT infra-
structure, only the xt_nat module was updated to make use of it.  This
patch-set extends the core support and updates all the nft NAT modules
to support it too.

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

* Patches 1 & 2 contain small tidy-ups.
* Patch 3 extends the core NAT support for shifted port-ranges to SNAT.
* Patches 4 & 5 correct the size in a `nft_parse_register_load` call and
  add shifted port-range support to nft_nat.
* Patches 6-8 correct the size in a `nft_parse_register_load` call and
  add shifted port-range support to nft_masq.
* Patch 9 corrects a C&P mistake in an nft_redir `nft_expr_type`
  definition.
* Patch 10-13 correct the size in a `nft_parse_register_load` call and
  add shifted port-range support to nft_redir.

Jeremy Sowden (13):
  netfilter: conntrack: fix typo
  netfilter: nat: fix indentation of function arguments
  netfilter: nat: extend core support for shifted port-ranges
  netfilter: nft_nat: correct length for loading protocol registers
  netfilter: nft_nat: add support for shifted port-ranges
  netfilter: nft_masq: correct length for loading protocol registers
  netfilter: nft_masq: deduplicate eval call-backs
  netfilter: nft_masq: add support for shifted port-ranges
  netfilter: nft_redir: correct value of inet type `.maxattrs`
  netfilter: nf_nat_redirect: use `struct nf_nat_range2` in ipv4 API
  netfilter: nft_redir: correct length for loading protocol registers
  netfilter: nft_redir: deduplicate eval call-backs
  netfilter: nft_redir: add support for shifted port-ranges

 include/net/netfilter/nf_nat_redirect.h  |   3 +-
 include/uapi/linux/netfilter/nf_tables.h |   6 ++
 net/netfilter/nf_conntrack_core.c        |   2 +-
 net/netfilter/nf_nat_core.c              |   7 +-
 net/netfilter/nf_nat_masquerade.c        |   2 +
 net/netfilter/nf_nat_redirect.c          |  59 ++++++-------
 net/netfilter/nft_masq.c                 |  97 ++++++++++-----------
 net/netfilter/nft_nat.c                  |  38 ++++++---
 net/netfilter/nft_redir.c                | 104 +++++++++++------------
 net/netfilter/xt_REDIRECT.c              |  10 ++-
 10 files changed, 177 insertions(+), 151 deletions(-)

Comments

Florian Westphal March 7, 2023, 12:46 p.m. UTC | #1
Jeremy Sowden <jeremy@azazel.net> wrote:
> Jeremy Sowden (13):
>   netfilter: nft_nat: correct length for loading protocol registers
>   netfilter: nft_masq: correct length for loading protocol registers
>   netfilter: nft_redir: correct value of inet type `.maxattrs`
>   netfilter: nft_redir: correct length for loading protocol registers

I think the fixess above should be routed through the 'nf' tree, I
don't see why we need to hold them in -next trees for another 3 months.
Jeremy Sowden March 7, 2023, 7:35 p.m. UTC | #2
On 2023-03-07, at 13:46:38 +0100, Florian Westphal wrote:
> Jeremy Sowden wrote:
> > Jeremy Sowden (13):
> >   netfilter: nft_nat: correct length for loading protocol registers
> >   netfilter: nft_masq: correct length for loading protocol registers
> >   netfilter: nft_redir: correct value of inet type `.maxattrs`
> >   netfilter: nft_redir: correct length for loading protocol
> >   registers
> 
> I think the fixess above should be routed through the 'nf' tree, I
> don't see why we need to hold them in -next trees for another 3
> months.

When I send v2, I'll separate these out.

J.