windows10gegner
Goto Top

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).

!         
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
!
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

Content-Key: 595109

Url: https://administrator.de/contentid/595109

Ausgedruckt am: 19.03.2024 um 11:03 Uhr

Mitglied: LordGurke
LordGurke 09.08.2020 um 21:27:29 Uhr
Goto Top
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.
Mitglied: Windows10Gegner
Windows10Gegner 09.08.2020 aktualisiert um 21:59:05 Uhr
Goto Top
Den Befehl gibt es exakt so auch für IPv6, wird auch angenommen.
 ipv6 tcp adjust-mss 1452
Ä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
Mitglied: LordGurke
LordGurke 10.08.2020 um 00:07:53 Uhr
Goto Top
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).
Mitglied: Windows10Gegner
Windows10Gegner 10.08.2020 um 08:24:42 Uhr
Goto Top
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
!
Mitglied: aqui
aqui 10.08.2020 um 10:50:07 Uhr
Goto Top
Schuld könnte die Firewall im Cisco-IOS sein.
Arbeitest du denn mit einer CBAC Firewall oder ZBF Firewall ?
Mitglied: Windows10Gegner
Windows10Gegner 10.08.2020 um 12:08:44 Uhr
Goto Top
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.
Mitglied: aqui
aqui 10.08.2020 aktualisiert um 15:39:29 Uhr
Goto Top
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... face-wink
Mitglied: Windows10Gegner
Windows10Gegner 10.08.2020 um 15:47:21 Uhr
Goto Top
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?
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.30
Mitglied: aqui
aqui 10.08.2020 um 15:51:40 Uhr
Goto Top
Es 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/ face-wink
Mitglied: Windows10Gegner
Windows10Gegner 10.08.2020 um 16:01:04 Uhr
Goto Top
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 face-wink
Mitglied: Windows10Gegner
Windows10Gegner 10.08.2020 um 20:56:41 Uhr
Goto Top
Geht immer noch nicht mit 1412, auch nach dem Neustart.
Mitglied: LordGurke
LordGurke 11.08.2020 um 02:16:02 Uhr
Goto Top
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.
Mitglied: Windows10Gegner
Windows10Gegner 11.08.2020 um 07:08:51 Uhr
Goto Top
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.
Mitglied: LordGurke
LordGurke 11.08.2020 um 19:49:34 Uhr
Goto Top
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.
Mitglied: Windows10Gegner
Windows10Gegner 11.08.2020 um 20:12:08 Uhr
Goto Top
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
Mitglied: LordGurke
LordGurke 16.08.2020 um 21:30:29 Uhr
Goto Top
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.
Mitglied: Windows10Gegner
Windows10Gegner 16.08.2020 um 21:51:15 Uhr
Goto Top
Bei HE selbst steht in der Konfigurationsanleitung nichts zur MTU.
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
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.
Mitglied: LordGurke
Lösung LordGurke 16.08.2020 um 21:56:14 Uhr
Goto Top
Du kannst bei HE im Webinterface die MTU für den Tunnel konfigurieren:

he-mtu
Mitglied: Windows10Gegner
Windows10Gegner 16.08.2020 um 22:04:27 Uhr
Goto Top
Auf 1472 gestellt im Webinterface und nun funktioniert es.

Beim anderen Tunnel (gleicher Provider, FB7490) steht es auf 1480 und es tut problemlos.
Mitglied: aqui
aqui 17.08.2020 aktualisiert um 09:02:16 Uhr
Goto Top
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 ...