On Tue, Jul 29, 2025 at 02:22:36PM -0700, Joel wrote:
> > 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.
Ahhh! That likely explains a tech escalation from my son about a month
ago - the MineCraft authentication servers were taking about ~5 minutes
to fall back to IPv4. I fixed it by fixing my previous failed attempt at
mss clamping for IPv6 in npf:
$ext_if = "pppoe0"
$ext_v6 = { 2001:44b8:3158:7e00::/56, 2001:44b8:31a3:5d00::/56 }
procedure "mssclamp" { normalize: "max-mss" 1432 }
group "external" on $ext_if {
...
pass stateful out final family inet6 proto tcp from $ext_v6 to any apply
"mssclamp"
...
}
--
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.
