Firmen VPN, Fritzbox 7530 AX, Vodafone DS Lite

[Funbold]

Hallo zusammen,

wir haben seit ein paar Wochen Probleme mit unserem Firmen VPN. Es betrifft nur wenige Mitarbeiter und ich versuche mal, das Szenario in meinem persönlichen Fall so umfänglich wie möglich zu beschreiben:

VPN Dienst: Pritunl (OpenVPN Protokoll, UDP)
VPN Client: Pritunl Client, OpenVPN GUI (Verhalten bei bei den Clients gleich)

Privater DSL-Anschluss: Vodafone VDSL 250 mit DS Lite
Privater Router: Fritzbox 7530 AX

Problem: Im VPN funktioniert ping, nslookup und tracert bei diversen Firmenressourcen korrekt - aber bspw. die interne Website dazu kann nicht aufgebaut werden. Der Browser erreicht zwar irgendwie die Adresse, aber dann lädt und lädt er ohne dass etwas passiert.

RDP-Verbindungen klappen mal und mal nicht.

Andere Mitarbeiter haben ebenfalls Fritzboxen (7530 AX und 7590 AX), ob sie auch DS Lite haben, konnte ich bisher noch nicht herausfinden.

Ich habe die Vermutung, dass es irgendwie mit DS Lite zusammenhängt, weiß aber nicht so richtig, wie ich das sicher feststellen kann. Hat jemand eine Idee oder anderen Rat?

Danke!

 

[Novize]

Die meisten VPN-Dienste laufen auch per TCP - versuche mal, darauf umzustellen,.
Ich habe den Verdacht, dass beim UDP einfach unmerklich ab und an Datenpakete abhanden kommen. Gerade bei DSL-Lite ist die Datenverbindung des DSL ja eher als wackelig zu bezeichnen, da werden schon schneller mal defekte / nicht reparierbare Datenpakete eintreffen, dann klappt die Kommunikation nicht mehr. Bei TCP läuft das anders ab, diese verlorenen Pakete werden nachgefordert und sind auch wieder nutzbar
Der Haken: Es wird alles halt ein wenig langsamer, da immer ein ACK-Paket als Antwort erwartet wird, bevor der nächster Schwung auf die Reise geht...

 

[Whoopie]

Kann auch an der MTU/MSS hängen. Ich hab bei mir in der Konfiguration auf Server-Seite "mssfix 1300".

 

[PeterPawn]

Auch für mich ein MTU-Problem ... Dienste mit kurzen Paketen funktionieren weiterhin, während diejenigen, die längere Pakete verwenden, nur sehr unregelmäßig arbeiten, weil Pakete ab einer bestimmten Länge noch einmal zusätzlich fragmentiert werden müßten, was bei VPN-Verbindungen aber nicht funktioniert, da dann die Integrität der enthaltenen Daten nicht länger "gesichert" ist.

Je nach verwendter Art der IP-Adressierung (IPv4 vs. IPv6) wird die nutzbare Datenmenge in einem Paket immer kleiner ... IPv6 benötigt auch dann schon deutlich mehr Daten im Paket-Header (nämlich 40 Byte ggü. 20 Byte bei IPv4), wenn es KEINE zusätzliche "Verpackung" für IPv4-Pakete geben sollte. Wird aber bei einem DS-Lite-Anschluß dann auch noch ein IPv4-Ziel "adressiert", dann kommen da noch weitere Daten für die Steuerung hinzu, denn dann müssen die IPv4-Pakete noch einmal zusätzlich in IPv6-Paketen gekapselt werden, die vom CPE an den AFTR (Address Family Translation Router) beim Anbieter gesendet werden.

Obendrauf kommt dann bei VPN-Lösungen jeweils noch der eigene Overhead (an zu übertragenden Steuerinformationen) für dieses VPN ... und wenn dann die automatische Ermittlung der max. möglichen Paketlänge nicht richtig funktioniert (was gerade bei VPN gerne mal vorkommt), dann kommt es zu solchen Phänomenen.

Bei OpenVPN kann man als Hausnummer auch mal mit einer MTU von 1300 starten (m.E. aber nicht zwingend per mssfix-Option), wobei die tatsächlich nutzbare Datenmenge pro Paket eben von mehreren Faktoren abhängig ist - siehe mein Versuch der Erläuterung, warum IPv4-Ziele bei einem ("echten") DS-Lite-Anschluß den meisten Overhead verursachen. Wieviel man dort also tatsächlich ansetzen muß (eine zu kleine MTU-Size verringert natürlich den möglichen Durchsatz insgesamt), kann man aber auch austesten - Stichwort ICMP-Pakete (also ping) mit gesetztem "don't fragment"-Bit und natürlich eine funktionierende Infrastruktur, bei der auch ICMP-Pakete als Antworten zuverlässig ans Ziel gelangen (einfach mal eine Suche im Internet starten). Bei IPv6 ist das ohnehin "Pflicht" ... da wird nicht mehr in irgendeinem Router fragmentiert und wenn Pakete für die Übertragung zu groß sind, werden sie einfach (mit entsprechender Nachricht an den Absender) verworfen.

Da solche Pakete dann natürlich NICHT in den verschlüsselten Datenstrom einer VPN-Verbindung passen (und quasi als "Fremdkörper" angesehen werden, was sie am Ende ja auch sind), funktioniert dieser Mechanismus eben bei VPN-Lösungen häufig nicht ... dazu müßte die VPN-Software deutlich weiter "vorne" (bzw. "unten", spätestens auf L3 im OSI-Modell) im Network-Stack des OS ansetzen, damit sie auch über Probleme mit zu großen Paketen informiert wird.

Gerade OpenVPN bietet aber eine Vielzahl an Einstellungen, mit denen man diese Parameter einer Verbindung beeinflussen kann ... daher sollte man (wenn man sich damit befassen muß) wenigstens einmal in seinem Leben einen Blick in das Handbuch zu OpenVPN (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/) geworfen haben, BEVOR man da in blindes Probieren verfällt. Speziell ein Verständnis, wie tun-mtu, fragment und mssfix zusammenwirken, wäre (nach meiner Erfahrung) nützlich ... und auch ein (vorübergehend gesetztes) mtu-test kann nützlich sein, wenn man die Protokollierung entsprechend hochdreht. Das meiste davon kann man auch an einem Client einstellen bzw. testen, denn bei einer Enterprise-Lösung sollte man - sofern eben nicht ALLE Clients betroffen sind - sich sicherlich eher auf eine clientseitige Lösung der Probleme kaprizieren, als auf eine serverseitige Änderung.

BTW ... auch bei OpenVPN über UDP-Pakete wird von der VPN-Software für die Daten im Tunnel (egal, ob diese selbst TCP, UDP oder irgendwas anderes enthalten, solange es IP-Pakete sind) eine Sicherungsschicht eingezogen, so daß Paketverluste tatsächlich bemerkt werden ... nur bringt eben eine wiederholte Übertragung dieser Pakete auch nichts, solange sie ihr Ziel gar nicht erreichen KÖNNEN (zumindest nicht unfragmentiert, was dann aber wieder die Integrität nicht mehr garantieren kann).

 

[Funbold]

Hallo zusammen,
danke für eure Antworten.

@Novize
das könnte ich mal probieren, allerdings müsste ich dafür eine passende Zeit finden, weil wir keinen "Testing"-Server haben.

@Whoopie @PeterPawn
kann ich das mit "mssfix 1300" einfach mal ausprobieren oder muss man da vorsichtig sein? Ich kenne mich da leider so gar nicht aus.

Ich konnte bisher noch herausfinden, dass auch ein anderer betroffener Mitarbeiter DS Lite bei Vodafone hat. Bei den zwei weiteren betroffenen Mitarbeiterinnen versuche ich noch, es in Erfahrung zu bringen.

 

[Whoopie]

Ja, kannst du.

 

[NDiIPP]

@Novize
das könnte ich mal probieren, […]

Würde ich aber erst einmal sein lassen. Denn auch für mich sieht das eher nach einem MTU-Problem aus und nicht nach einem UDP-Problem.

 

[Novize]

Würde ich aber erst einmal sein lassen

Das ist oft mit einem Klick getestet - daher: Warum nicht?
Ich hatte mal in 2 Anlagen je einen Fernwartungsrouter (hinter dem DSL-Router), denen ich trotz reduzierter MTU kein stabiles VPN beibringen konnte - allesamt hinter DSL-Lite-Anschlüssen. Einzig der Umstieg dieser Router auf TCP brachte Abhilfe. Die PCs direkt am DSL-Router (MTU nicht geändert) hatten ebenfalls Probleme:
Diese waren per Teamviewer via UDP erreichbar, doch die Verbindung brach immer wieder ab. Ein Umstieg auf TCP brachte auch da Stabilität rein.
Also ein Versuch ist es zumindest wert, schaden tut's meines Erachtens nach nicht

Anders herum gefragt: Wenn Datenpakete per UDP zu groß sind, warum passt das dann bei TCP? Außer dem Transportprotokoll hatte ich nachweislich nichts geändert.

 

[frank_m24]

Ich hab schon länger den Verdacht, dass es Internetanschlüsse gibt, die Probleme mit UDP Paketverlusten haben, obwohl sie ansonsten unauffällig sind. "Gefühlt" kommt es bei Kabelanschlüssen besonders häufig vor, aber dafür gibt es keinerlei objektiven Beleg. Ich weiß nicht, ob es was mit DS-Lite zu tun hat, könnte aber sein. Das gibt es ja durchaus öfter mal an Kabelanschlüssen. Testen kann man es mit iperf3, wenn man eine passende Gegenstelle hat. Auch bei recht geringen Bandbreiten (2-3 MBit/s) im Test kommt es zu messbaren Verlusten.

 

[NDiIPP]

Das ist oft mit einem Klick getestet - daher: Warum nicht?

Dies erfordert (zusätzlich zur Clientkonfiguration) einerseits eine Anpassung der OpenVPN-Serverkonfiguration und andererseits evtl. auch noch der involvierten Firewall/Router (Portfreigabe für TCP). Währenddessen auf ein MTU-Problem allein mit der Client-Config getestet werden könnte. Von daher würde ich hier mit dem naheliegendsten und einfachsten anfangen. Zudem kommt noch der in #4 (letzter Absatz) erwähnte Umstand bei OpenVPN…

 

[Novize]

Dies erfordert (zusätzlich zur Clientkonfiguration) einerseits eine Anpassung der OpenVPN-Serverkonfiguration und andererseits evtl. auch noch der involvierten Firewall/Router (Portfreigabe für TCP)

I.d.R. nur der Serverkonfig, denn diese wird separat pro Client angepasst. Die Clients können zumindest bei dem von mir administrierten OpenVPN-Netz (mit aktuell 68 Clients) beides und probieren beim Misserfolg von UDP als Fallback das andere Transportprotokoll (TCP). Daher schrieb ich ja von einem Klick. Vor dem VPN-Router ist i.d.R. ausgehend sehr viel erlaubt, quasi nichts verboten - warum auch, da der VPN-Router schon alles blockt und ins private Netz umlenkt, nichts frei raus lässt und somit eine weitere Firewall vor der VPN-Firewall obsolet ist. So kenne ich das von großen weltweit identisch administrierten Firmennetzen von Heidelberger, Holcim, Geiger, Vogel-Bau, Bergerbau, Strabag usw...
Daher ist das (meist?) auch nur ein Klick in der Serverconfig, der Client fliegt raus, verbindet sich neu und fertig oder er verbindet sich nicht neu und man stellt das einfach zurück und der Client meldet sich brav wieder an, wie nach jedem Reconnect des DSL. Fliegt der Client raus wegen dort umgestellter Netzwerk-Config, und der kommt nicht wieder, hat man aus Admin-Sicht halt den Ast, auf dem man sitzt (die Netzwerkconfig) abgesägt und somit erfolgreich einen Außen-Einsatz gebucht
Ich will eine eventuelle MTU-Problematik ja nicht in Abrede stellen, das ist ja ebenfalls ein zu untersuchender Ansatz. Du aber formulierst meinen einfachen Test aber als "lass besser sein". Das ist es, was mich irritiert.

Zudem kommt noch der in #4 (letzter Absatz) erwähnte Umstand bei OpenVPN…

Auf die von mir gestellte Frage hast Du keine Antwort? Denn der erwähnte Absatz in #4 beantwortet das eben nicht.

 

[Funbold]

Ich werde kommenden Freitag mal die Sache mit mssfix 1300 ausprobieren, da sollte niemand außer mir verbunden sein und ich kann in Ruhe testen und ggf. auch mal den Server neustarten etc.

Sollte das nichts bringen, würde ich die Umstellung auf TCP zumindest mal testen. Problem ist hierbei, dass wir keinen dedizierten Test-Server haben und einige Leute von den Änderungen betroffen wären. Außerdem müsste ich wie @NDiIPP schon erwähnt hat diverse Anpassungen in unseren Firewalls tätigen, da ist (soweit ich das beurteilen kann) nur UDP für die VPN-Verbindungen freigegeben. Das ist zwar keine riesige Hürde, aber möchte ich trotzdem nicht einfach mal so machen.

Danke an alle, die sich damit beschäftigen

EDIT: Mittlerweile ist sicher, dass mindestens 3/4 betroffenen Mitarbeitern DS Lite verwenden. Zwei IT-Mitarbeiter, bei denen es funktioniert, haben kein DS Lite.

 

[PeterPawn]

Auf die von mir gestellte Frage hast Du keine Antwort?

Ich hielt das meinerseits nur für eine rein rhetorische Frage ... denn niemand kann/wird in Abrede stellen wollen, daß es durchaus MEHRERE Ursachen für VPN-Probleme geben kann.

Sollte tatsächlich irgendwo in einem Netzsegment soviel Traffic zusammenkommen, daß beteiligte Router sich veranlaßt sehen, UDP-Pakete (spezifikationsgemäß!!!) zu verwerfen (was aber heute auch nur noch wirklich sehr selten auftritt nach meinen Erfahrungen - und dann handelt es sich meist um temporäre(!) Probleme in einem Segment), dann dürfte sich das ja auch auf ALLE Pakete auswirken und nicht abhängig von der Paketgröße sein. Hier wurde aber berichtet, daß typische Dienste, die mit eher kleinen Datenmengen arbeiten, problemlos funktionieren würden - was für mich darauf hindeutet, daß es eben KEINE Congestion-Probleme generell gibt (denn auch die kurzen Datenpakete werden ja vom OpenVPN in eigene UDP-Pakete verpackt) und dann schiebt sich eben sofort wieder die Vermutung, daß es sich um falsch berechnete Größen für den Payload handelt, in den Vordergrund.

Ich würde jedenfalls erst mal mit dem wahrscheinlichsten Problem beginnen bei einer eigenen Suche ... eine Überlast in verschiedenen Netzsegmenten, die auch noch für mehrere (aber eben auch nicht alle) Benutzer zu reproduzierbaren Problemen führt, ist in meinen Augen jedenfalls einigermaßen unwahrscheinlich. Das ließe ich vielleicht noch für 2-3 Clients gelten, sofern die auch noch bei demselben Provider sind und sich diese Probleme eher spontan manifestieren (denn permanente Überlast ist ja auch eher unwahrscheinlich) ... ich lese die Problembeschreibung in #1 jedenfalls auch nicht so.

Und ein (eher generelles) Problem bei der Anbindung des eigenen VPN-Servers würde sich sicherlich auch wieder nicht nur auf wenige Clients auswirken - auch das sehe ich daher nicht als die wahrscheinlichste Ursache an. Ein Zusammenhang mit DS-Lite-Anschlüssen wurde hingegen schon vom TO "vermutet" ... auch wenn er die dabei deutlich verringerten Paketgrößen (hinsichtlich der "Nutzlast") als (für mich nun mal wahrscheinlichste) Ursache selbst noch nicht (er)kannte.

Auch die Tatsache, daß bestimmte Dienste (hier berichtet für RDP) mal funktionieren und mal nicht, hat (für mich) nichts mit "spontanen" Fehlern zu tun ... je nach Geschwindigkeit und Umfang von Änderungen an Bildschirminhalten schwanken die zu übertragenden Datenmengen erheblich. Anders als andere Lösungen (TeamViewer, VNC, etc.) wird bei RDP-Sessions eben NICHT der Grafikpuffer des entfernten Clients gepackt und komplett übertragen - stattdessen werden die "Zeichenkommandos" der Programme an den Grafiktreiber etwas vereinfacht und dann zum RDP-Client übertragen, der sie dann seinerseits an der eigenen Kopie des (entfernten) Bildschirminhalts ausführt, bevor er diese Kopie zur Anzeige bringt.

---

EDIT:

Ich werde kommenden Freitag mal die Sache mit mssfix 1300 ausprobieren

Bis Freitag ist ja noch etwas Zeit ... vielleicht liest Du Dir ja auch mal die von mir weiter oben verlinkte Dokumentation zum OpenVPN und dessen Optionen durch, bevor Du anfängst, (nur) mit mssfix herumzuexperimentieren.

 

[Novize]

Ich hielt das meinerseits nur für eine rein rhetorische Frage

In dem Fall wirkliches Interesse.

Sollte tatsächlich irgendwo in einem Netzsegment soviel Traffic zusammenkommen, daß beteiligte Router sich veranlaßt sehen, UDP-Pakete (spezifikationsgemäß!!!) zu verwerfen (was aber heute auch nur noch wirklich sehr selten auftritt nach meinen Erfahrungen - und dann handelt es sich meist um temporäre(!) Probleme in einem Segment)

Meine Betrachtung zielte eher auf den Teil DSL-Strecke: Wenn diese nur noch als DSL-Light ausgeführt werden kann, dann wird das eh schon einiges im kritischen Bereich laufen und die Gefahr, dass da Datenpakete unwiderruflich zerstört sind, ist höher, als z.B. bei einem perfekt laufenden DSL100-Anschluss. Leider habe ich bei den beiden betroffenen Kunden keinen Zugriff auf den DSL-Router, um mal auf die CRC-Counter zu schauen. Den Part im Backbone des Providers usw sehe ich hier auch als weniger kritisch.

Auch die Tatsache, daß bestimmte Dienste (hier berichtet für RDP) mal funktionieren und mal nicht, hat (für mich) nichts mit "spontanen" Fehlern zu tun ... je nach Geschwindigkeit und Umfang von Änderungen an Bildschirminhalten schwanken die zu übertragenden Datenmengen erheblich

Gerade da sehe ich eher viele kleine Datenpakete, denn, wie du ja auch schriebst, bestehen die Daten ja zu großen Teilen nur aus den Vektoranweisungen an den Bildschirmtreiber, was i.d.R. mit paar Bytes pro Anweisung erledigt ist. Erst ständig neu dargestellte Bitmaps vergrößern die Datenmengen, werden meines Wissen nach aber auch komprimiert übertragen.

Sei's drum, schauen wir mal, was sich beim TE ergibt...

 

[NDiIPP]

Du aber formulierst meinen einfachen Test aber als "lass besser sein". Das ist es, was mich irritiert.

Die MTU-Problematik ist aufgrund der Problembeschreibung 1. die wahrscheinlichere Ursache und 2. auch einfacher auszuschließen (quasi mit "0 Klicks" bzgl. Serverkonfiguration, da ist dein "ein Klick" bei der Serverkonfiguration schon zu viel). Und "lass besser sein" hatte ich nicht geschrieben sondern ich schrieb "erst einmal sein lassen"! Und auch mein vorletzter Satz in #10 endete mit "… anfangen". Irritiert mich daher schon, dass du das scheinbar überlesen hast. Wenn es anschließend immer noch Probleme gibt, kann man ja gerne der UDP-Theorie nachgehen. Aber m.E. eben erst dann…

Auf die von mir gestellte Frage hast Du keine Antwort?

Wenn ich das richtig verstanden habe, bezog sich das nicht auf das Problem des TO. Auch ich habe (bisher) UDP-Probleme nicht ausgeschlossen (das will und kann ich schließlich nicht)*, sie scheinen mir bisher nur unwahrscheinlicher zu sein. Mir stellte sich nach dem lesen deiner Frage in #8 eher eine andere Frage: Woher weißt du, dass das umstellen auf TCP auch beim TO das Problem löst?

Edit:
*)
Auch ich hatte in der Vergangenheit schon mit UDP-Problemen zu tun aber die äußerten sich stets anders als beim TO.

 

[Funbold]

Hallo zusammen,

ich habe am vergangenen Freitag die MTU auf 1300 begrenzt, anschließend funktioniertes es (zumindest bei mir) wieder so wie früher. Vielen Dank an dieser Stelle!

Ich warte mal ab, ob die anderen betroffenen Mitarbeiter ebenfalls Positives berichten können.