Hybrid Router, LTEBoost, MTU, VPN, Speedport
Bei "Hybrid" denken alle Microsoft Administratoren wohl erst einmal an Exchange Hybrid mit Microsoft 365. Aber ein sehr befremdliches Verhalten eines VPN-Client im Homeoffice eines Benutzers hat wohl mit Speedport Pro Hybrid Router der Telekom mit einem LTE-Boot-Tarif betroffen. Das VPN hat nicht stabil funktioniert und es betraf nur alle Homeoffice-Mitarbeiter mit genau diesem Setup.
Das Problem
Wie so oft sind es die "besonderen" Probleme, die dann wieder auf meinem Tisch landen. Der Anwender im Homeoffice hat sich teils über schlechte Performance, langsame Verbindungsaufbauen, Anmeldefenster und sonstige Probleme beschwert. Technisch war das Setup eigentlich einfach, denn ein Homeoffice-PC, der sich per WLAN an einem DSL-Router verbindet und über das Internet eine IPSec-VPN-Tunnel zum Firmennetzwerk aufbaut, ist nun wirklich keine Raketentechnik. Da auch eine Cloud-Nutzung erforderlich war, wurde ein Split-VPN konfiguriert.
Mittels Microsoft Teams haben wir ein Meeting aufgesetzt, in dem auch der Mitarbeiter seinen Bildschirm geteilt hat. Das hat mit einigen Teams-typischen Rucklern gut funktioniert. Schon so war eigentlich klar, dass die Bandbreite und Laufzeit nicht wirklich ein Problem haben kann. Aber wir konnten zusehen, wie träge das System war und dass viele per VPN erreichbare internen Dienste nicht oder nur sehr langsam genutzt werden konnten. Wobei "Langsam" schon Verzögerungen von mehrere Sekunden bis wenige Minuten bedeutet haben.
Sobald sich aber der Computer über einen IPhone-Hotspot verbunden hat, was die Verbindung zur Firma immer problemlos und performant. So einen Gegenprobe lässt ja quasi nur eine Analyse beim WLAN, dem DSL-Router oder dem Provider zu. An der grundlegenden Konfiguration des VPN-Client und erst recht des VPN-Servers hat sich dann ja nichts geändert. Zudem betraf es nur bestimmte und immer die gleichen Anwender, während andere Mitarbeiter mit identischer VPN-Konfiguration, Gruppenrichtlinien und Firmen-Notebook kein Problem hatten.
Die Frage war nur: Wo ist der Knoten, den es zu zerschlagen gilt.
Analyse
Wenn eine Verbindung zu einem Service nicht oder nur sehr langsam möglich ist, dann gibt es drei Dinge zu prüfen:
Kriterium | Überprüfung | Status |
---|---|---|
Namensauflösung |
Die wenigsten Systeme nutzen heute statische IP-Adressen, sondern fragen per DNS nach der gültigen IP-Adresse für einen Namen. Hier gibt es mehrere Dinge zu beachten:
Als wir uns auf den PC verbunden haben, lieferte ein PING auf einen internen Namen keine IP-Adresse oder die öffentliche Adresse. Per IPCONFIG sahen wir, dass der VPN-Adapter gar keine DNS-Server konfiguriert hatte. Die NRTP-Einträge waren aber da. Damit war zumindest klar, warum der Client weder die Domain Controller noch andere internen Server auflösen und keine Kerberos-Tickets bekommen konnte. Wir hatten uns schon gefreut aber dann hätten alle anderen Clients auch das Problem gehabt. Der Anwender hat dann das VPN beendet und neu aufgebaut und diesmal waren die DNS-Server vorhanden und die Namensauflösung war auch korrekt. Die Analyse ging weiter. |
|
Routing/Erreichbarkeit |
Der zweite Baustein ist das IP-Routing.
In dem Troubleshooting ganz es keine schnelle Rückmeldung, sondern wir hatten Sanduhren und blockierte Fenster. Entweder gehen die Pakete den falschen Weg, sprechen die falsche IP-Adresse an oder werden auf dem Hin oder Rückweg verschluckt. |
|
Latenz/Bandbreite |
Zuletzt bleibt noch die Verbindung vom VPN-Client zum VPN-Server und durch den VPN-Knoten hindurch zu den internen Servern. Hier kann ich nur hoffen, dass Netzwerkadministratoren und Security-Verantwortlich das "Schadpotential" von PING, Traceroute und ICMP nicht falsch einschätzen. Ein VPN-Server hat ganz andere Herausforderungen, als auch PING nicht zu antworten. PING oder ICMP zu blocken verhindert keine DoS-Atttacken aber blockiert jede einfache Analyse durch einen Anwender Mittels Dauerping und Traceroute kann eben DNS auch der Weg zu den Servern und die Laufzeit (Round Trip Time) geprüft werden. Es ist aber keine Überprüfung, ob der Service selbst erreichbar ist. Nur weil ein Server auf einen PING antwortet, kann eine Firewall durchaus die anderen Ports und Protokolle blockieren. Ein TELNET oder Test-NetConnection auf die gewünschten Ports ist der zweite Test. |
Aber auch hier haben die einfachen Tests erst einmal keinen Befund geliefert.
Paketverlust und MTU
Bislang wissen wir, dass es nicht an der Namensauflösung liegt und auch das IP-Routing korrekt zu sein scheint. Einfache PING-Pakete kommen bei der Gegenseite an aber Verbindungen kommen nicht oder nach sehr langer Zeit zustande und sind nicht stabil. Bei diesem Fall kam erschwerend hinzu, dass ich kein Administrator auf dem Client war und eine Endpoint Protection Lösung auch den Start fremder Programme verhindert hat. Sonst hätte ich mal schnell WireShark installiert und der physikalischen Netzwerkkarte als auch der VPN-Verbindung auf die Finger geschaut, welche Pakete hier in welcher Richtung unterwegs sind und wie die Antworten darauf aussehen. Das war aber leider ebenso wenig möglich, wie eine Spiegelung eines Orts oder ein Mitschnitt auf dem Router. Eine Analyse auf der Seite des Servers oder der Firewall war ebenfalls mangels Berechtigungen nicht möglich.
Also haben wir mal noch mal die aktuellen Erkenntnisse zusammengefügt und haben einen Punkt gefunden, den wir noch nicht geprüft haben: Ein ICMP-Ping funktioniert aber nutzt nur 64 Byte großen Pakete. Was passiert, wenn wir große Pakete senden und eine Fragmentierung auf der Leitung verbieten? Windows hat auf seinem Adapter eine entsprechende Einstellung:
„Windows Server 2003, Windows 2000 und Windows XP verwenden
eine feste MTU-Größe von 1500 Bytes für alle PPP-Verbindungen und eine feste
MTU-Größe von 1400 Bytes für alle VPN-Verbindungen. Dies ist die
Standardeinstellung für PPP-Clients, für VPN-Clients, für PPP-Server oder für
VPN-Server, auf denen Routing und Remotezugriff ausgeführt werden.“
Quelle:
Das können wir einfach nachprüfen:
Es wäre nicht das erste mal, dass die MTU-Größe von Paketen überschnitten wird und die Router nicht fragmentieren oder das "ICMP Fragmentation needed"-Paket von einer Firewall verworfen wird. Übrigens fordert und startet IPv6 mit einer MTU-Size von 1280 Bytes, erlaubt keine "Fragmentierung" und nutzt größere MTUs nur bei erfolgreichem MTU-Discovery.
Werden die ICMP-Typ-3-Code-4- bzw. ICMPv6-Typ-2-Pakete an
einem Punkt des Pfades gefiltert, zum Beispiel durch ein
einfaches „ICMP deny“ auf einer Firewall, kann es zu
Übertragungsproblemen kommen, wie im Artikel Maximum
Transmission Unit beschrieben.
Quelle: Path MTU Discovery
https://de.wikipedia.org/wiki/Path_MTU_Discovery
- ICMP
https://de.wikipedia.org/wiki/Internet_Control_Message_Protocol - Path MTU Discovery
https://de.wikipedia.org/wiki/Path_MTU_Discovery - # ICMPv6-Typ-2 Packet to big
https://de.wikipedia.org/wiki/ICMPv6#Packet_Too_Big_%E2%80%93_Type_2
Da der VPN-Server hier keine IPv6-Adresse hat, musste der Client die Verbindung über IPv4 aufbauen, was die Analyse etwas vereinfacht. Wir haben dann per einfachem "PING" mit unterschiedlichen Paketgrößen geschaut, wie sich das Gesamtsystem verhält und interessante Details entdeckt. Wir haben uns den VPN-Server als Gegenstelle ausgesucht und mit unterschiedlichen Paketgrößen belastet.
ping <vpnserver.kundendomain.tld> -l <mtusize> -f
Die Spalte "Speedport" ist der Problemclient und die Spalte "Fritz!Box" ein anderer Client ohne die Probleme. Die MTU-Size haben wir angepasst
Gegenstelle | MTU-Size | Ergebnis Speedport Pro | Ergebnis Fritz!Box |
---|---|---|---|
VPN-Server |
64-1464 |
OK |
OK |
VPN-Server |
1465-1472 |
No Reply |
OK |
VPN-Server |
1473 |
Fragmentation Needed |
Fragmentation Needed |
Bei einer MTU-Sitze zwischen 1465 und 1472 Bytes wurden die ICMP-Pakete nicht übertragen und beantwortet. Die Frage ist nun, ob es auf dem Hinweg oder dem Rückweg passiert.
Hier kann uns der Google-DNS-Server auf der IP-Adresse 8.8.8.8 weiterhelfen, an den wir einen PING mit 1472 Bytes senden.
Der Google DNS-Service sendet aber nicht mein komplettes Paket sondern nur 68 Bytes zurück. Das interpretiere ich so, dass Pakete bis zu zu 1472 Bytes aus dem Homeoffice sehr wohl ins Internet übertragen werden und ich davon ausgehen, dass die Pakete auch in Richtung des VPN-Servers ankommen. Das bedeutet dann, dass der Verlust auf dem Rückweg erfolgt.
Auf Maximum Transmission Unit (MTU) und Fragmentierung habe ich beschrieben, dass die MTU-Size in jede Richtung getrennt ermittelt wird. Das Paket kann also mit 1472 Bytes beim VPN-Server ankommen und seine Antwort geht auch zurück. Der VPN-Server hat sehr wahrscheinlich eine Ethernet-Karte mit einer MTU=1500 Bytes. Nur auf dem Weg zurück kann es natürlich eine Stelle geben, die eine kleinere MTU fordert und hoffentlich einen "ICMP Frgmentation Needed" generiert, der vom VPN-Server dann auch interpretiert werden sollte.
Leider hatte ich noch keine Möglichkeit zu prüfen, ob beim VPN-Server wirklich diese ICMP-Pakete von einer Relay-Station ankommen.
Aber vielleicht ist die Problemstelle ja auch der Router. Der Weg zwischen Homeoffice und VPN-Server sieht stark vereinfacht wie folgt aus:
Sie müssen gar nicht genau hinschauen, um hier einen Sonderfall zu klassischen Anbindungen eines Homeoffice zu erkennen: Der Router ist ein "Speedport Pro" Router mit einer Hybrid-Anbindung. Der Router nutzt sowohl die DSL-Verbindung, die an diesem Standort grade mal 12-13 Megabit Down und 2Megabt Upload bietet. Das ist natürlich weit von DSL50 oder DSL100 entfernt, so dass die Telekom im Router auch noch eine LTE-Karte verbaut hat, die "bis zu 300 Megabit on top" liefern soll.
...In erster Linie wird immer zuerst die Festnetzleitung genutzt, da sich diesen
Anteil nicht alle Nutzer in Deiner Umgebung miteinander teilen müssen. Wenn
Deine Gegenstelle im Internet aber mehr Speed anbietet, als Dein Festnetz
abnehmen kann, wird automatisch der Mobilfunk-Turbo zugeschaltet. Brauchst Du
mehr - bekommst Du mehr. Je nachdem wie viel in Deiner Mobilfunkzelle los ist,
bekommst Du dann bis zu 300 Mbit/s über die Hybrid-Option on top...
https://www.telekom.com/de/medien/medieninformationen/detail/hybrid-lte-option-der-mobilfunk-turbo-fuers-festnetz-604556
Der Router baut also zwei logische Verbindungen auf und bündelt diese auf der Eingangsseite. Wenn eingehend mehr Daten ankommen, als über die DSL-Leitung zum Kunden gesendet werden können und ie Funkzelle entsprechend raum hat, dann sollen die Pakete über den LTE-Tunnel zum Kunden gesendet werden. Das kann natürlich eine wackelige Geschichte sein, wenn die LTE-Verbindung eine andere, insbesondere kleinere, MTU-Paketgröße erlaubt oder die Pakete aufgrund doch nicht so stabilen LTE-Verbindung verloren gehen-
Leider kenne ich keinen Weg, diese Qualität auf Seiten der Telekom zum Kunden zu analysieren oder abzufragen.
Es kann wohl durchaus sein, dass ein Paket über die DSL-Leitung gesendet aber über die LTE- Leitung wieder ankommt oder umgekehrt.
Blick auf Speedport
Wir haben uns dann, in der Hoffnung, dass wir hier vielleicht etwas sehen, per Browser mit dem DSL-Router verbunden. Die Übersicht zeigt, dass sowohl der "DSL Tunnel" als auch der "LTE-Tunnel" aktiv sind:
Leider sind hier noch keine weitere Details zu sehen. Was nun genau "Hybrid-Bonding" ist und wie es funktioniert, habe ich nicht gefunden. Aber eine Internet-Recherche findet umso mehr Treffer zu Hybrid Bonding Problemen und VPN-Problemen:
- Speedport Hybrid OpenVPN Drosselung,
kein OpenVPN über UDP
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Speedport-Hybrid-OpenVPN-Drosselung-kein-OpenVPN-ueber-UDP/m-p/2752212#M815882
Mit Hinweis zu MTU - Kein LTE Bonding bei bestehender VPN
Verbindung
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Kein-LTE-Bonding-bei-bestehender-VPN-Verbindung/td-p/6476247 - VPN mit Hybrid-Anschluss (IPSec)
https://telekomhilft.telekom.de/t5/Festnetz-Internet/VPN-mit-Hybrid-Anschluss-IPSec/td-p/1189219 - VPN Client Probleme seit Wechsel zu
Telekom Hybrid
https://administrator.de/forum/vpn-client-probleme-seit-wechsel-zu-telekom-hybrid-7261304239.html - Speedport Pro Plus: LTE-Boost (Bonding)
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Speedport-Pro-Plus-LTE-Boost-Bonding/td-p/6386708 - VPN möglich mit Hybrid ?
https://telekomhilft.telekom.de/t5/Festnetz-Internet/VPN-moeglich-mit-Hybrid/td-p/4628885 - Hybrid Bonding Workaround gesucht
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Hybrid-Bonding-Workaround-gesucht/td-p/6511606 - Hybrid Bonding / 5G-Emfänger
funktioniert nur wenige Minuten nach
Neustart
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Hybrid-Bonding-5G-Emfaenger-funktioniert-nur-wenige-Minuten-nach/td-p/6573684 - DSL 2000 + Hybrid 5G schlechte Leistung,
Paketverluste, Hoher Ping. Absturtz vom
Router
https://telekomhilft.telekom.de/t5/Festnetz-Internet/DSL-2000-Hybrid-5G-schlechte-Leistung-Paketverluste-Hoher-Ping/m-p/6581391 - Bonding funktioniert scheinbar nicht
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Bonding-funktioniert-scheinbar-nicht/td-p/6084316 - Hybrid 5G Bonding-Problem durch
DSL-Störung (?)
https://telekomhilft.telekom.de/t5/Festnetz-Internet/Hybrid-5G-Bonding-Problem-durch-DSL-Stoerung/td-p/6589629
Um das Problem weiter einzukreisen, habe wir mit den Parametern gespielt und zuerst "LTE verwenden" deaktiviert. Das Ergebnis war aber, dass überhaupt kein VPN-Tunnel mehr aufgebaut werden konnte. Wir haben dann LTE wieder eingeschaltet aber das LTE-Bonding im Unterbereich abgeschaltet
Als Ergebnis hat der Router LTE deaktiviert und nur noch per DSL gearbeitet.
Allerdings hat diese kleine Checkbox eine quasi durchschlagende Wirkung in der Umgebung gehabt. Die VPN-Verbindung wurde rasend schnell aufgebaut und auch die Verbindung zur Firma durch das VPN was schnell und zuverlässig.
Der String "MTU" komm in der gesamten Speedport Pro-Anleitung nur einmal vor, wenn es um die Einrichtung eines alternativen Internet Providers geht.
Quelle:
https://www.telekom.de/hilfe/downloads/bedienungsanleitung-speedport-pro-plus.pdf
Diese Einstellung kann aber sowieso nur die Senderichtung vom Homeoffice zum ISP steuern und den Homeoffice-Client auf kleinere Pakete zwingen.
Zwischenstand
Wir haben den Router erst einmal in dieser Konfiguration belassen und prüfe die nächsten Tage die Zuverlässigkeit. Schade ist, dass der Mitarbeiter im Homeoffice nun auf die "relativ" langsame DSL-Verbindung eingebremst ist.
Wenn die TCP-Verbindung zwischen VPN-Client und VPN-Server korrekt funktioniert, dann sollte auch das VPN keine Probleme haben. In diesem Fall war es keine Fehlkonfiguration des VPN-Servers, des VPN-Clients oder irgendwelche Zertifikate, CRLs, Krypto-Verfahren o.ä. sondern es hat den Anschein, dass auf dem Übertragungsweg etwas komisches passiert, und VPN-Pakete gar nicht, unvollständig oder viel zu spät ankommen und es für den Client schlicht wie eine ganz unzuverlässige Verbindung aussieht.
Der Anwender kann aber alle Cloud-Dienste problemlos nutzen. Wobei die meisten Dienste aktuelle TCP nutzen und der Hybrid-Router und die Telekom durchaus anders reagieren können, als dies bei einem IPSec-basierten VPN über UDP ist.
Vielleicht sollten die Default MTU-Size auf einen "sicheren" Wert, z.B. 1400 oder gar 1280 Bytes (IPv6 Default) festlegen und nur bei funktionierender MTU Discovery auf höhere MTUs wechseln. Und natürlich darf niemand auf dem Übertragungsweg die IMCP-Pakete Typ 3 ignorieren oder blockieren. Ansonsten kann MTU Discovery nicht funktionieren.
Die Untersuchung ist noch nicht
final abgeschlossen.
Frage an die Leser: Hat jemand ähnliche Probleme und diese wie gelöst?
Weitere Link
- WireShark
- Maximum Transmission Unit (MTU) und Fragmentierung
- ChChange the default maximum transmission unit (MTU) size
settings for PPP connections or for VPN connections
https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/change-default-mtu-size-for-ppp-vpn-connection#summary -
SG TCP/IP Analyzer
https://www.speedguide.net/analyzer.php - MTU and Fragmentation Issues in IPsec VPN
https://support.checkpoint.com/results/sk/sk98074 - Technical Note : How to adjust the Maximum Transmission Unit
(MTU) value on a FortiGate interface
https://community.fortinet.com/t5/FortiGate/Technical-Note-How-to-adjust-the-Maximum-Transmission-Unit-MTU/ta-p/192636?externalID=11745 - MTU für Client VPN einstellen
https://www.geekbundle.org/mtu-fuer-client-vpn-einstellen/