Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5064096pxv; Wed, 28 Jul 2021 02:07:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy7PUmE5UsIy6sasaRopdKKcIJ8M+IiCbNv+o3YPQc/97TGrGjQLAbbGOxqc1X8VpCPAL/w X-Received: by 2002:a02:7a50:: with SMTP id z16mr24714978jad.139.1627463265982; Wed, 28 Jul 2021 02:07:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627463265; cv=none; d=google.com; s=arc-20160816; b=HR6ZG7aFsWsK720ng0j87XLjFSfE7E+0gZ9o8AY0lTGte3+uWk3y7giEAOByb26CLS 3Erwj9NhZMgW/sKZaUzIlVvxPHq9cDQt9RSHxhhrQw+TRkoO9Ghrk3UhaZxWwOd5jCtv wVUpRtMBkcEViuy+lx2qxSqLxeKSaPV7XsK95dFPrm0cE6Cf926MBNYpQXoxEjUIjnYW Fkw+E6hyVan2TyXJXVhoEZ8+mR1neqnMx9AorKzISFSN5ZaiS3epLsPmLbTOw4kMlpr4 T7benAtBEpzUaZL5s5JLamZIFFneLtNRwUhI9emF8Ejmc0z5koMQIm4vImQs4TrQOw0k 95HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=oYOowVg/U1J4vwgyRLVkXWTovhQ/c8GwtnPdxjJUARI=; b=ELrN2IgykAkf2sjunGxttmKROuBNko5/Ygo/i2OUEvpKiysrUpiE3fHH4zgQL4xvqj e2qsfzRo6lQsAIWzw1UIjQlwhw76goqdpDXu3CFDP0n0oEWjGTIJUSnpzlYVx80Ka4Vb eKyB4NJIohFmh8SkmRJuCn/mPDOWwjazgzEJosaWoyPxKP+04QPNVrtghIbVYI170qcd Ly+YhjO3/We/FxnnjSTv/kmqXcCKl1ruYO4XuHeqtXCwSjfwppLVHf26wwvP2jFBXGmL +iV4ivhY5wzThu85cAb1HZ2vVygWNdFh9hhYXLBWD5QnKH4lQqBjNzj09KdSBW2dWR4p HkRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x19si5858156ioa.74.2021.07.28.02.07.34; Wed, 28 Jul 2021 02:07:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232229AbhG1JGr convert rfc822-to-8bit (ORCPT + 99 others); Wed, 28 Jul 2021 05:06:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230520AbhG1JGq (ORCPT ); Wed, 28 Jul 2021 05:06:46 -0400 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2a0a:51c0:0:12e:520::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C9F7C061757; Wed, 28 Jul 2021 02:06:45 -0700 (PDT) Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1m8fWN-00060Q-S5; Wed, 28 Jul 2021 11:06:35 +0200 Date: Wed, 28 Jul 2021 11:06:35 +0200 From: Florian Westphal To: Cole Dishington 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 , Scott Parlane , Blair Steven Subject: Re: [PATCH] net: netfilter: Fix port selection of FTP for NF_NAT_RANGE_PROTO_SPECIFIED Message-ID: <20210728090635.GB15121@breakpoint.cc> References: <20210728032134.21983-1-Cole.Dishington@alliedtelesis.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20210728032134.21983-1-Cole.Dishington@alliedtelesis.co.nz> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cole Dishington 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 > Signed-off-by: Anthony Lineham > Co-developed-by: Scott Parlane > Signed-off-by: Scott Parlane > Co-developed-by: Blair Steven > Signed-off-by: Blair Steven > Signed-off-by: Cole Dishington > --- > > 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 > > +#include > + > 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.