20
Cisco IOS IPv6 Tunnel MTU Problem dauerhafte TLS-Handshakes
Hallo,
ich hatte habe das Problem ja schon lange, ich will das aber jetzt richtig angehen (MTU nicht manuell auf den Clients setzen).
Problem:
Bei manchen Seiten (yahoo.com, rt.com) kommt keine TLS-Verbindung zustande, es wird minutenlang ein TLS-Handschlag durchgeführt. Dies tritt browser- und betriebssystemübergreifend auf.
Das tritt nur bei IPv6 auf, ich betreibe einen IPv6-Tunnel von HE.
Dieser hat bedingt durch den Tunnelmechanismus eine MTU von 1472.
Setze ich die MTU am PC manuell auf 1472 funktioniert alles. Das will ich aber nicht an jedem PC tun.
An einem anderen Anschluss mit FritzBox und einem HE-Tunnel klappt alles, ergo also kein Problem des Tunnelanbieters.
Schuld könnte die Firewall im Cisco-IOS sein.
Anfangs hatte ich am Tunnel keinerlei FW-Regeln eingerichtet.
Jetzt habe ich eine eingerichtet, die alles durchlassen soll (das ist aus Diagnosegründen auch so gewünscht, mir ist die Gefahr bekannt).
Sowohl ausgehend als auch eingehend sollte also alles erlaubt sein.
Das Problem besteht aber weiterhin.
Ich habe daher an beiden Anschlüssen einen Paketmitschnitt am Beispiel von Yahoo gemacht.
https://www.filedropper.com/daheim
https://www.filedropper.com/yahoo
LG WIn10Gegner
ich hatte habe das Problem ja schon lange, ich will das aber jetzt richtig angehen (MTU nicht manuell auf den Clients setzen).
Problem:
Bei manchen Seiten (yahoo.com, rt.com) kommt keine TLS-Verbindung zustande, es wird minutenlang ein TLS-Handschlag durchgeführt. Dies tritt browser- und betriebssystemübergreifend auf.
Das tritt nur bei IPv6 auf, ich betreibe einen IPv6-Tunnel von HE.
Dieser hat bedingt durch den Tunnelmechanismus eine MTU von 1472.
Setze ich die MTU am PC manuell auf 1472 funktioniert alles. Das will ich aber nicht an jedem PC tun.
An einem anderen Anschluss mit FritzBox und einem HE-Tunnel klappt alles, ergo also kein Problem des Tunnelanbieters.
Schuld könnte die Firewall im Cisco-IOS sein.
Anfangs hatte ich am Tunnel keinerlei FW-Regeln eingerichtet.
Jetzt habe ich eine eingerichtet, die alles durchlassen soll (das ist aus Diagnosegründen auch so gewünscht, mir ist die Gefahr bekannt).
!
ipv6 access-list ipv6acl
permit ipv6 any any
!interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 address 2001:470:xxxx/64
ipv6 enable
ipv6 mtu 1472
ipv6 traffic-filter ipv6acl in
ipv6 traffic-filter ipv6acl out
tunnel source Dialer0
tunnel mode ipv6ip
tunnel destination 216.66.80.30
!Das Problem besteht aber weiterhin.
Ich habe daher an beiden Anschlüssen einen Paketmitschnitt am Beispiel von Yahoo gemacht.
https://www.filedropper.com/daheim
https://www.filedropper.com/yahoo
LG WIn10Gegner
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 595109
Url: https://administrator.de/contentid/595109
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
20 Kommentare
Neuester Kommentar
Der Cisco müsste für dich TCP MSS-Clamping machen. Dadurch werden die vom Client gesendeten (zu großen) MSS-Values aus dem TCP-Header durch kleinere ersetzt, die durch den Tunnel passen.
Bei IPv4 setzt man das auf dem Tunnel-Interface mit "ip tcp adjust-mss", ich weiß jetzt aus dem Kopf leider nicht, ob es den Befehl exakt so für IPv6 auch gibt.
Bei IPv4 setzt man das auf dem Tunnel-Interface mit "ip tcp adjust-mss", ich weiß jetzt aus dem Kopf leider nicht, ob es den Befehl exakt so für IPv6 auch gibt.
Den Befehl gibt es exakt so auch für IPv6, wird auch angenommen.
Ändert nur nichts, habe natürlich auf shutdown und wieder no shutdown gestellt.
EDIT: Habe nun 1432 probiert, kein Erfolg, 1452 ist ja zu groß und es kommen 40 Byte IPv6-eader hinzu.
Ergo 1472-40=1432
ipv6 tcp adjust-mss 1452EDIT: Habe nun 1432 probiert, kein Erfolg, 1452 ist ja zu groß und es kommen 40 Byte IPv6-eader hinzu.
Ergo 1472-40=1432
Oh, ich habe gerade nochmal in der Anleitung nachgeschaut — diese Config muss auf das Ingress-Interface angewendet werden, also auf das dem LAN zugewandte Interface.
Auf dem Tunnel-IF hat das dann nur Wirkung bei eingehenden Verbindungen (schadet also vermutlich nicht).
Auf dem Tunnel-IF hat das dann nur Wirkung bei eingehenden Verbindungen (schadet also vermutlich nicht).
Habe ich gemacht, bisher keine Wirkung. Habe den kompletten Router neugestartet.
interface Vlan1
description internal_LAN
ip address 10.0.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ipv6 address 2001:470:xxx/64
ipv6 enable
ipv6 mtu 1476
ipv6 nd other-config-flag
ipv6 tcp adjust-mss 1432
ipv6 dhcp server DHCPv6
!
Schuld könnte die Firewall im Cisco-IOS sein.
Arbeitest du denn mit einer CBAC Firewall oder ZBF Firewall ?
CBAC normalerweise, die aber aber nicht aktiv und soll es auch vorerst nicht werden.
Alles durchlassen soll vorerst passen. Bei mir laufen keine Dienste, die nicht laufen sollen.
Alles durchlassen soll vorerst passen. Bei mir laufen keine Dienste, die nicht laufen sollen.
OK, aber dann hast du ja keinerlei Firewall aktiv und damit wäre deine spekulative Frage/Vermutung oben ja dann auch obsolet.
Wo nix aktiv ist kann auch nix gefiltert werden...
Wo nix aktiv ist kann auch nix gefiltert werden...
Es scheint aber nicht an der FW zu liegen.
Wie gesagt habe ich die MSS für Ipv6 im vlan 1 auf 1432 gesetzt (20 Bit weniger als beim IPv4). Passt das so?
Wie gesagt habe ich die MSS für Ipv6 im vlan 1 auf 1432 gesetzt (20 Bit weniger als beim IPv4). Passt das so?
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 address 2001:470:1xxxx/64
ipv6 enable
ipv6 mtu 1472
ipv6 tcp adjust-mss 1432
ipv6 traffic-filter ipv6acl in
ipv6 traffic-filter ipv6acl out
tunnel source Dialer0
tunnel mode ipv6ip
tunnel destination 216.66.80.30Es scheint aber nicht an der FW zu liegen.
Eben ! Wenn du gar keine aktiv hast kanns daran ja auch nicht liegen...Passt das so?
Kannst du dir selber ausrechnen: https://baturin.org/tools/encapcalc/
Da war ich schon. Ich habe als Parent MTU 1472 eingegeben und dann nur IPv6 (40 Byte) gewählt.
Wenn ich es richtig verstanden habe muss ich aber noch den TCP-Header (20 Byte) abziehen, dann wären wir bei 1412, richtig?
Ich will ungern noch 5x den Cisco neustarten
Wenn ich es richtig verstanden habe muss ich aber noch den TCP-Header (20 Byte) abziehen, dann wären wir bei 1412, richtig?
Ich will ungern noch 5x den Cisco neustarten
Geht immer noch nicht mit 1412, auch nach dem Neustart.
Ich bin leider jetzt erst dazu gekommen, wirklich die PCAPs anzuschauen.
Die MSS in den TCP-Paketen sieht bereits richtig aus - die wird offenbar von der FritzBox korrekt gesetzt.
Der TCP-Stream im PCAP sieht ebenfalls gut aus, da sind keine Retransmissions zu erkennen (was bei MTU-Problemen zwangsläufig auftreten würde) oder andere offensichtliche Anomalieen auf Layer 3/4.
Interessant ist allerdings die Cipherauswahl des Clients. Diese TLS-Handshakes kann ich tatsächlich aktuell keinem Betriebssystem oder Client zuordnen.
Entweder ist das recht alte Software, die da eine Verbindung versucht - oder da ist irgendeine "Sicherheitssoftware", die die TLS-Verbindung aufbricht und dadurch schwächt. Falls du da einen Virenscanner hast, der TLS aufbricht, deaktiviere den testweise mal und starte den Browser auch mal in einem Private-Tab und teste dann, ob der Aufruf von Yahoo nun funktioniert.
Die MSS in den TCP-Paketen sieht bereits richtig aus - die wird offenbar von der FritzBox korrekt gesetzt.
Der TCP-Stream im PCAP sieht ebenfalls gut aus, da sind keine Retransmissions zu erkennen (was bei MTU-Problemen zwangsläufig auftreten würde) oder andere offensichtliche Anomalieen auf Layer 3/4.
Interessant ist allerdings die Cipherauswahl des Clients. Diese TLS-Handshakes kann ich tatsächlich aktuell keinem Betriebssystem oder Client zuordnen.
Entweder ist das recht alte Software, die da eine Verbindung versucht - oder da ist irgendeine "Sicherheitssoftware", die die TLS-Verbindung aufbricht und dadurch schwächt. Falls du da einen Virenscanner hast, der TLS aufbricht, deaktiviere den testweise mal und starte den Browser auch mal in einem Private-Tab und teste dann, ob der Aufruf von Yahoo nun funktioniert.
Die Datei yahoo ist unter Ubuntu 20.04 mit Pale Moon entstanden , da funktioniert alles.
Bei mir daheim tritt es in exakt gleicher Konstellatio auf, am anderen Anschluss nicht. Pale Moon unter Ubuntu bzw. Debian und auch im Firefox und in Chromium ist der Effekt vorhanden.
Die Datei daheim ist notgedrungen unter FF 52 (XP) entstanden (ja, unsicher), da ich gerade keine andere VM zur Hand hatte, kann aber gerne direkt vom PC wahlweise mit FF, PM oder Chrome aufzeichnen.
Bei mir daheim tritt es in exakt gleicher Konstellatio auf, am anderen Anschluss nicht. Pale Moon unter Ubuntu bzw. Debian und auch im Firefox und in Chromium ist der Effekt vorhanden.
Die Datei daheim ist notgedrungen unter FF 52 (XP) entstanden (ja, unsicher), da ich gerade keine andere VM zur Hand hatte, kann aber gerne direkt vom PC wahlweise mit FF, PM oder Chrome aufzeichnen.
Ah, ich bin da mit den Dateien durcheinander gekommen. In der "daheim.pcapng" ist definitiv die MSS zu hoch (1460 Bytes). Die Frage ist, ob das aktuell immer noch so ist - kannst du das noch einmal jetzt mit der angewendeten Config (die normalerweise keinen Reboot des Routers braucht) testen? Im SYN-Paket findest du das MSS-Value.
Auf der Verbindung zwischen dem Cisco und HE müsste das maximal dem Wert entsprechen, den du konfiguriert hast.
Auf der Verbindung zwischen dem Cisco und HE müsste das maximal dem Wert entsprechen, den du konfiguriert hast.
Das erste SYN-Paket (Quelle: Ich) hat eine MSS von 1416, im Cisco sind 1412 konfiguriert.
Das Paket von Yahoo 1440.
Beides macht mich stutzig.
Der neue Mitschnitt (Debian 10, Pale Moon)
http://www.filedropper.com/daheimneu
Das Paket von Yahoo 1440.
Beides macht mich stutzig.
Der neue Mitschnitt (Debian 10, Pale Moon)
http://www.filedropper.com/daheimneu
Sorry, hatte ein wenig um die Ohren.
Die MSS im neuen Capture sieht mit 1416 Bytes eigentlich vollkommen in Ordnung aus.
Könnte es sein, dass die MTU bei HE niedriger konfiguriert ist als auf deiner Seite? Inkonsistente MTUs könnten das Verhalten erklären.
Laut dem Capture kommt die TCP-Verbindung zustande, dein Client sendet den Client-Hello und bekommt diesen per ACK von Yahoo bestätigt.
Das bedeutet also theoretisch, dass der Server-Hello nicht ankommt, weil er möglicherweise zu groß ist und PMTU-Discovery bei Yahoo nicht ordentlich funktioniert.
Die MSS im neuen Capture sieht mit 1416 Bytes eigentlich vollkommen in Ordnung aus.
Könnte es sein, dass die MTU bei HE niedriger konfiguriert ist als auf deiner Seite? Inkonsistente MTUs könnten das Verhalten erklären.
Laut dem Capture kommt die TCP-Verbindung zustande, dein Client sendet den Client-Hello und bekommt diesen per ACK von Yahoo bestätigt.
Das bedeutet also theoretisch, dass der Server-Hello nicht ankommt, weil er möglicherweise zu groß ist und PMTU-Discovery bei Yahoo nicht ordentlich funktioniert.
Bei HE selbst steht in der Konfigurationsanleitung nichts zur MTU.
k.A. ob dann 1472 passt, ich bin aber nochmal die Mail von HE durchgegangen, die sagten der Ubuntu-PC soll eine MTU von 1472 haben, sobald das so ist funktioniert ja auch alles.
configure terminal
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 enable
ipv6 address 2001:470:xxx/64
tunnel source xxxx
tunnel destination 216.66.80.30
tunnel mode ipv6ip
ipv6 route ::/0 Tunnel0
end
write
Du kannst bei HE im Webinterface die MTU für den Tunnel konfigurieren:
Auf 1472 gestellt im Webinterface und nun funktioniert es.
Beim anderen Tunnel (gleicher Provider, FB7490) steht es auf 1480 und es tut problemlos.
Beim anderen Tunnel (gleicher Provider, FB7490) steht es auf 1480 und es tut problemlos.
Beim anderen Tunnel (gleicher Provider, FB7490) steht es auf 1480 und es tut problemlos.
Ggf. weil du vergessen hast tunnel path-mtu-discovery auf dem Tunnel Interface zu konfigurieren.Damit macht der Router eine automatische MTU Discovery.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-c ...
