Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Jon Masters <jcm@jonmasters.org>
Mime-Version: 1.0 (1.0)
Subject: Re: nf_nat not running in a netns
Date:   Sun, 5 Jan 2020 13:58:38 -0500
Message-Id: <8D4A3CF6-E12A-4AC5-A8CC-E2D80DB83F65@jonmasters.org>
References: <29555895-6D59-4415-B44C-5AD90C14C63F@jonmasters.org>
In-Reply-To: <29555895-6D59-4415-B44C-5AD90C14C63F@jonmasters.org>
To:     linux-kernel@vger.kernel.org
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Ignore. The below was exactly the problem.

It was broken. netns nat rules in CentOS7.7 kernel were exactly not working d=
ue to a bug. Sigh.

--=20
Computer Architect


> On Jan 4, 2020, at 10:51, Jon Masters <jcm@jonmasters.org> wrote:
>=20
> =EF=BB=BFHi there,
>=20
> Can anyone offer any reasons why the nat table chains for a netns wouldn=E2=
=80=99t be running?
>=20
> Longer detail:
>=20
> I=E2=80=99ve be playing with Kolla (containerized OpenStack) and the way t=
hey implement (virtual) routers for tenant networks is to create network nam=
espaces with interfaces representing the ports plugged into the router. To t=
ranslate addresses from internal to external networks, they apply D/SNAT rul=
es within that netns. All of these are created and the interfaces are pingab=
le, but the nat rules aren=E2=80=99t being run and the untranslated addresse=
s are ultimately seen on the physical network once packets traverse out of t=
he containers and to the external neutron interface.
>=20
> Jon.
>=20
> --=20
> Computer Architect
>=20