Hohe Zugriffszeiten über VPN im Home-Office

[cartridge_case]

mit aktiver VPN habe ich es nicht gemssen

Warum denn dieses? Das wäre doch das erste, was man macht. o.O

Das hat mir schon gereicht.

Na so läuft das aber nicht. :-/

Die MTU wird es sein.

Und dann ist nur ein Anwender betroffen? Das wäre krass.

 

[CubeID]

Und dann ist nur ein Anwender betroffen? Das wäre krass.

Yep, muss auf jeden Gerät einzeln gemacht werden.
Geht glaube ich auch mit Registryeinträgen, mit den Befehlen in der CMD ist man bei Einzelfällen erstmal schneller.

 

[cartridge_case]

Yep, muss auf jeden Gerät einzeln gemacht werden.

Also durch Zufall gibt es bei allen anderen Mitarbeitern und deren Providern kein Problem? Okay, dann ja. Danke für die Aufklärung.

 

[CubeID]

Kommt auf die Anzahl der Mitarbeiter an die Dienste über VPN nutzen, da ist auch nicht jeder Dienst gleichermaßen von betroffen. Und nicht jeder User meldet sich dann direkt, manchen sind da richtig leidensfähig xD meckern darüber dass es schlecht läuft, lassen sich aber auch nicht helfen
Bei uns war das auch eher so ein schleichendes Ding, wo nach und nach (über Jahre) immer mal wieder Leute kamen. Am Ende wurde es dann mal in die Installationsroutine vom VPN Client mit übernehmen, ich glaube per Registry-Einträgen.

 

[cartridge_case]

Am Ende wurde es dann mal in die Installationsroutine vom VPN Client mit übernehmen

Aber ich denke es ist an jedem Anschluss ganz individuell? Dann kann ich doch keinen Wert festlegen. o.O

 

[CubeID]

Mit MTU 1400 hat man von denen die es betrifft 99,8% erschlagen. Bei mir war es glaube ich 1436, bei anderen 1472, bei wieder anderen 1400.
Wenn man eine Bambusleitung hat geht damit natürlich etwas Bandbreite flöten, heutezutage ist der Zugewinn für eine stabile Verbindung bei der alle Dienste sauber funktionieren größer, als das ein Nachkomma-MBit-Geschwindigkeitsgewinn es aufwiegen würde.
Am Ende macht man noch Split-Tunneling, wo nur die Sachen die in die Firma sollen wirklich über diese VPN-Verbindung gehen, und der ganze Internet- und Cloudtraffic geht beim User direkt ins Internet.

 

[Hammelkoppter]

Es könnte, wie bereits erwähnt, an der MTU liegen..Gerade der Vodafone Kabel Anschluss spricht dafür. Habe das bei ein zwei Kunden auch schon erlebt. Die verwenden zum Teil DS-Lite. Ich habe dann die MTU am VPN Backend auf 1300 gesetzt. Somit hast du auch in Zukunft keine Probleme und musst nicht auf einzelnen Clients die Registry verdrehen.

 

[TechGuru711]

Mir ist das mit der MTU noch nicht ganz klar im welchen Zusammenhang das steht. Muss ich das am Client einstellen oder woher weiß ich das die MTU nicht optimal ist?

 

[CubeID]

Ja, das musst am Client eingestellt werden.

Ein Datenpaket hat eine Std-Größe, normal sind das 1500 Byte. Mit Anpassungen und entsprechenden Protokollen kann das auch 9000 Bytes (Jumbo frames) sein, aber die Regel sind 1500 Byte.
Mit DS-Lite machst du eine Übersetzung von IPv4 im lokalen Netz zu IPv6 beim Provider, der je nach Dienst wo es hin soll dann entweder v6 weiter macht oder es ggf. wieder in v4 wandelt.
Da mit der "Umwandlung" von IPv4 auf IPv6 zusätzliche Platz beim Paket für die Infos belegt wird, gibt es 2 Möglichkeiten:
A) Die Paketgröße bei 1500 Byte belassen und die zusätzlichen IPv6 Infos anhängen = Paket größer als 1500 Byte
B) Paketgröße reduzieren, damit es inklusive der IPv6 Daten kleiner oder gleich 1500 Byte ist.
Die 1500 Byte sind die gängige Größe für Datenpakete, womit Option B der präferierte Weg ist.

Von der Umwandlung von v4 nach v6 weiß die VPN-Verbindung aber nix, also schickt sie Datenpakete mit 1500 Byte los, also Option A. Mit Glück kann das Datenpaket auf zwei Pakete aufgeteilt werden, die Gegenstelle setzt es wieder dazusammen und es geht. Oder, die Gegenstelle sagt: Du, das zerhackte Paket aktepziere ich nicht, mach mal ein kleineres Paket und schick nochmal, und es geht auch, jedoch kommt es hier dann zu Verzögerungen, weil es geht merhmals hin und her...
Oder, der schlechteste Fall, es funktioniert direkt garnicht.
Normalerweise könnte die Framegröße dynamisch ausgehandelt werden, das funktioniert aber nicht in allen Fällen.

Ergo, mit dem Ping-Optionen von der Vorseite feststellen wie groß das Paket maximal sein darf bis es zerhackt werden müsste, die MTU-Size für die VPN-Verbindung entsprechend reduzieren, et voila.

 

[TechGuru711]

Teste mal wie groß die Datenpakete sein können, die bei aktivem VPN in Richtung Server in der Firma funktionieren.
CMD:

-f: fragmentiert er das Paket NICHT
-l: Größe vom Datenpaket in Byte, normal macht Ping nur kleine Pakete (z.B. 32Byte)

Wenn beim Ping mit 1500 kommt: Packet needs to be fragmented but DF set
müsste das Datenpaket auf zwei Pakete aufgeteilt werden, was nicht immer so funktioniert wie es soll. Beim Ping mit der Größe runtergehen,

Bei mir kommt hier genau das raus "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt"

Ergänzung (17. Juli 2024)

Ich habe jetzt herausgefunden mithilfe des Tools "Adapter Watch" von NirSoft.

WLAN-Adapter 1500 MTU
Virtueller VPN Ethernet Adapter 1392 MTU

 

[TheCadillacMan]

Bei mir kommt hier genau das raus "Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt"

Das Beispiel von @CubeID stimmt nicht ganz. Zumindest unter Windows ist -l der Payload des ICMP-Pakets. Zu diesem Wert kommt automatisch noch die Längen der ICMP- (8 Bytes) und IP-Header (20 Bytes bei IPv4, 40 bei IPv6) hinzu.

Um eine MTU von 1500 Bytes über IPv4 zu testen muss man also eine Länge von 1472 verwenden:

ping -f -l 1472 X.X.X.X

Dann reduziert man den Wert solange bis die Fehlermeldung nicht mehr erscheint.

Wegen der hohen Verbreitung von PPPoE in Deutschland gehen 1500 Bytes ganz oft nicht. Ich persönlich gehe deshalb immer von einem MTU-Wert von maximal 1492 Bytes aus.

 

[Hammelkoppter]

Ja, das musst am Client eingestellt werden.

Kann man bestimmt machen.
Man sollte es aber am VPN-Server (Firewall, whatever) zentral machen. Dann hast du auch in Zukunft Ruhe und fummelst nicht an jedem Client einzeln rum. Ggf. gibt es schon Clients die vom selben Problem betroffen sind und es nur noch nicht gemeldet haben oder es wird zukünftig Clients treffen durch z.B. Providerwechsel.