Skip to content

Instantly share code, notes, and snippets.

@gleber

gleber/README.md

Last active May 13, 2026 13:34
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save gleber/a874c0bf21abe76e9da043da8bd643cc to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save gleber/a874c0bf21abe76e9da043da8bd643cc to your computer and use it in GitHub Desktop.
Download ZIP
Orange Poland (AS5617) <> Azure Front Door IPv6 connectivity issues
Raw
README.md

Summary

TCP connections to Azure Front Door IPv6 endpoints in the 2620:1ec::/32 range fail completely from Orange Poland's IPv6 network (AS5617). ICMP probes successfully reach Azure's internal infrastructure, confirming the issue is not a BGP peering problem — packets enter Azure's network but TCP sessions to the Front Door anycast IPs never complete. Multiple production sites using Azure Front Door are affected.

Affected Endpoints

DNS name CNAME chain Azure Front Door IPv6
www.doz.pl → ecom-apps-drdncufehfg0euds.a03.azurefd.net → dual.part-0016.t-0009.fb-t-msedge.net 2620:1ec:48:1::44, 2620:1ec:29:1::44
www.bankmillennium.pl → Azure Front Door 2620:1ec:48:1::44

Both resolve to the same Azure Front Door IPv6 addresses. IPv4 connectivity to these sites is fully functional.

Source Network

  • ISP: Orange Poland (TPNET)
  • AS: AS5617
  • IPv6 source prefix: 2a01:110f:4e0e:da00::/64 (DHCPv6-PD delegated /56: 2a01:110f:4e0e:da00::/56)
  • Test machines: Two independent hosts on the same prefix (NixOS/Linux and Windows 11)

Evidence

1. DNS Resolution

www.doz.pl → ecom-apps-drdncufehfg0euds.a03.azurefd.net
           → mr-a03.tm-azurefd.net
           → dual.part-0016.t-0009.fb-t-msedge.net
           → 2620:1ec:29:1::44 (AAAA)
              2620:1ec:48:1::44 (AAAA)
              13.107.226.44    (A)

2. TCP Connection Test (Linux/luna, curl)

$ curl -6 -v --connect-timeout 5 https://www.doz.pl/
*   Trying [2620:1ec:48:1::44]:443...
* Connection timed out after 5001 milliseconds

Same result from Windows host on the same network. IPv4 succeeds immediately:

$ curl -4 -v https://www.doz.pl/
* Connected to www.doz.pl (13.107.226.44) port 443
< HTTP/2 200

3. MTR from Linux host (luna, 2a01:110f:4e0e:da00:e4a7:db11:70f9:623b)

HOST: luna                         Loss%   Snt   Last   Avg
  1. 2a01:110f:4e0e:da00::1          0.0%    5    0.9   0.7   ← MikroTik router
  2. 2a01:1000::6ca                   0.0%    5    5.3   4.6   ← Orange PL
  3. 2a01:1000:0:5ca::1               0.0%    5    3.9   3.6
  4. 2a01:1000::35                    0.0%    5    2.7   5.8
  5. 2a01:1100:0:100::129            80.0%    5    3.8   3.8   ← ICMP rate-limited (normal)
  6. 2a01:111:2000:2:8000::f5d        0.0%    5    3.0   3.5   ← Microsoft AS8075
  7. 2a01:111:2000:6::461e            0.0%    5   23.3  22.1
  8. 2a01:111:201:f200::1242         60.0%    5   21.2  21.9   ← ICMP rate-limited (normal)
  9. 2a01:111:201:f200::1131          0.0%    5   20.9  21.6
 10. 2a01:111:2000:6::4fcd            0.0%    5   22.2  21.6
 11. 2603:10a0:1203:1200::e           0.0%    5   19.8  19.8   ← Azure internal
 12. 2603:10a0:1203:1101::e           0.0%    5   22.4  21.9
 13. 2603:10a0:120c:390::             0.0%    5   19.8  20.3
 14. 2603:10a0:120c:390::1a           0.0%    5   19.8  20.2
 15. ???                            100.0%    5    0.0   0.0   ← no response (ICMP blocked at endpoint — expected)

ICMP probes transit Orange PL cleanly, enter Microsoft's network at hop 6 (2a01:111:..., AS8075), traverse Azure's internal backbone (2603:10a0:...), and reach the penultimate hop at ~20ms RTT. The 100% loss at hop 15 is consistent with ICMP being blocked at the final endpoint — this is expected behavior for Azure Front Door. The issue is not ICMP loss — it is that TCP connections to 2620:1ec:48:1::44:443 do not complete.

4. Windows tracert (host 2a01:110f:4e0e:da00:...)

Tracing route to 2620:1ec:48:1::44

  1    625 ms   2a01:110f:4e0e:da00::1    ← local router
  2   1117 ms   2a01:1000::6ca            ← Orange PL
  3    509 ms   2a01:1000:0:5ca::1
  4    372 ms   2a01:1000::35
  5      *        2a01:1100:0:100::129
  6    849 ms   2a01:111:2000:2:8000::f5d ← Microsoft AS8075
  7    545 ms   2a01:111:2000:6::461a
  8    235 ms   2a01:111:201:f200::1246
  9   1333 ms   2a01:111:2000:6::4ca9
 10   1303 ms   2603:10a0:1203:9100::1e
 11    107 ms   2603:10a0:1203:9301::26
 12   1311 ms   2603:10a0:120c:391::
 13    935 ms   2603:10a0:120c:391::1e    ← last visible hop
 14-30  *  *  *  Request timed out.

Note: Windows tracert high latency on first hops is due to the Windows IPv6 stack sending initial probes over a temporary address — not indicative of actual path latency (Linux MTR shows ~20ms end-to-end).

Key Observation

ICMP probes traverse the path 2a01:111:... → 2603:10a0:... (Azure backbone), reaching deep into Azure's infrastructure. However, TCP connections destined for 2620:1ec:48:1::44 (a different Azure prefix, Front Door anycast) time out. This indicates a routing inconsistency within Azure's network: ICMP probes are being forwarded to one internal path while TCP packets to 2620:1ec:48::/48 are being dropped or routed to a black hole after entering AS8075.

This is not an Orange Poland peering issue. IPv6 peering between AS5617 and AS8075 is functional.

Reproduction Steps

  1. From any host on Orange Poland IPv6 (2a01:110f:4e0e::/48 or similar AS5617 prefix):
  2. curl -6 --connect-timeout 10 https://www.doz.pl/ → times out
  3. curl -4 --connect-timeout 10 https://www.doz.pl/ → succeeds immediately
  4. curl -6 --connect-timeout 10 https://www.bankmillennium.pl/ → times out

Impact

  • All Orange Poland residential/business IPv6 users attempting to access Azure Front Door-hosted sites experience timeouts
  • Modern browsers attempt IPv6 first (RFC 6555 Happy Eyeballs); with a non-responsive IPv6 endpoint, they wait the full Happy Eyeballs timeout (~300ms) before falling back to IPv4 — but some clients (mobile apps, certain HTTP libraries) do not fall back gracefully and fail entirely
  • Affected sites include at minimum: www.doz.pl, www.bankmillennium.pl; any other site using Azure Front Door with AAAA records is likely also affected for Orange PL users

Requested Action

  1. Investigate routing within AS8075/Azure Front Door for destination 2620:1ec:48::/48 from source AS5617 (2a01:110f:4e0e::/48)
  2. Verify that TCP packets (port 443) from AS5617 are being delivered to the correct Front Door PoP
  3. Check for any ACL or routing policy filtering traffic from AS5617 to 2620:1ec::/32

Report generated: 2026-05-13. Testing performed from Orange Poland FTTH, Warsaw area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment