AW: Speedport Hybrid OpenVPN Drosselung, kein OpenVPN über UDP

[#1]

Ich habe seit einigen Tagen das Problem, dass die Download Geschwindigkeit bei OpenVPN über TCP am Hybrid Anschluss extrem langsam ist!
Wir sprechen hier von ca. 50 KByte/s.

Eine Verbindung über das OpenVPN UDP Protokoll ist seit ca. Anfang des Jahres gar nicht mehr möglich, vermutlich da die Telekom Hybrid Bonding Server diesen Datenverkehr filtert/blockieren.
Was ich sehr ärgerlich finde, mir erschließt sich dabei auch absolut kein Sinn. Davor gab es keine Probleme bei OpenVPN über UDP.
Der Verbindungsaufbau zum OpenVPN Server klappt zwar noch, allerdings geht danach nur noch der Datenverkehr vom "Ping-Befehl" durch.
Am Telekom DSL (only) Anschluss meiner Nachbarn funktioniert OpenVPN über UDP sowie TCP im Übrigen ohne Drosselung und oder Filterung.
An einem Kabelanschluss ebenfalls keine Drosselung und oder Filterung von OpenVPN über UDP/TCP.
Wenn ich meinen Hybrid Router in den DSL only Modus setze, funktioniert OpenVPN über UDP übrigens ganz normal. Allerdings seit neustem auch nur mit Drosselung.

Ich habe mal einige Speedtests gemacht, auch wenn die nicht immer aussagekräftig sind. Beim Download von großen Dateien ergab sich das gleiche Fehlerbild.
Ein Freund von mir, ebenfalls Hybrid Kunde, hat seit Anfang des Jahres auch die Blockade von OpenVPN über UDP und seit neustem ebenfalls die Drosselung von OpenVPN drin.
Gleiches Fehlerbild an einem anderen Anschluss mit anderen Endgeräten also, gebucht ist an beiden Anschlüssen "MagentaZuhause Hybrid S".

Nun zu den Tests...
- durchgeführt um kurz nach 0 Uhr Mitternacht an einem Donnerstag Abend/Freitag Morgen
- synchronisierte DSL Geschwindigkeit Downstream 3104 kbit/s - Upstream 1672 kbit/s; laut SP Hybrid
- Einheiten Mbit/s (Mb/s)
- Jeweils gleicher VPN Server bei allen Tests mit VPN
- OpenVPN über UDP im Hybrid Modus ergab keine Internet Verbindung, lediglich der Ping in CMD funktionierte
- Beweisbilder im Anhang

Test 0: Download 12.72 Mb/s - Upload 2.28 Mb/s (novpn, hybrid)

Test 1: Download 0.50 Mb/s - Upload 3.08 Mb/s (vpn_tcp, hybrid)

Test 2: Download 0.35 Mb/s - Upload 0.05 Mb/s (novpn, dsl_only)

Test 3: Download 0.30 Mb/s - Upload 0.07 Mb/s (vpn_tcp, dsl_only)

Test 4: Download 0.39 Mb/s - Upload 0.06 Mb/s (vpn_udp, dsl_only)

Ich hoffe meine Schilderung des Problems ist ausführlich genug.
So langsam verliere ich nämlich die Geduld mit dem Hybrid Anschluss der Telekom, und ja mir ist bewusst, dass es sich hierbei um ein Shared-Medium handelt.

EDIT:

Wir haben es jetzt 01:32 Uhr und die Download Geschwindigkeit bei OpenVPN über TCP liegt nun schon bei schwindelerregenden 170 - 300 KByte/s.

Ich bezweifle doch sehr sehr stark, dass die LTE Ausnutzung zu dieser Tageszeit derart hoch ist.

[#2 · Accepted solution]

---

@björn_335 schrieb:

Nach langem herumexperimentieren mit den MTU Werten der VPN Verbindung konnte ich das Problem nun endlich lösen!

Ebenso möchte ich anmerken, dass ich die MTUs der einzelnen physischen Netzwerkadapter wieder auf den Standardwert von 1500 gesetzt habe.

Die Lösung sieht wie folgt aus:

@Waage1969

Hat ja schon den Tipp mit den MTUs gegeben, danke dafür!

Der MTU Wert eines Hybridanschlusses liegt, sofern Bonding von DSL + LTE stattfindet, bei 1384.

Der UDP Header hat eine Größe von 8 Byte und der IPv4 Header 20 Byte, macht also zusammen 28 Byte.

Der TCP Header ist mindestens 20 Byte groß (maximal jedoch 60 Byte), hinzu kommt wieder der 20 Byte IPv4 Header, macht also zusammen 40-60 Byte.

Was bringt uns diese Erkenntniss jetzt also für den Einsatz von OpenVPN an einem Hybrid Anschluss?

Ganz einfach, man muss bei Verwendung von OpenVPN über UDP/TCP folgende Zeile in der "NAME.ovpn" Datei bzw. OpenVPN Konfiguration hinzufügen.

OpenVPN over UDP --> "mssfix 1356" setzen

// Hybrid MTU 1384 - (UDP Header 8 Byte + IP Header 20 Byte) = 1356

OpenVPN over TCP --> "mssfix 1344" setzen

// Hybrid MTU 1384 - (TCP Header 20 Byte + IP Header 20 Byte) = 1344

(Wie oben bereits erwähnt, bei TCP auch wahlweise bis MTU 1304, bei mir klappt es jedoch mit 1344 super)

Wie durch ein Wunder funktioniert jetzt nicht nur OpenVPN über TCP mit vollem Speed, sogar OpenVPN über UDP funktioniert jetzt wieder einwandfrei.

Danke nochmal an alle, die konstruktive Beiträge geliefert haben.

Falls ich mich irgendwo irren sollte, bitte gern berichtigen.

Quellen:

https://de.wikipedia.org/wiki/IPv4

https://de.wikipedia.org/wiki/User_Datagram_Protocol

https://de.wikipedia.org/wiki/Transmission_Control_Protocol

https://www.lifewire.com/tcp-headers-and-udp-headers-explained-817970

https://michael.stapelberg.de/Artikel/mtu_openvpn

https://openvpn.net/index.php/open-source/documentation/manuals.html

---

Ein kleiner Nachtrag

Im Oktober 2017 wurde für den Speedport Hybrid die Firmware Version "050124.03.06.002" verteilt.
Im Changelog ist folgender Hinweis zu finden: "Optimiertes Bonding (MTU-Size)"

https://www.speedguide.net/analyzer.php
Ein kurzer Blick auf den obigen Link verrät uns, dass der neue MTU Wert bei 1440 liegt, sofern der Bonding Tunnel genutzt wird.
Demnach kann man den Parameter mssfix nun etwas erhöhen.
Mit den alten Werten würde die Verbindung natürlich ebenfalls noch einwandfrei funktionieren, allerdings hat man dann (eventuell !) minimale Einbußen bei der Geschwindigkeit.


Die neuen Werte für den Parameter mssfix lauten wie folgt:
OpenVPN over UDP --> "mssfix 1412"
OpenVPN over TCP --> "mssfix 1400", wahlweise bis "mssfix 1360"

[#3]

Nach langem herumexperimentieren mit den MTU Werten der VPN Verbindung konnte ich das Problem nun endlich lösen!

Ebenso möchte ich anmerken, dass ich die MTUs der einzelnen physischen Netzwerkadapter wieder auf den Standardwert von 1500 gesetzt habe.

Die Lösung sieht wie folgt aus:

@Waage1969

Hat ja schon den Tipp mit den MTUs gegeben, danke dafür!

Der MTU Wert eines Hybridanschlusses liegt, sofern Bonding von DSL + LTE stattfindet, bei 1384.

Der UDP Header hat eine Größe von 8 Byte und der IPv4 Header 20 Byte, macht also zusammen 28 Byte.

Der TCP Header ist mindestens 20 Byte groß (maximal jedoch 60 Byte), hinzu kommt wieder der 20 Byte IPv4 Header, macht also zusammen 40-60 Byte.

Was bringt uns diese Erkenntniss jetzt also für den Einsatz von OpenVPN an einem Hybrid Anschluss?

Ganz einfach, man muss bei Verwendung von OpenVPN über UDP/TCP folgende Zeile in der "NAME.ovpn" Datei bzw. OpenVPN Konfiguration hinzufügen.

OpenVPN over UDP --> "mssfix 1356" setzen

// Hybrid MTU 1384 - (UDP Header 8 Byte + IP Header 20 Byte) = 1356

OpenVPN over TCP --> "mssfix 1344" setzen

// Hybrid MTU 1384 - (TCP Header 20 Byte + IP Header 20 Byte) = 1344

(Wie oben bereits erwähnt, bei TCP auch wahlweise bis MTU 1304, bei mir klappt es jedoch mit 1344 super)

Wie durch ein Wunder funktioniert jetzt nicht nur OpenVPN über TCP mit vollem Speed, sogar OpenVPN über UDP funktioniert jetzt wieder einwandfrei.

Danke nochmal an alle, die konstruktive Beiträge geliefert haben.

Falls ich mich irgendwo irren sollte, bitte gern berichtigen.

Quellen:

https://de.wikipedia.org/wiki/IPv4

https://de.wikipedia.org/wiki/User_Datagram_Protocol

https://de.wikipedia.org/wiki/Transmission_Control_Protocol

https://www.lifewire.com/tcp-headers-and-udp-headers-explained-817970

https://michael.stapelberg.de/Artikel/mtu_openvpn

https://openvpn.net/index.php/open-source/documentation/manuals.html

[#4]

Hallo @björn_335

super das es jetzt klappt und Besten Dank für die ausführliche Rückmeldung !

Gruß

Waage 1969

[#5]

@björn_335

---

björn_335 schrieb: Danke nochmal an alle, die konstruktive Beiträge geliefert haben. Bier
Falls ich mich irgendwo irren sollte, bitte gern berichtigen.

---

Schließe ich mich an und toll, dass du nicht klein beigegeben hast.

@Waage1969
Kleiner zwischendurch und ich bin auch so gut wie hier wieder weg.

Greetz
Stefan D.

[#6]

@björn_335

So ähnlich hätte meine Lösung wohl auch ausgesehen. Vielleicht wäre ich sogar für TCP und UDP auf einen einheitlichen Wert von 1300 runtergegangen (wenn man da auch etwas Performance verschenkt). Man kann sich dem Thema auch iterativ nähern um den optimalen Wert herauszubekommen. Ist aber u.U. ein wenig zeitintensiv.

Ich hatte mich mit dem Thema losgelöst von Hybrid vor Jahren selbst rumgeschlagen weil Home Office über die VPN-Verbindung nach Einsatz eines neuen Routers plötzlich nicht mehr funktioniert hat. Allerdings waren mir mangels Admin-Rechten am Firmennotebook deutlich mehr die Hände gebunden im Hinblick auf die MTU-Manipulationen, zumal es sich auch nicht um OpenVPN sondern um einen Cisco VPN Client gehandelt hat.

Bei mir war die Lösung damals einen anderen Router zu nehmen.

Danke Dir für den Ehrgeiz und die ausführliche Lösungsbeschreibung, die vielleicht künftig dem einen oder anderen auch helfen könnte.

[#7 · Accepted solution]

---

@björn_335 schrieb:

Nach langem herumexperimentieren mit den MTU Werten der VPN Verbindung konnte ich das Problem nun endlich lösen!

Ebenso möchte ich anmerken, dass ich die MTUs der einzelnen physischen Netzwerkadapter wieder auf den Standardwert von 1500 gesetzt habe.

Die Lösung sieht wie folgt aus:

@Waage1969

Hat ja schon den Tipp mit den MTUs gegeben, danke dafür!

Der MTU Wert eines Hybridanschlusses liegt, sofern Bonding von DSL + LTE stattfindet, bei 1384.

Der UDP Header hat eine Größe von 8 Byte und der IPv4 Header 20 Byte, macht also zusammen 28 Byte.

Der TCP Header ist mindestens 20 Byte groß (maximal jedoch 60 Byte), hinzu kommt wieder der 20 Byte IPv4 Header, macht also zusammen 40-60 Byte.

Was bringt uns diese Erkenntniss jetzt also für den Einsatz von OpenVPN an einem Hybrid Anschluss?

Ganz einfach, man muss bei Verwendung von OpenVPN über UDP/TCP folgende Zeile in der "NAME.ovpn" Datei bzw. OpenVPN Konfiguration hinzufügen.

OpenVPN over UDP --> "mssfix 1356" setzen

// Hybrid MTU 1384 - (UDP Header 8 Byte + IP Header 20 Byte) = 1356

OpenVPN over TCP --> "mssfix 1344" setzen

// Hybrid MTU 1384 - (TCP Header 20 Byte + IP Header 20 Byte) = 1344

(Wie oben bereits erwähnt, bei TCP auch wahlweise bis MTU 1304, bei mir klappt es jedoch mit 1344 super)

Wie durch ein Wunder funktioniert jetzt nicht nur OpenVPN über TCP mit vollem Speed, sogar OpenVPN über UDP funktioniert jetzt wieder einwandfrei.

Danke nochmal an alle, die konstruktive Beiträge geliefert haben.

Falls ich mich irgendwo irren sollte, bitte gern berichtigen.

Quellen:

https://de.wikipedia.org/wiki/IPv4

https://de.wikipedia.org/wiki/User_Datagram_Protocol

https://de.wikipedia.org/wiki/Transmission_Control_Protocol

https://www.lifewire.com/tcp-headers-and-udp-headers-explained-817970

https://michael.stapelberg.de/Artikel/mtu_openvpn

https://openvpn.net/index.php/open-source/documentation/manuals.html

---

Ein kleiner Nachtrag

Im Oktober 2017 wurde für den Speedport Hybrid die Firmware Version "050124.03.06.002" verteilt.
Im Changelog ist folgender Hinweis zu finden: "Optimiertes Bonding (MTU-Size)"

https://www.speedguide.net/analyzer.php
Ein kurzer Blick auf den obigen Link verrät uns, dass der neue MTU Wert bei 1440 liegt, sofern der Bonding Tunnel genutzt wird.
Demnach kann man den Parameter mssfix nun etwas erhöhen.
Mit den alten Werten würde die Verbindung natürlich ebenfalls noch einwandfrei funktionieren, allerdings hat man dann (eventuell !) minimale Einbußen bei der Geschwindigkeit.


Die neuen Werte für den Parameter mssfix lauten wie folgt:
OpenVPN over UDP --> "mssfix 1412"
OpenVPN over TCP --> "mssfix 1400", wahlweise bis "mssfix 1360"

[#8]

Auch ich habe den Speedport Hybrid und arbeite mit Viscosity auf meinem Mac OS X. Ich benötige eine OpenVPN Verbindung über UDP. Leider hilft der Trick mit dem "mssfix 1412" bei mir nicht. Habe auch die aktuellste Firmware auf meinem Speedport. Ich kann zwar einen Ping korrekt ausführen, aber alles weitere (wie das Aufrufen von internen Webapplikationen im Browser) ist nicht möglich.

Gibt es vielleicht noch einen weiteren Ansatz? Oder kann man hierzu den Telekom-Support mobilisieren?

Ich würde mich riesig über eure Hilfe freuen

PS: Anbei mal meine Config aus Viscosity...

[#9]

Hallo,

ich habe bereits einen anderen Post (https://telekomhilft.telekom.de/t5/forums/v3_1/forumtopicpage/board-id/710/page/7/thread-id/812728) gelesen und die Lösungsvarianten versucht, aber leider ohne Erfolg.

Ich habe den Speedport Hybrid und arbeite mit Viscosity auf meinem Mac OS X. Ich benötige eine OpenVPN Verbindung über UDP. Leider hilft der Trick mit dem "mssfix 1412" bei mir nicht. Habe auch die aktuellste Firmware auf meinem Speedport. Ich kann zwar einen Ping korrekt ausführen, aber alles weitere (wie das Aufrufen von internen Webapplikationen im Browser) ist nicht möglich.

Gibt es vielleicht noch einen weiteren Ansatz? Oder kann man hierzu den Telekom-Support mobilisieren?

Ich würde mich riesig über eure Hilfe freuen

PS: Anbei mal meine Config aus Viscosity...

[#10]

@martin_grambauer

Überprüf mal bitte, ob die angzeigte Firmware Version "050124.03.06.002" lautet.

Falls nicht, das Update mal manuell aufspielen.

https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-hybrid/speedport-hybrid-firmware

Wenn die aktuelle Firmware wirklich schon drauf ist, geh mal auf die folgende Seite und gib den MTU Wert durch.

https://www.speedguide.net/analyzer.php

[#11]

Hallo @martin_grambauer

willkommen.

bitte aber bei einem Thema / Problem auch in einem Beitrag / Thread bleiben.

Diese ist jetzt Nummer zwei, Ursprung siehe hier: https://telekomhilft.telekom.de/t5/Telefonie-Internet/Speedport-Hybrid-OpenVPN-Drosselung-kein-OpenV...

Gruß

Waage1969

[#12]

@martin_grambauer

ergänzend mal noch :

Hier bitte die Nutzerdaten geschützt im Profil hinterlegen  => Profildaten ,diese Daten sind nur für das Telekom hilft Team ersichtlich und nicht öffentlich. Wenn erfolgt bitte kurz hier im Beitrag antworten - Danke !

Gruß
Waage 1969

[#13]

Hallo,

danke für die Hilfe! Ja genau diese Firmware ist installiert.

Hier mal das Ergebnis des Analyzers:

« SpeedGuide.net TCP Analyzer Results » 
Tested on: 2017.11.02 09:51 
IP address: 93.242.xx.xxx 
Client OS/browser: Mac OS (Safari 603.2.4) 
 
TCP options string: 02040578010303050101080a45e9dbc00000000004020000 
MSS: 1400 
MTU: 1440 
TCP Window: 131840 (not multiple of MSS) 
RWIN Scaling: 5 bits (2^5=32) 
Unscaled RWIN : 4120 
Recommended RWINs: 64400, 128800, 257600, 515200, 1030400 
BDP limit (200ms): 5274kbps (659KBytes/s)
BDP limit (500ms): 2109kbps (264KBytes/s) 
MTU Discovery: ON 
TTL: 45 
Timestamps: ON 
SACKs: ON 
IP ToS: 00000000 (0) 

[#14]

@martin_grambauer

Normalerweise sollte es mit "mssfix 1412" einwandfrei funktionieren.

Ich kenne allerdings dein Programm nicht und gehe mal stark davon aus, das es an diesem liegt.
Du könntest höchstens mal "mssfix 1300" oder noch niedriger probieren, vielleicht geht es damit.

[#15]

@björn_335

Danke für deinen Tipp. Kannst du mir vielleicht einen guten OpenVPN Client empfehlen, möglichst Mac OS X kompatibel?

[#16]

@martin_grambauer

Da kann ich leider nicht helfen, habe selbst keinen Mac.

Dein Problem muss nicht zwingend mit dem Programm zusammenhängen, es könnte auch eine falsche Konfiguration sein.

[#17]

Hallo @Peuki @danXde

habt Ihr etwas "VPN" mäßiges für den MAC das am Hybrid - Anschluß läuft ?

Gruß

Waage1969

[#18]

Hallo @Waage1969,

leider nein... 

VG

Peuki

[#19]

---

@martin_grambauer schrieb:

Kannst du mir vielleicht einen [...] OpenVPN Client empfehlen, möglichst Mac OS X kompatibel?

---

Was ist mit https://tunnelblick.net/ ?

[#20]

Hi, leider auch von mir ein nein...bisher am Mac nur IPSec und ssl von im Einsatz. 

Grüsse

danXde

[#21]

@björn_335

Vielen Dank für deinen Bug-Fix (Lösung mit Nachtrag).

Ich hatte das gleiche Problem und bin fast verrückt geworden.

Endlich verbindet sich mein OpenVPN mit dem Internet.

Vielen vielen Dank!!

[#22]

Ich hab kein mssfix in meiner openvpn drin. Über LTE verliere ich öfters Pakete, was dann bei SSH dann oft kaputt geht.

Also hab ich den DSL-only Regel für mein OpenVPN eingerichtet. Dadurch kann ich nicht mal zu mein OpenVPN server verbinden. Als Workaround hab ich per TCP-portscanner gegen mein OpenVPN server gemacht, damit der Bonding es in sein NAT es registrieren kann. Mein OpenVPN server läuft auf UDP und TCP (jeweils eigene Ports).

Nicht nur bei OpenVPN hab ich Probleme, auch bei Destiny2 mit der DSL-only Regel hab ich auch Probleme. Bei Factorio hab ich ab und zu mal Datenverluste, aber das Spiel Factorio hat sein UDP Protokol so intelligent gemacht als wäre es selber TCP ist, daher merk ich bei Factorio quasi nie.

Also, bei einige UDP Protokollen muss ich ab und zu mal mit TCP-Portscanner auf dessen ZielIP jagen damit der UDP Verkehr auf der NAT beim Bondingserver erlaubt wird.