Skip to main content
Warum O2
Warenkorb
Service
Frage

IPv6 Routing probleme zu Microsoft Azure

  • July 31, 2026
  • 0 Antworten
  • 34 Aufrufe

Forum|alt.badge.img+10

Hallo Zusammen,

Es ist ja schon länger her, dass es mal wieder ein kniffliges Thema gab.

seit inzwischen rund 2 Jahre bin ich ja über das Netz von Telefonica online, bis auf ein paar Details (die z.T. in der Adressierung sind) recht zufrieden (das gute Peering ist nach >10 Jahre AS3320 ein Segen!).

Aber ich habe leider auch Punkte zu bemängeln, diesmal IPv6.

Zugegeben, die Fehlerbeschreibung ist schwer über den normalen Support zu vermitteln, jedoch hatte ich es heute versucht. Nach etwas mehr als eine Stunde (mit kurzen Wartezeiten, das ist löblich, kenne ich von anderen Anbietern anders), musste ich unverrichteter Dinge auflegen, es ist wohl nicht möglich einen Ticket aufzunehmen und in einem Textfeld das Fehlerbild zu notieren, so dass die eigentliche Technik dahinter verstehen kann wo der Schuh drückt.

Über den Kontaktformular lässt sich die Störung auch nicht melden, nur “andere Anliegen”.

Der Fehler lässt sich wie folgt beschreiben:

Einige Dienste die über die Microsoft Infrastruktur (ich nehme hier einfach mal Azure an) bereitgestellt werden, lassen sich über IPv6 nicht verwenden. Simple Beispiele wären Webseiten wie z.B. www.michelin.de, www.amundietf.de, die Login-Seite der Bausparkasse Schwäbisch-Hall (login.schwaebisch-hall.de), oder auch z.B. den Updater von Microsoft VisualStudio Code, oder den Microsoft Store in Windows, der keine Updates laden kann.

Das lässt sich in verschiedenen Varianten umgehen. Man kann z.B. über den Handy auf diese Dienste (auch über IPv6!) zugreifen, ebenso funktionieren diese bei einem o2 Kabelanschluss im Bekanntenkreis einwandfrei. Das problem war bisher lediglich an meinem Anschluss, seit mindestens 1 Jahr (vermutlich seit Vertragsbeginn) feststellbar.

Zuerst wollte ich tiefer analysieren mithilfe von TCPDump was genau passiert, aber langsam ist die Einschränkung etwas unangenehm (weil ich immer wieder IPv6 deaktivieren muss um die oben genannte Sachen zu verwenden) deshalb skippe ich einfach mal diesen Schritt und eröffne dieses Thema hier.

Natürlich wäre es zu einfach, wenn mein o2 Community Konto mit dem betroffenen o2 Kunden Konto verknüpft wäre, aber mein böser Zwilling ​@almightyloaf2 war so fleissig und hat sich für solche Sachen einen (hoffentlich temporären, ich hab ja die Hoffnung dass es irgendwann wirklich sauber läuft) Konto erstellt. Falls unbedingt nötig kann er auch hier nochmal ein kurzes “Hello” von sich geben :)

Da sicherlich mehr Kunden betroffen sind (letztendlich kriege ich ja jede Nacht einen neuen IPv6 präfix, andere o2 Kunden kriegen “meinen alten” irgendwann ja auch), hoffe ich aber auch dass ein Moderator (selbstverständlich wenn er dazu kommt und Zeit für hat) mal intern nachfragen kann, ob die Routen hier mal überprüft werden könnten. Es gab ja auch mal in der Vergangenheit, allerdings nicht auf Microsoft Azure bezogen, würde meiner Ansicht nach aber zum Fehlerbild recht gut passen.

Der Unterschied ist allerdings, es scheitern nicht 30% oder 50% der Verbindungsversuche, sondern immer 100% (wobei irgendwann habe ich auch aufgegeben, ich werde die Seiten nicht 200x aufrufen :D )

Wenn jemanden Ahnung hat und mit diesem Output was anfangen kann (oder bessere Tipps hat, teste ich gerne), hier mal als Beispiel mit der Webseite www.michelin.de (oder falls ein Moderator das mal intern weiterleiten möchte ;) )

Mit Curl sieht es so aus (der connection reset am Ende kommt nach einer halben Ewigkeit) 

curl -v -s https://www.michelin.de/ -o /dev/null
* Host www.michelin.de:443 was resolved.
* IPv6: 2603:1061:14:133::1
* IPv4: 150.171.110.56
* Trying [2603:1061:14:133::1]:443...
* Connected to www.michelin.de (2603:1061:14:133::1) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [88 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to www.michelin.de:443
* Closing connection

TCPdump liefert folgendes:

sudo tcpdump ip6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:38:32.777380 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [S], seq 2922770860, win 64800, options [mss 1440,sackOK,TS val 496973713 ecr 0,nop,wscale 7], length 0
20:38:32.789075 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [S.], seq 3029751708, ack 2922770861, win 65535, options [mss 1400,sackOK,TS val 3398689301 ecr 496973713,nop,wscale 9], length 0
20:38:32.789143 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 496973724 ecr 3398689301], length 0
20:38:32.800001 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 496973735 ecr 3398689301], length 517
20:38:32.811879 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [.], ack 518, win 131, options [nop,nop,TS val 3398689324 ecr 496973735], length 0
20:38:32.812102 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 1:100, ack 518, win 131, options [nop,nop,TS val 3398689324 ecr 496973735], length 99
20:38:32.812123 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973747 ecr 3398689324], length 0
20:38:32.909126 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [P.], seq 518:1041, ack 100, win 507, options [nop,nop,TS val 496973844 ecr 3398689324], length 523
20:38:32.921405 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 2956:4196, ack 1041, win 133, options [nop,nop,TS val 3398689434 ecr 496973844], length 1240
20:38:32.921451 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973857 ecr 3398689324,nop,nop,sack 1 {2956:4196}], length 0
20:38:32.924481 IP6 2603:1061:14:135::1.https > dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058: Flags [P.], seq 7052:7428, ack 1041, win 133, options [nop,nop,TS val 3398689437 ecr 496973844], length 376
20:38:32.924507 IP6 dynamic-2a02-3100-IPv6-ac2e.310.pool.telefonica.de.46058 > 2603:1061:14:135::1.https: Flags [.], ack 100, win 507, options [nop,nop,TS val 496973860 ecr 3398689324,nop,nop,sack 2 {7052:7428}{2956:4196}], length 0
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Meine IPv6 ist natürlich zensiert.

Hoffentlich lässt sich das geradebiegen (aber ich bin auch etwas erstaunt dass sowas solange nicht auffällt...)

Jedenfalls freue ich mich auf dem Input der Community und auf die vielen verschiedenen Tests die man so machen kann um das Problem besser zu verstehen