The rest of Greg's message I agree with, but if you
decide on the cheap way out:
| Run "ifconfig awge0 1480" and stop worrying entirely.
you're going to need "mtu" between the interface name and
the value (as written it will try to teat "1480" as an address
to configure!)
I was going to save this for my weekend project, but couldn't stop
worrying entirely :)
Ultimately, I solved this with MSS-clamping in OpenBSD pf. In pf.conf, I
added:
match on gif0 all scrub (max-mss 1420)
I got that MSS value by subtracting header size with an MTU of 1480 on
my HE tunnel (i.e. gif0).
I was able to set MTU 1500 back on my Win11 and Debian machines with the
pf change and I can hit *.microsoft.com sites via IPv6 without freezing
on TLS handshake.
This was not a NetBSD issue, to be clear. So special thanks to Greg for
still reaching out and helping me diagnose this. I trust NetBSD's IPv6
stack the most; hence why I debugged on my NetBSD 10.1 device.
The root cause is that Azure Networking currently does not support Path
MTU Discovery (PMTUD). As more Microsoft websites come up with AAAA
records, most of those sites use Azure Networking (without Azure Front
Door) and can cause this issue.
Thanks - Joel
