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:

  • DNS-Server
    Welche DNS-Server nutzt denn der Client? Bei VPN-Konfiguration hat der Client nämlich einmal die DNS-Server der aktiven Netzwerkkarte. Im Homeoffice ist das meist der DSL-Router, der sich als DNS-Server per DHCP anbietet. Der VPN-Adapter bekommt aber mit dem Verbindungsaufbau ebenfalls DNS-Server der Firma.
    Der Client muss nun überlegen, welche DNS-Server er wofür nutzt. Dies ist insbesondere wichtig, wenn Sie im LAN und Internet die gleichen Domain-Namen verwenden. Eine Adresse wie "intranet.msxfaq.de" kann über den DNS-Server des Providers auf eine öffentliche Adresse verweisen aber über den DNS-Server des VPN auf eine private Adresse.
    Mit passender Konfiguration wird bei einem VPN immer der Server in der Firma gefragt, der aber dann auch fremde externe Namen für Split-VPN auflösen muss.
  • Split-DNS, NRTP
    Um die Namensauflösung zu optimieren, können Sie in Windows mit NRTP (Name Resolution Policy Table) arbeiten und z.B. bestimmte Domainnamen auf abweichende DNS-Server routen. Das ist ideal für ein Split-VPN, wenn Sie so ihre intern genutzten Namen auf die internen DNS-Server schicken und alle andere Namen durch den Provider vor Ort auflösen lassen.
    Prüfen Sie in dem Zuge auch die Kosten und Reihenfolge, nicht dass ihr Client sowohl die privaten VPN-DNS-Server als auch die öffentlichen DNS-Server parallel nutzt und damit Namen nur manchmal korrekt aufgelöst werden. Sind wirklich alle internen DNS-Zonen üper NRPT auf die internen Server geroutet?
  • NSLOOKUP vs. Ping
    Die einen Administratoren starten einfach einen "ping <name>" um die IP-Adresse zu ermitteln während andere Administratoren mit NSLOOKUP, DIG oder "Resolve-DNSName" arbeiten. Die Ergebnisse sind hierbei nicht zwingend gleich, denn NSLOOKUP umgeht die NRTP-Konfiguration und lokale HOSTS-Dateien, weil es direkt mit einem der DNS-Server spricht. Das Ergebnis ist also nicht immer korrekt.
  • IPv4/IPv6
    Immer mehr Anschlüsse haben mittlerweile IPv6-Adressen und Routing. Windows nutzt bevorzugt IPv6. In dem Fall gab es aber kein internes IP-6-Deployent, das VPN konnte auch kein IPv6 und die öffentlichen Server waren auch nur per IPv4 im DNS eingetragen. Diesmal mussten wir nicht auch noch auf diesen Aspekt Rücksicht nehmen und konnten und voll auf IPv4 beschränken.

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.

  • Gateway und Leitwege
    Wir haben uns die Default Gateways und die Leitwege angeschaut. Die VPN-Verbindung hatte kein Default Gateway aber statische Routen für die internen Netzwerke. Das ist eine gültige Konfiguration für ein Split-VPN für Routing.
  • IPv4/IPv6
    Bei der DNS-Analyse haben wir schon ermittelt, dass der Client im Homeoffice zwar IPv6-Native konnte aber weder VPN noch interne Server noch öffentliche Server des Kunden per IPv6 auflösbar oder erreichbar waren.
  • WLAN Signal
    In dem Zuge haben wir auch schnell das lokale LAN überprüft, indem wie die WLAN-Signalstärke betrachtet und per Dauerping die Erreichbarkeit des Default Gateway überprüft haben. Hier gab es keine Auffälligkeiten.
  • Firewall/Filter
    Natürlich kann immer noch eine Firewall auf dem Übertragungsweg oder auf dem Server abhängig von der Source-IP eine Verbindung blockieren. Ich wünsche mir ja, dass in dem Fall die Firewall auch einen "ICMP not Reachable" sendet und nicht einfach die Paket heimlich verwirft. Im ersten Fall bekommen wir dann quasi sofort eine Rückmeldung. Wenn der Verbindungsversicht aber viele Sekunden dauert, dann dürfte es eher um Paketverluste gehen

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:
https://learn.microsoft.com/de-de/troubleshoot/windows-client/networking/change-default-mtu-size-for-ppp-vpn-connection#summary

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

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:

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