Date: Sat, 14 Dec 2019 17:56:15 -0500 From: "John W. O'Brien" <john@saltant.com> To: Eugene Grosbein <eugen@grosbein.net>, FreeBSD Networking <freebsd-net@freebsd.org> Subject: Re: NAT64 return traffic vanishes after successful de-alias Message-ID: <94b5ede7-3c64-9a4c-2622-9d2229f91cf7@saltant.com> In-Reply-To: <657dd43e-a555-9823-e8fd-a1ee0eb2b0e2@grosbein.net> References: <9f3ee846-1357-0b73-cc0f-e001ea74b15c@saltant.com> <657dd43e-a555-9823-e8fd-a1ee0eb2b0e2@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Oc6sic6MqT2FJ2nj0PtMx9KIWM5J2J0Sl
Content-Type: multipart/mixed; boundary="sCoZRI32UETOJrFcNDRMaCyXDbS0uIcXm"
--sCoZRI32UETOJrFcNDRMaCyXDbS0uIcXm
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 2019/12/14 17:36, Eugene Grosbein wrote:
> 15.12.2019 2:54, John W. O'Brien =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>> Hello FreeBSD Networking,
>>
>> As the subject summarizes, I have a mostly-working NAT64 rig, but retu=
rn
>> traffic is disappearing, and I haven't been able to figure out why. I
>> observe the post-translation (4-to-6) packets via ipfwlog0, but a simp=
le
>> ipfw counter rule ipfw matches nothing.
>=20
> Have you read NETWORK ADDRESS TRANSLATION (NAT) section of ipfw(8) manu=
al page carefully?
> It tells:
>=20
>> To let the packet continue after being (de)aliased, set the sysctl
>> variable net.inet.ip.fw.one_pass to 0.
>=20
> Did you set sysctl net.inet.ip.fw.one_pass=3D0 ?
>=20
Hi Eugene,
Yes, I am familiar with the one_pass flag. It is disabled. However, I
don't believe it applies to the nat64lsn module. The IPv6/IPv4 NETWORK
ADDRESS AND PROTOCOL TRANSLATION section, Stateful translation
subsection says:
> After translation NAT64 translator by default sends packets through
> corresponding netisr queue.
I find no mention of an interaction between nat64lsn and one_pass.
Furthermore, the outbound path (6-to-4) is working, and aliased packets
are successfully matching ipfw rules.
This is what the rule counters look like in the working case after
sending a single ping6 from the v6 jail to the v4 jail via the host that
performs NAT64:
root@freebsd:~ # ipfw show
00100 2 72 setfib 1 ip4 from 198.51.100.4/30 to any
00200 2 72 allow ip4 from 198.51.100.4/30 to any
00300 2 112 setfib 1 ip6 from 2001:db8:64:64::/96 to
2001:db8::/64,2001:db8:1000::/64
00400 2 112 allow ip6 from 2001:db8:64:64::/96 to
2001:db8::/64,2001:db8:1000::/64
00500 1 56 nat64lsn magic ip6 from 2001:db8::/64,2001:db8:1000::/64
to 2001:db8:64:64::/96 // Alias 6-to-4
00600 1 36 nat64lsn magic ip4 from any to 198.51.100.4/30 // De-alias
4-to-6
00700 71 7780 allow ip from any to any
65535 26 2752 deny ip from any to any
root@freebsd:~ # ipfw nat64lsn magic show
nat64lsn magic prefix4 198.51.100.4/30 prefix6 2001:db8:64:64::/96 log
The equivalent counters in the non-working case would be 0 for rules 300
and 400, but 100 and 200 would be non-zero.
--=20
John W. O'Brien
OpenPGP keys:
0x33C4D64B895DBF3B
--sCoZRI32UETOJrFcNDRMaCyXDbS0uIcXm--
--Oc6sic6MqT2FJ2nj0PtMx9KIWM5J2J0Sl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEKpEHkkRoSDiIJkQOWPtK56pP/m4FAl31aI8ACgkQWPtK56pP
/m4Uswf/Vj4nWdX4iAKO0mYhZSwE6X4VpcZsvJgZn+WivYJVXnH8EK+JgajGjC05
6bwi4R36yiCIX1cojIXU/lrZ2/F9C8l643hsZeONy5U5aJrqZYajQNZVjJe7QaNs
1IsHj0T/1a2OG48ZP0cSDZ6DcJ0TbnlfBjjUNAE0Zv3VSR0q56qIpYu6g06uZonv
GqytVzRbgnMw/nZZAlDe48kYTHtjYt7c2euKIH0sadRHW6/+//ObRAszZcIzfQE2
apHIqbwgClj0UCqH/WNZ8vRk6YY9HB/t7ILmrxjtGmfeS02+ujg8+HcdpbA2zjYa
gSzKv74fG/fL1en9FM3Ojo4BUbkEiw==
=5RP0
-----END PGP SIGNATURE-----
--Oc6sic6MqT2FJ2nj0PtMx9KIWM5J2J0Sl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?94b5ede7-3c64-9a4c-2622-9d2229f91cf7>