Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Dec 2019 11:15:30 -0500
From:      "John W. O'Brien" <john@saltant.com>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>, FreeBSD Networking <freebsd-net@freebsd.org>
Subject:   Re: NAT64 return traffic vanishes after successful de-alias
Message-ID:  <15ce6744-91f1-e755-22c7-0c5355686d90@saltant.com>
In-Reply-To: <52463470-973e-aa5f-73f5-dd9ba39edf79@yandex.ru>
References:  <9f3ee846-1357-0b73-cc0f-e001ea74b15c@saltant.com> <52463470-973e-aa5f-73f5-dd9ba39edf79@yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IglUFb5dkvL3RpZtKTPLgvLWWSoUEBUfL
Content-Type: multipart/mixed; boundary="OsYedDgdivxpdAXCHQbXQlDunjkTOjnBk"

--OsYedDgdivxpdAXCHQbXQlDunjkTOjnBk
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2019/12/15 05:44, Andrey V. Elsukov wrote:
> On 14.12.2019 22:54, John W. O'Brien wrote:
>> 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
> I suspect you have disabled IPv6 on the interface, where IPv4 address i=
s
> configured. Check that IFDISABLED flag is not set on the IPv4 side
> interface.
>=20
> When NAT64 does translation, by default it reschedules a packet again o=
n
> the same interface, but from another address family, so if you have
> disabled IPv6, a packet will be just dropped by ip6_input.
> You can enable IPv6 by the following command:
>=20
>  # ifconfig igb0 inet6 -ifdisabled

Yes, this is exactly the problem. Thank you very much!

The reason it was working in the EC2 case is because the FreeBSD AMIs
set ipv6_activate_all_interfaces=3D"YES".

It helps me quite a lot to learn the concept of "reschedules a packet
again on the same interface". That fills in a gap that I am sure will
come in handy when trying to reason about behavior in the future.

Incidentally, where are those drops counted? I did start looking at
"netstat -i" and "netstat -s" for clues, and even now that I know what
to look for, I'm not sure I know what I'm seeing. Is it "ip6: output
packets discarded due to no route"?

--=20
John W. O'Brien
OpenPGP keys:
    0x33C4D64B895DBF3B


--OsYedDgdivxpdAXCHQbXQlDunjkTOjnBk--

--IglUFb5dkvL3RpZtKTPLgvLWWSoUEBUfL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEKpEHkkRoSDiIJkQOWPtK56pP/m4FAl32XCIACgkQWPtK56pP
/m5AvAgAlCos7ED2TYRMBXuk6jQXMXv1hmSu48rsVbTp1werlLCCXbprdARlPK3Q
NKLRTIIpYMJE/0Otqpna/EcLCRlarpRR5iLwnOc0O5guwdKG6BKcmFZcaV1S7pNq
+VECPi0GuyolAWlwA1ZahsGiSYLAxpOGDpwPHpQYRMqdryrw1M/ElXT5cM2UE9qP
rU2m2IUy7BnOqgSPnWXm4UCRt+Z69tstQteLBmGq1mCGpb0ORQtQ3bIgH9yhS9LS
G/ilplKy4XbZKxn0ZI5SsuzRhP4QzqeL8ANoCE4cAJI0wuBW6TDlQap/+7vJ1jkx
TzbfZimr5i2fPsreDh2WYBGx6vSqMA==
=88Dp
-----END PGP SIGNATURE-----

--IglUFb5dkvL3RpZtKTPLgvLWWSoUEBUfL--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15ce6744-91f1-e755-22c7-0c5355686d90>