All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Cole Dishington <Cole.Dishington@alliedtelesis.co.nz>
Cc: pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de,
	davem@davemloft.net, kuba@kernel.org, shuah@kernel.org,
	linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	coreteam@netfilter.org, netdev@vger.kernel.org,
	linux-kselftest@vger.kernel.org,
	Anthony Lineham <anthony.lineham@alliedtelesis.co.nz>,
	Scott Parlane <scott.parlane@alliedtelesis.co.nz>,
	Blair Steven <blair.steven@alliedtelesis.co.nz>
Subject: Re: [PATCH] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED
Date: Wed, 28 Jul 2021 11:06:35 +0200	[thread overview]
Message-ID: <20210728090635.GB15121@breakpoint.cc> (raw)
In-Reply-To: <20210728032134.21983-1-Cole.Dishington@alliedtelesis.co.nz>

Cole Dishington <Cole.Dishington@alliedtelesis.co.nz> wrote:
> FTP port selection ignores specified port ranges (with iptables
> masquerade --to-ports) when creating an expectation, based on
> FTP commands PORT or PASV, for the data connection.
> 
> Co-developed-by: Anthony Lineham <anthony.lineham@alliedtelesis.co.nz>
> Signed-off-by: Anthony Lineham <anthony.lineham@alliedtelesis.co.nz>
> Co-developed-by: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
> Signed-off-by: Scott Parlane <scott.parlane@alliedtelesis.co.nz>
> Co-developed-by: Blair Steven <blair.steven@alliedtelesis.co.nz>
> Signed-off-by: Blair Steven <blair.steven@alliedtelesis.co.nz>
> Signed-off-by: Cole Dishington <Cole.Dishington@alliedtelesis.co.nz>
> ---
> 
> Notes:
>     Currently with iptables -t nat -j MASQUERADE -p tcp --to-ports 10000-10005,
>     creating a passive ftp connection from a client will result in the control
>     connection being within the specified port range but the data connection being
>     outside of the range. This patch fixes this behaviour to have both connections
>     be in the specified range.
> 
>  include/net/netfilter/nf_conntrack.h |  3 +++
>  net/netfilter/nf_nat_core.c          | 10 ++++++----
>  net/netfilter/nf_nat_ftp.c           | 26 ++++++++++++--------------
>  net/netfilter/nf_nat_helper.c        | 12 ++++++++----
>  4 files changed, 29 insertions(+), 22 deletions(-)
> 
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index cc663c68ddc4..b98d5d04c7ab 100644
> --- a/include/net/netfilter/nf_conntrack.h
> +++ b/include/net/netfilter/nf_conntrack.h
> @@ -24,6 +24,8 @@
>  
>  #include <net/netfilter/nf_conntrack_tuple.h>
>  
> +#include <uapi/linux/netfilter/nf_nat.h>
> +
>  struct nf_ct_udp {
>  	unsigned long	stream_ts;
>  };
> @@ -99,6 +101,7 @@ struct nf_conn {
>  
>  #if IS_ENABLED(CONFIG_NF_NAT)
>  	struct hlist_node	nat_bysource;
> +	struct nf_nat_range2 range;
>  #endif

Thats almost a 20% size increase of this structure.

Could you try to rework it based on this?
diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -27,12 +27,18 @@ union nf_conntrack_nat_help {
 #endif
 };
 
+struct nf_conn_nat_range_info {
+	union nf_conntrack_man_proto	min_proto;
+	union nf_conntrack_man_proto	max_proto;
+};
+
 /* The structure embedded in the conntrack structure. */
 struct nf_conn_nat {
 	union nf_conntrack_nat_help help;
 #if IS_ENABLED(CONFIG_NF_NAT_MASQUERADE)
 	int masq_index;
 #endif
+	struct nf_conn_nat_range_info range_info;
 };
 
 /* Set up the info structure to map into this range. */

... and then store the range min/max proto iff nf_nat_setup_info had
NF_NAT_RANGE_PROTO_SPECIFIED flag set.

I don't think there is a need to keep the information in nf_conn.


  parent reply	other threads:[~2021-07-28  9:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28  3:21 [PATCH] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED Cole Dishington
2021-07-28  5:23 ` kernel test robot
2021-07-28  5:23   ` kernel test robot
2021-07-28  9:06 ` Florian Westphal [this message]
2021-07-28 10:30 ` kernel test robot
2021-07-28 10:30   ` kernel test robot
2021-07-28 11:09 ` kernel test robot
2021-07-28 11:09   ` kernel test robot

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=20210728090635.GB15121@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=Cole.Dishington@alliedtelesis.co.nz \
    --cc=anthony.lineham@alliedtelesis.co.nz \
    --cc=blair.steven@alliedtelesis.co.nz \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=kadlec@netfilter.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=scott.parlane@alliedtelesis.co.nz \
    --cc=shuah@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 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.