IPv6 PMTUD-Problem – PPPoE MTU 1492 – Paketverlust zu Azure Front Door (login.schwaebisch-hall.de)
vor 14 Tagen
Hallo zusammen,
ich habe ein reproduzierbares IPv6-Problem an meinem Telekom-PPPoE-Anschluss und würde mich freuen, wenn sich das jemand aus dem IPv6-/Netzwerkbereich ansehen könnte.
Es geht konkret um:
https://login.schwaebisch-hall.de
Über IPv4 funktioniert die Seite problemlos. Über IPv6 an meinem Telekom-Anschluss beginnt die Verbindung, bleibt aber während des TLS-Handshakes hängen und läuft schließlich in einen Timeout.
Über einen anderen Internetzugang (z. B. Mobilfunk) funktioniert dieselbe Seite auch per IPv6.
Anschluss / MTU
Der Telekom-Anschluss läuft über PPPoE.
Die tatsächlich ausgehandelte PPPoE-MTU beträgt 1492 Byte.
Die Clients im LAN haben die normale MTU von 1500 Byte.
Ich verwende einen eigenen Router (MikroTik), keine FRITZ!Box.
Das Problem lässt sich eindeutig von der MTU abhängig reproduzieren
Client MTU 1500, kein MSS-Clamping:
IPv6-Verbindung zu login.schwaebisch-hall.de schlägt fehl.
Client MTU 1492, kein MSS-Clamping:
IPv6-Verbindung funktioniert.
Client MTU 1500, TCP-MSS auf 1432 begrenzt:
IPv6-Verbindung funktioniert ebenfalls.
1432 ergibt sich aus:
1492 Byte MTU - 40 Byte IPv6 - 20 Byte TCP = MSS 1432
Paketmitschnitt der fehlerhaften Verbindung
Der TCP-Verbindungsaufbau funktioniert zunächst normal.
Der Server sendet die ersten 99 Bytes und der Client bestätigt mit:
ACK 100
Danach fehlen im Server→Client-Datenstrom die Bytes mit den TCP-Sequenznummern 100 bis 2955.
Spätere Serverdaten ab SEQ 2956 erreichen den Client dagegen wieder.
Der Client meldet das entstandene Loch korrekt per TCP SACK:
ACK 100
SACK 2956-4380
Das heißt: Die Verbindung an sich besteht weiterhin und spätere Pakete kommen an, aber ein bestimmter Teil des Server→Client-Datenstroms geht verloren.
Vergleich mit MSS 1432
Wenn ich auf dem Router ausschließlich die IPv6-TCP-MSS auf 1432 begrenze, funktioniert die Verbindung sofort.
Im Paketmitschnitt sieht man dann:
Client SYN: MSS 1432
Server SYN/ACK: MSS 1400
Der Server sendet anschließend den zuvor fehlenden Bereich vollständig.
Dabei kommen sehr viele Serverpakete mit exakt 1492 Byte IPv6-Gesamtgröße an.
Beispielsweise:
SEQ 100, TCP-Daten 1420 Byte, Gesamtgröße 1492 Byte
SEQ 1520, TCP-Daten 1420 Byte, Gesamtgröße 1492 Byte
Damit ist der Zusammenhang mit der PMTU von 1492 sehr gut reproduzierbar.
PMTUD mit externem Server gegengeprüft
Um auszuschließen, dass mein Router generell ICMPv6 Packet Too Big blockiert oder PMTUD grundsätzlich nicht funktioniert, habe ich zusätzlich mit einem eigenen Linux-VPS im Internet getestet.
Vom VPS habe ich ein unfragmentiertes 1500-Byte-IPv6-Paket zu meinem Anschluss geschickt.
Der VPS erhält daraufhin korrekt:
ICMPv6 Packet Too Big, MTU 1492
Quelle der PTB-Nachricht war bei diesem Test:
2003:0:8902:3000::1
Linux übernimmt daraufhin korrekt eine Path MTU von 1492.
Auch ein TCP-Test mit iperf3 vom VPS zu meinem Anschluss funktioniert ohne MSS-Clamping mit rund 480 Mbit/s. Im Paketmitschnitt sind dabei die entsprechenden ICMPv6 Packet Too Big mit MTU 1492 sichtbar.
PMTUD vom Internet zu meinem Telekom-Anschluss funktioniert mit diesem unabhängigen Server also grundsätzlich.
Auch in Gegenrichtung konnte ich die Grenze bestätigen: 1492 Byte funktionieren, ab 1493 Byte wird ein ICMPv6 Packet Too Big mit MTU 1492 erzeugt.
Vermutung / Frage an die Telekom
Das Problem scheint daher spezifisch auf dem IPv6-Pfad zwischen Microsoft/Azure Front Door und meinem Telekom-Anschluss aufzutreten.
login.schwaebisch-hall.de liegt hinter Azure Front Door. Bei meinen Tests wurden unter anderem diese IPv6-Adressen verwendet:
2603:1061:14:6a::1
2603:1061:14:63::1
Ich möchte damit ausdrücklich nicht behaupten, dass der Fehler zwingend im Telekom-Netz liegt. Es wäre aber interessant zu wissen, ob auf dem Pfad Azure/Microsoft → Telekom die ICMPv6 Packet Too Big Nachrichten mit MTU 1492 korrekt erzeugt und Richtung Azure zurückgeschickt werden.
Mit meinem eigenen VPS funktioniert genau dieser Mechanismus nachweislich.
Könnte das bitte jemand prüfen bzw. bei Bedarf an die zuständige IPv6-/IP-/ Peering -Fachabteilung weitergeben?
Ich habe Paketmitschnitte für:
- den fehlerhaften Zugriff ohne MSS-Clamping
- den funktionierenden Zugriff mit MSS 1432
- den PMTUD-Test mit dem externen VPS
- den funktionierenden TCP/iperf3-Test mit PMTU 1492
und kann diese bei Bedarf zur Verfügung stellen.
Vielen Dank!
Mit freundlichen Grüßen,
Karol Babioch
59
7
Das könnte Ihnen auch weiterhelfen
vor weniger als einer Minute
in
1
0
0
52
0
5
vor 23 Stunden
in
41
0
6
vor 2 Tagen
78
0
9
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 14 Tagen
Du hast aber schon gelesen, was in der Rückmeldung von Schwäbisch Hall geschrieben steht?
0
1
von
vor 14 Tagen
Nein, wenn es man es über IPv6 ohne MSS Clamping probiert, läuft man in ein TLS Timeout, da wird im Browser sicherlich nichts angezeigt:
---
curl -6 --connect-timeout 10 -v \
https://login.schwaebisch-hall.de/ -o /dev/null
* Host login.schwaebisch-hall.de:443 was resolved.
* IPv6: 2603:1061:14:6a::1
* IPv4: (none)
* Trying [2603:1061:14:6a::1]:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1580 bytes data]
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
{ [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]
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* Connection timed out after 10002 milliseconds
* closing connection #0
curl: (28) Connection timed out after 10002 milliseconds
---
Um das Problem nachstellen zu können, darf man aber nicht hinter eine bequemen Fritzbox sein, die das Problem ggf. durch MSS Clamping kaschiert.
Hier ist die PMTU Discovery kaputt. Entweder werden die "Packet too big" Nachrichten im Telekom-Netz verschluckt, oder von Microsoft gar nicht erst losgeschickt. Ich kann das nicht überprüfen, daher meine Anfrage.
Uneingeloggter Nutzer
von
vor 14 Tagen
Potentiell geht das in diese Richtung: https://telekomhilft.telekom.de/conversations/festnetz-internet/pmtud-blackhole-auf-telekom-netz/68ffe18a860e8150b4800bbf?commentId=68ffea0b9b1c1f21a0302e6a
Es kommt mir unschön vor, dass MSS Clamping hier als akzeptierte Lösung gehandelt wird, wenn alle Verbindungen zu Microsoft / Azure betroffen sind.
0
vor 14 Tagen
Ich verwende einen eigenen Router (MikroTik), keine FRITZ!Box.
Hallo zusammen,
ich habe ein reproduzierbares IPv6-Problem an meinem Telekom-PPPoE-Anschluss und würde mich freuen, wenn sich das jemand aus dem IPv6-/Netzwerkbereich ansehen könnte.
Es geht konkret um:
https://login.schwaebisch-hall.de
Über IPv4 funktioniert die Seite problemlos. Über IPv6 an meinem Telekom-Anschluss beginnt die Verbindung, bleibt aber während des TLS-Handshakes hängen und läuft schließlich in einen Timeout.
Über einen anderen Internetzugang (z. B. Mobilfunk) funktioniert dieselbe Seite auch per IPv6.
Anschluss / MTU
Der Telekom-Anschluss läuft über PPPoE.
Die tatsächlich ausgehandelte PPPoE-MTU beträgt 1492 Byte.
Die Clients im LAN haben die normale MTU von 1500 Byte.
Ich verwende einen eigenen Router (MikroTik), keine FRITZ!Box.
Das Problem lässt sich eindeutig von der MTU abhängig reproduzieren
Client MTU 1500, kein MSS-Clamping:
IPv6-Verbindung zu login.schwaebisch-hall.de schlägt fehl.
Client MTU 1492, kein MSS-Clamping:
IPv6-Verbindung funktioniert.
Client MTU 1500, TCP-MSS auf 1432 begrenzt:
IPv6-Verbindung funktioniert ebenfalls.
1432 ergibt sich aus:
1492 Byte MTU - 40 Byte IPv6 - 20 Byte TCP = MSS 1432
Paketmitschnitt der fehlerhaften Verbindung
Der TCP-Verbindungsaufbau funktioniert zunächst normal.
Der Server sendet die ersten 99 Bytes und der Client bestätigt mit:
ACK 100
Danach fehlen im Server→Client-Datenstrom die Bytes mit den TCP-Sequenznummern 100 bis 2955.
Spätere Serverdaten ab SEQ 2956 erreichen den Client dagegen wieder.
Der Client meldet das entstandene Loch korrekt per TCP SACK:
ACK 100
SACK 2956-4380
Das heißt: Die Verbindung an sich besteht weiterhin und spätere Pakete kommen an, aber ein bestimmter Teil des Server→Client-Datenstroms geht verloren.
Vergleich mit MSS 1432
Wenn ich auf dem Router ausschließlich die IPv6-TCP-MSS auf 1432 begrenze, funktioniert die Verbindung sofort.
Im Paketmitschnitt sieht man dann:
Client SYN: MSS 1432
Server SYN/ACK: MSS 1400
Der Server sendet anschließend den zuvor fehlenden Bereich vollständig.
Dabei kommen sehr viele Serverpakete mit exakt 1492 Byte IPv6-Gesamtgröße an.
Beispielsweise:
SEQ 100, TCP-Daten 1420 Byte, Gesamtgröße 1492 Byte
SEQ 1520, TCP-Daten 1420 Byte, Gesamtgröße 1492 Byte
Damit ist der Zusammenhang mit der PMTU von 1492 sehr gut reproduzierbar.
PMTUD mit externem Server gegengeprüft
Um auszuschließen, dass mein Router generell ICMPv6 Packet Too Big blockiert oder PMTUD grundsätzlich nicht funktioniert, habe ich zusätzlich mit einem eigenen Linux-VPS im Internet getestet.
Vom VPS habe ich ein unfragmentiertes 1500-Byte-IPv6-Paket zu meinem Anschluss geschickt.
Der VPS erhält daraufhin korrekt:
ICMPv6 Packet Too Big, MTU 1492
Quelle der PTB-Nachricht war bei diesem Test:
2003:0:8902:3000::1
Linux übernimmt daraufhin korrekt eine Path MTU von 1492.
Auch ein TCP-Test mit iperf3 vom VPS zu meinem Anschluss funktioniert ohne MSS-Clamping mit rund 480 Mbit/s. Im Paketmitschnitt sind dabei die entsprechenden ICMPv6 Packet Too Big mit MTU 1492 sichtbar.
PMTUD vom Internet zu meinem Telekom-Anschluss funktioniert mit diesem unabhängigen Server also grundsätzlich.
Auch in Gegenrichtung konnte ich die Grenze bestätigen: 1492 Byte funktionieren, ab 1493 Byte wird ein ICMPv6 Packet Too Big mit MTU 1492 erzeugt.
Vermutung / Frage an die Telekom
Das Problem scheint daher spezifisch auf dem IPv6-Pfad zwischen Microsoft/Azure Front Door und meinem Telekom-Anschluss aufzutreten.
login.schwaebisch-hall.de liegt hinter Azure Front Door. Bei meinen Tests wurden unter anderem diese IPv6-Adressen verwendet:
2603:1061:14:6a::1
2603:1061:14:63::1
Ich möchte damit ausdrücklich nicht behaupten, dass der Fehler zwingend im Telekom-Netz liegt. Es wäre aber interessant zu wissen, ob auf dem Pfad Azure/Microsoft → Telekom die ICMPv6 Packet Too Big Nachrichten mit MTU 1492 korrekt erzeugt und Richtung Azure zurückgeschickt werden.
Mit meinem eigenen VPS funktioniert genau dieser Mechanismus nachweislich.
Könnte das bitte jemand prüfen bzw. bei Bedarf an die zuständige IPv6-/IP-/ Peering -Fachabteilung weitergeben?
Ich habe Paketmitschnitte für:
und kann diese bei Bedarf zur Verfügung stellen.
Vielen Dank!
Mit freundlichen Grüßen,
Karol Babioch
Dann richte ihn halt richtig ein?
Es kommt mir unschön vor, dass MSS Clamping hier als akzeptierte Lösung gehandelt wird
Potentiell geht das in diese Richtung: https://telekomhilft.telekom.de/conversations/festnetz-internet/pmtud-blackhole-auf-telekom-netz/68ffe18a860e8150b4800bbf?commentId=68ffea0b9b1c1f21a0302e6a
Es kommt mir unschön vor, dass MSS Clamping hier als akzeptierte Lösung gehandelt wird, wenn alle Verbindungen zu Microsoft / Azure betroffen sind.
Ist es halt .. MSS Clamping ist für die kaputte IPv6 Welt halt die Lösung.
Ob du das nun schön findest oder nicht, ist dein Problem.
Dein VPS Test hat doch nur bewiesen, dass es zumindest pauschal nicht im Telekom Netz liegt.
0
2
von
vor 13 Tagen
Dsa habe ich, gemäß allen RFCs. Leider reicht das in der echten Welt nicht, weil sich andere nicht daran halten. Und ich kann von meiner Stelle aus nicht prüfen, ob es am Absender oder am Provider liegt. Daher mein Beitrag.
Noch schöner wäre es, wenn die Telekom Baby Jumbo Frames zulassen würde, um 1500 Byte auch über PPPoe nutzen zu können, so wie quasi alle anderen im modernen Internet.
Abseits von schön oder nicht, löst es ja nur einen Teil der Probleme, nämlich TCP Verbindungen. Ursächlich ist die fehlende Zustellung / Aussendung der PTB Pakete. Begünstigt wird es durch die reduzierte PTU von 1492.
Genau, es liegt nicht pauschal daran. Das sagt streng genommen aber nichts über den speziellen Anwendungsfall heraus.
Auf Reddit haben wir das mittlerweile weiter untersuchen / eingrenzen können und es gibt die Probleme auch aus anderen Netzen heraus, nämlich:
Beide Netzbereiche gehören zu Microsoft. Das spricht dafür, dass diese unterschiedlich konfiguriert sind und der Fehler auf deren Seite liegt.
von
vor 9 Tagen
Hey @Karol Babioch,
teile mir doch gerne einen passendes Zeitfenster für einen Rückruf mit.
Gerne melde ich mich zwecks eine Legitimation telefonisch und hole dann unsere Kollegen der Diagnose mit ins Boot.
Beste Grüße
Julia
0
Uneingeloggter Nutzer
von
vor 13 Tagen
Noch schöner wäre es, wenn die Telekom Baby Jumbo Frames zulassen würde, um 1500 Byte auch über PPPoe nutzen zu können, so wie quasi alle anderen im modernen Internet.
Dsa habe ich, gemäß allen RFCs. Leider reicht das in der echten Welt nicht, weil sich andere nicht daran halten. Und ich kann von meiner Stelle aus nicht prüfen, ob es am Absender oder am Provider liegt. Daher mein Beitrag.
Noch schöner wäre es, wenn die Telekom Baby Jumbo Frames zulassen würde, um 1500 Byte auch über PPPoe nutzen zu können, so wie quasi alle anderen im modernen Internet.
Abseits von schön oder nicht, löst es ja nur einen Teil der Probleme, nämlich TCP Verbindungen. Ursächlich ist die fehlende Zustellung / Aussendung der PTB Pakete. Begünstigt wird es durch die reduzierte PTU von 1492.
Genau, es liegt nicht pauschal daran. Das sagt streng genommen aber nichts über den speziellen Anwendungsfall heraus.
Auf Reddit haben wir das mittlerweile weiter untersuchen / eingrenzen können und es gibt die Probleme auch aus anderen Netzen heraus, nämlich:
Beide Netzbereiche gehören zu Microsoft. Das spricht dafür, dass diese unterschiedlich konfiguriert sind und der Fehler auf deren Seite liegt.
@Karol Babioch
Dann nenne mir doch mal alle Provider in Deutschland die Baby Jumbo Frames unterstützen.
0
Uneingeloggter Nutzer
von