@ktims The assumption is (and has been observed by pinging *to* my home server behind this PPP link) that my ISP is correctly generating "message too long" ICMPv6 messages, but some paths then end up losing them or ignoring them. Azure seems to be particularly vulnerable to this.

Other sites? It's fine, works as designed, which is why it took this long (around mid-2025, after the config has been in use for years) for it to cause any issues, and only then intermittently on only some sites.

Yes, even on Azure I observed that *some* hosts would work fine, yes, with IPv6 when I looked into it, but others wouldn't. I've never had to deal with setting anything up on Azure myself, so have no idea how many layers there are between their "front door" and the actual services exhibiting this behaviour.

So, basically, I've gone from "oops, MSS of 4088, oh but then PMTU corrects things, most of the time" to now just forcing the correct MSS on all outbound connections.

@AthanSpod Sure, what you had before was going to break in some cases, since end-to-end ICMP isn't guaranteed.

What I am curious about is why the SSL session setup seems to matter. Once the session is up and running, assuming it's bulk data and not streaming, you're going to be transmitting MSS-sized packets. Since ssl exchange doesn't affect MSS, I'd still have expected this to hang at the start of data transfer even if it were able to get the session started before.

@AthanSpod Aha! It all makes sense again! :D