Share via

Intermittent IPv6 Connection Hangs/Timeouts to Azure Front Door Endpoints (t-msedge.net) on Windows 11 and Linux

Jakub Kahoun 25 Reputation points
2026-03-12T19:39:31.82+00:00

I am experiencing consistent connectivity issues when accessing websites hosted on the Microsoft Azure edge network (specifically endpoints like part-0016.t-0009.t-msedge.net) over IPv6. The connection hangs indefinitely during data transfer, while IPv4 connectivity works perfectly.

Environment:

Affected OS: Windows 11 (24H2/25H2) and Lubuntu (24.04).

Unaffected OS: iOS (iPad) works without modification (likely due to aggressive RFC 8305 Happy Eyeballs fallback).

Network: Dual-stack IPv4/IPv6 enabled.

Observed Behavior:

With IPv6 Enabled: Browser attempts to connect, SSL handshake often completes, but the page never loads (indefinite "Waiting for response").

With IPv6 Disabled: The website loads instantly over IPv4.

Command Line Test: * curl -4 -I https://[affected-site]Success (200 OK)

curl -6 -v https://[affected-site]Hangs after * TLSv1.3 (OUT), TLS handshake, Finished (20): or similar step.

Technical Hypothesis: This appears to be an IPv6 Path MTU Discovery (PMTUD) failure or an ICMPv6 "Packet Too Big" black hole at the Azure Front Door edge.

Small packets (handshakes) pass through.

Large data packets (MTU ~1500) are dropped by the path, but the Azure Edge node is not receiving/processing the ICMPv6 error to fragment or reduce MSS.

Windows/Linux Happy Eyeballs implementations are not falling back to IPv4 as quickly as iOS, leading to a "frozen" user experience.

Requested Action: Please investigate if there is a known MTU mismatch or ICMPv6 filtering issue on the Azure Front Door edge nodes resolving for the t-msedge.net infrastructure.

Azure Web Application Firewall

Answer accepted by question author

Ganesh Patapati 11,915 Reputation points Microsoft External Staff Moderator
2026-03-12T20:21:22+00:00

Hello Jakub Kahoun

Workaround by lowering your host MTU/MSS

Reduce effective MTU on the client or edge router (if feasible)

  • Set MTU to 1280–1400 on the client interface or upstream router This can bypass PMTUD failure by ensuring packets never exceed the minimum IPv6 MTU

If you confirm a black-hole, temporarily set a lower MTU or MSS on your OS (for example, 1400 bytes) so PMTUD isn’t needed.

Windows and Linux implementations fallback more slowly to IPv4 than iOS. You can tweak the fallback timers or disable IPv6 so you get immediate IPv4 routing.

If after checking your local/network firewalls you still see no Packet Too Big replies coming from the Azure edge, please share:

  1. The output of your tracepath6 or ping6 -M do tests
  2. Any packet-capture logs showing attempted ICMPv6 PTB replies (or the lack thereof)
  3. Details about any transit devices (home router, corporate firewall, ISP) that might filter ICMPv6.

Microsoft Docs:

Troubleshoot Azure Front Door common issues

Front Door diagnostics & RefString analysis


Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.

Was this answer helpful?

0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Jakub Kahoun 25 Reputation points
    2026-03-17T12:36:34.84+00:00

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.