Azure Web Application Firewall
An Azure service that provides protection for web apps.
Intermittent IPv6 Connection Hangs/Timeouts to Azure Front Door Endpoints (t-msedge.net) on Windows 11 and Linux
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(41.6, 28.000000000000004%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJK%3C/text%3E%3C/svg%3E)
Jakub Kahoun
0
Reputation points
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
{count} votes
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(54.400000000000006, 71%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGP%3C/text%3E%3C/svg%3E)
Ganesh Patapati 10,990 Reputation points Microsoft External Staff Moderator2026-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:
- The output of your tracepath6 or ping6 -M do tests
- Any packet-capture logs showing attempted ICMPv6 PTB replies (or the lack thereof)
- 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.
-
Jakub Kahoun 0 Reputation points
2026-03-12T20:44:35.97+00:00 Hello,
thank you for your reply. I can confirm that the workaround works. After lowering the MTU to 1400 on the client, I can connect to the websites hosted on Azure cloud over IPv6.
yet, I would prefer the connection to work without any workaround.
Please find the output of the tracert command below:
Tracing route to part-0016.t-0009.t-msedge.net [2620:1ec:46::44]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms dynamic-pd01.res.v6.highway.a1.net [2001:871:266:6a40:e68d:8cff:fee3:7d30]
2 1 ms 1 ms 1 ms dynamic-pd01.res.v6.highway.a1.net [2001:871:266::3219:9027]
3 1 ms 1 ms 1 ms lg221-9076-3219.as8447.a1.net [2001:850:1:1131:0:9027:3219:1]
4 2 ms 2 ms 2 ms lg22-9080.as8447.a1.net [2001:850:1:10e::1]
5 * 2 ms 1 ms lg2-9078.as8447.a1.net [2001:850:1:126::2]
6 3 ms 3 ms 2 ms 2a01:111:2000:1::2a96
7 3 ms 3 ms 4 ms ae23-0.ier01.san30.ntwk.msn.net [2a01:111:2000:2:8000::188e]
8 72 ms 15 ms 16 ms 2603:1060:1:12::f476
9 16 ms 16 ms 16 ms 2603:1060:1:10::f545
10 17 ms 16 ms 16 ms 2603:1060:1:10::f58e
11 17 ms 16 ms 17 ms po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111:201:f200::8da]
12 17 ms 16 ms 17 ms 2a01:111:2000:6::54c1
13 15 ms 15 ms 15 ms 2603:10a0:c02:1200::7e
14 15 ms 15 ms 15 ms 2603:10a0:c02:1107::ca
15 15 ms 15 ms 15 ms 2603:10a0:c0d:be::
16 15 ms 15 ms 15 ms 2603:10a0:c0d:be::56
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * 17 ms * 2620:1ec:46::44
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
-
Ganesh Patapati 10,990 Reputation points Microsoft External Staff Moderator
2026-03-12T20:47:37.4033333+00:00 Hello Jakub Kahoun
Thanks for the reply!
Could you please provide the required details in a private message so we can proceed with further troubleshooting?
Sign in to comment
Sign in to answer