Date: Wed, 26 Jun 2019 14:37:31 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: FreeBSD Net <freebsd-net@freebsd.org>, mops@punkt.de Subject: Re: IPFW NAT64 changed 11.2 --> 11.3? Message-ID: <e94512b4-53dc-8ba4-9ced-44926e0faa12@yandex.ru> In-Reply-To: <C8B5D541-C064-49FC-9E3E-27993721D1D3@punkt.de> References: <950200A8-6D36-46FE-B0DD-BA6EA860FEB7@punkt.de> <71dacccb-2500-6d7e-c890-2733d15fbbe5@yandex.ru> <F475ACC5-71CD-4C62-9E63-3F206A305F34@punkt.de> <76d0fb6a-28cb-4411-acb0-12f9ebe9b1f0@yandex.ru> <A15270D2-08F6-49F9-8201-E2935381F122@punkt.de> <C8B5D541-C064-49FC-9E3E-27993721D1D3@punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WaJFywOu52W1U9slzGfi1X6QLNHPs8caQ Content-Type: multipart/mixed; boundary="tzwY8DevO6yu3054FciXlqXCr6cFeMuKH"; protected-headers="v1" From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: FreeBSD Net <freebsd-net@freebsd.org>, mops@punkt.de Message-ID: <e94512b4-53dc-8ba4-9ced-44926e0faa12@yandex.ru> Subject: Re: IPFW NAT64 changed 11.2 --> 11.3? References: <950200A8-6D36-46FE-B0DD-BA6EA860FEB7@punkt.de> <71dacccb-2500-6d7e-c890-2733d15fbbe5@yandex.ru> <F475ACC5-71CD-4C62-9E63-3F206A305F34@punkt.de> <76d0fb6a-28cb-4411-acb0-12f9ebe9b1f0@yandex.ru> <A15270D2-08F6-49F9-8201-E2935381F122@punkt.de> <C8B5D541-C064-49FC-9E3E-27993721D1D3@punkt.de> In-Reply-To: <C8B5D541-C064-49FC-9E3E-27993721D1D3@punkt.de> --tzwY8DevO6yu3054FciXlqXCr6cFeMuKH Content-Type: multipart/mixed; boundary="------------2C56725B5F65E7D7742E15AF" Content-Language: en-US This is a multi-part message in MIME format. --------------2C56725B5F65E7D7742E15AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 26.06.2019 14:23, Patrick M. Hausen wrote: > Hi all, >=20 >> Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov <bu7cher@yandex.ru>: >> >> On 26.06.2019 13:10, Patrick M. Hausen wrote: >>> tcpdump will take some more time, currently we do not have /dev/bpf i= n these jails. >> >> So, nat64_direct_output didn't help? >> Does `ipfw nat64lsn NAT64 list states` shows correct addresses? >=20 > No, it didn=E2=80=99t. Yes, the IPv4 addresses shown are the external a= ddresses > of these =E2=80=9Egate64=E2=80=9C jails. >=20 > See: >=20 > 13:06:28.205602 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1= 6) 2a00:b580:8000:12:40f9:d4:cd11:d68c > 64:ff9b::9765:7085: [icmp6 sum o= k] ICMP6, echo request, seq 0 > 13:06:28.205611 IP (tos 0x0, ttl 63, id 25804, offset 0, flags [DF], pr= oto ICMP (1), length 36) > 217.29.40.145 > 151.101.112.133: ICMP echo request, id 1024, seq 0,= length 16 > 13:06:28.207853 IP (tos 0x0, ttl 58, id 53557, offset 0, flags [none], = proto ICMP (1), length 36) > 151.101.112.133 > 217.29.40.145: ICMP echo reply, id 1024, seq 0, l= ength 16 > 13:06:28.207861 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 1= 6) d91d:2891::9765:7085 > 2a00:b580:8000:12:40f9:d4:cd11:d68c: [icmp6 sum= ok] ICMP6, echo reply, seq 0 > 13:06:29.268095 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1= 6) 2a00:b580:8000:12:40f9:d4:cd11:d68c > 64:ff9b::9765:7085: [icmp6 sum o= k] ICMP6, echo request, seq 1 > 13:06:29.268106 IP (tos 0x0, ttl 63, id 18866, offset 0, flags [DF], pr= oto ICMP (1), length 36) > 217.29.40.145 > 151.101.112.133: ICMP echo request, id 1024, seq 1,= length 16 > 13:06:29.270335 IP (tos 0x0, ttl 58, id 53653, offset 0, flags [none], = proto ICMP (1), length 36) > 151.101.112.133 > 217.29.40.145: ICMP echo reply, id 1024, seq 1, l= ength 16 > 13:06:29.270340 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 1= 6) d91d:2891::9765:7085 > 2a00:b580:8000:12:40f9:d4:cd11:d68c: [icmp6 sum= ok] ICMP6, echo reply, seq 1 >=20 > So the IPv4 echo and reply exchange looks good. Then the packet is > forwarded to IPv6 with an entirely bogus (AFAIK) IPv6 source address. >=20 > Interestingly the host portion of the address that should be nat64 is i= dentical, > but the prefix - where does it get that idea? Thanks, it is very useful. Due to the code difference between head/ and stable/11 there were some partial MFCs, and r334836 seems has missing part of code. Can you try this patch? --=20 WBR, Andrey V. Elsukov --------------2C56725B5F65E7D7742E15AF Content-Type: text/x-patch; name="nat64.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="nat64.diff" Index: sys/netpfil/ipfw/nat64/nat64lsn.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/netpfil/ipfw/nat64/nat64lsn.c (revision 349408) +++ sys/netpfil/ipfw/nat64/nat64lsn.c (working copy) @@ -408,6 +408,7 @@ nat64lsn_translate4(struct nat64lsn_cfg *cfg, cons } else logdata =3D NULL; =20 + src6 =3D cfg->base.plat_prefix; nat64_embed_ip4(&src6, cfg->base.plat_plen, htonl(f_id->src_ip)); ret =3D nat64_do_handle_ip4(*pm, &src6, &nh->addr, lport, &cfg->base, logdata); --------------2C56725B5F65E7D7742E15AF-- --tzwY8DevO6yu3054FciXlqXCr6cFeMuKH-- --WaJFywOu52W1U9slzGfi1X6QLNHPs8caQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl0TWPsACgkQAcXqBBDI oXpOHQgAg8rTmZOMHGCPXjES6KKw52sYoNmyvVayOWNN6wepGly9MjKUzAVZzuq0 qjBE2/mDs3HT8mF4tny33FeNnD6wmKFkWwxPFGxRIwC37X/j+PzXfTnwnBtHt93L wKCKOBtrrXr1POTT5+cPGgNtu0Etd9cgPpi2uMis2GTRmjeHAs+ysIISmbfxF47A uJgGkG36GIdsA1ppJXrN5hv+w6t0TDcv8l0w6i0/mpwWbIm16qSubAEeLmtmmf+G oZ0jx1EigHNzxJvseHmJG8RrDYwOqzYSF1ExUuDHitShouAogUgF8mbzL3xDdS2+ xqCjTsUF7rXju0IzX6rGt/tZ+3B5HA== =nTpI -----END PGP SIGNATURE----- --WaJFywOu52W1U9slzGfi1X6QLNHPs8caQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e94512b4-53dc-8ba4-9ced-44926e0faa12>