Received-SPF: pass (google.com: domain of linux-kernel+bounces-12767-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20231223211306.GA215659@kernel.org> <20231224024725.80516-1-brad@faucet.nz>
In-Reply-To: <20231224024725.80516-1-brad@faucet.nz>
From: Xin Long <lucien.xin@gmail.com>
Date: Thu, 28 Dec 2023 10:59:21 -0500
Message-ID: <CADvbK_dpD+rTPr4acbvmHu91OHtgynzJ4Ru3+d+rw7njmOPeww@mail.gmail.com>
Subject: Re: [PATCH net] netfilter: nf_nat: fix action not being set for all
 ct states
To: Brad Cowie <brad@faucet.nz>
Cc: horms@kernel.org, aconole@redhat.com, coreteam@netfilter.org, 
	davem@davemloft.net, dev@openvswitch.org, edumazet@google.com, fw@strlen.de, 
	kadlec@netfilter.org, kuba@kernel.org, linux-kernel@vger.kernel.org, 
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, pabeni@redhat.com, 
	pablo@netfilter.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 23, 2023 at 9:48=E2=80=AFPM Brad Cowie <brad@faucet.nz> wrote:
>
> On Sun, 24 Dec 2023 at 10:13, Simon Horman <horms@kernel.org> wrote:
> > Thanks Brad,
> >
> > I agree with your analysis and that the problem appears to
> > have been introduced by the cited commit.
>
> Thanks for the review Simon.
>
> > I am curious to know what use case triggers this /
> > why it when unnoticed for a year.
>
> We encountered this issue while upgrading some routers from
> linux 5.15 to 6.2. The dataplane on these routers is provided
> by an openvswitch bridge which is controlled via openflow by
> faucet. These routers are also performing SNAT on all traffic
> to/from the wan interface via openvswitch conntrack openflow
> rules.
>
> We noticed that after upgrading the linux kernel, traceroute/mtr
> no longer worked when run from clients behind the router.
> We eventually discovered the reason for this is that the
> ICMP time exceeded messages elicited by traceroute were
> matching openflow rules with the incorrect destination ip,
> despite there being an openflow rule to undo the nat.
> Other packets in the established or new state matched the
> expected openflow rules.
>
> A git bisect between 5.15 and 6.2 showed that this change in
> behaviour was introduced by commit ebddb1404900. After the
> above patch is applied our routers perform nat correctly
> again for traceroute/mtr.

Acked-by: Xin Long <lucien.xin@gmail.com>