vrf: T6097: add the nat anchor conntrack zoning needs

VRF conntrack zoning assigns a zone to the original direction only, which
leaves every reply tuple in the default zone 0. That is deliberate and is
required by T3655: the reply of a flow that was leaked out of a VRF and
NATed in the default VRF arrives on an interface carrying no zone at all,
so it can only be matched when the reply tuple lives in zone 0 as well.

The side effect is that two flows differing only by their VRF end up with
identical reply tuples. The second conntrack entry can then not be
inserted and its packet is dropped, visible as insert_failed and drop in
"conntrack -S".

The kernel already resolves this, but only once nf_nat is registered for
the address family: a null binding is applied to every new conntrack entry
and get_unique_tuple() reallocates the clashing reply tuple. nf_nat is
registered as soon as any "type nat" chain exists in that family.

IPv4 always had one, because the startup ruleset created "table ip nat"
unconditionally. IPv6 never had an equivalent, so IPv6 was dropped while
IPv4 kept working by accident. That is the asymmetry reported here.

Create the chain from the VRF code instead, in the inet family so one
table covers both, and only while conntrack zoning is installed. A
registered nf_nat costs about 200ns per new connection, measured at +19%
for IPv4 and +11% for IPv6 in a connection setup benchmark, and is not
worth paying on systems without a VRF.

0 files changed, 0 insertions, 0 deletions