Gelöst
Speedport Hybrid OpenVPN Drosselung, kein OpenVPN über UDP
vor 9 Jahren
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.
test_0_novpn_hybrid.png
test_1_vpn_hybrid_tcp.png
test_2_novpn_dsl.png
test_3_vpn_dsl_tcp.png
test_4_vpn_dsl_udp.png
speedport.png
13911
0
45
Das könnte Ihnen auch weiterhelfen
vor einem Jahr
235
0
1
vor 3 Jahren
567
0
1
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 9 Jahren
Was ich an Deiner Stelle vermutlich mal probieren würde - einen "normalen" Router ranhängen - vielleicht liegt das Problem ja "nur" am Speedport Hybrid. Egal ob der mit "DSL plus LTE " oder "nur DSL" unterwegs ist.
0
0
vor 9 Jahren
0
39
von
vor 9 Jahren
So. Ich habe jetzt mal den vorgeschlagenen Test durchgeführt
1. an meinem VDSL50 IP-Anschluss der Telekom an welchem meine Fritzbox 7490 hängt mit aktueller Labor-Firmware. Zugriff über WLAN vom Windows 10 Notebook aus. Resultat:
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 260
In Windows 10, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed. Use the latest TCP Optimizer for tweaking.
RWIN is not fully optimized. The unscaled RWIN value is lower than it should be. Also, RWIN being close to and above 65535 does not justify the header overhead of enabling TCP 1323 Options. You might want to use one of the recommended RWIN values below.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
63888 (up to 2 Mbit lines, depending on latency. MSS * 44)
127776 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)
255552 (2-14 Mbit lines, depending on latency. MSS * 44 * 2^2)
511104 (8-30 Mbit lines, depending on latency. MSS * 44 * 2^3)
1022208 (25-60 Mbit lines depending on latency. MSS * 44 * 2^4)
Your TCP Window limits you to: 2662 kbps (333 KBytes/s) @ 200ms
Your TCP Window limits you to: 1065 kbps (133 KBytes/s) @ 500ms
TTL value is ok.
2. über LTE via meiner Daten-SIM im Telekommobilfunknetz , die in meinem Huawei MiFi E5770 drin steck. Zugriff über WLAN vom selben Windows 10 Notebook aus. Resultat:
MTU is fully optimized for broadband.
Maximum useful data in each packet = 1460, which equals MSS.
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 256
In Windows 10, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed. Use the latest TCP Optimizer for tweaking.
RWIN is not fully optimized. The unscaled RWIN value is lower than it should be. Also, RWIN being close to and above 65535 does not justify the header overhead of enabling TCP 1323 Options. You might want to use one of the recommended RWIN values below.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
64240 (up to 2 Mbit lines, depending on latency. MSS * 44)
128480 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)
256960 (2-14 Mbit lines, depending on latency. MSS * 44 * 2^2)
513920 (8-30 Mbit lines, depending on latency. MSS * 44 * 2^3)
1027840 (25-60 Mbit lines depending on latency. MSS * 44 * 2^4)
Your TCP Window limits you to: 2621 kbps (328 KBytes/s) @ 200ms
Your TCP Window limits you to: 1049 kbps (131 KBytes/s) @ 500ms
TTL value is ok.
0
von
vor 9 Jahren
Und so schaut es aus, wenn ich vom selben Windows 10 Notebook über einen Freifunkrouter rausgehe (der Freifunkrouter ist an meiner Fritzbox angeschlossen, baut aber ein VPN zum Freifunk-Server auf!)
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
MSS is not optimized for broadband. Consider increasing your MTU value.
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 256
In Windows 10, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed. Use the latest TCP Optimizer for tweaking.
RWIN is not fully optimized. The unscaled RWIN value is lower than it should be. Also, RWIN being close to and above 65535 does not justify the header overhead of enabling TCP 1323 Options. You might want to use one of the recommended RWIN values below.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
64800 (up to 2 Mbit lines, depending on latency. MSS * 54)
129600 (1-5 Mbit lines, depending on latency. MSS * 54 * 2)
259200 (2-14 Mbit lines, depending on latency. MSS * 54 * 2^2)
518400 (8-30 Mbit lines, depending on latency. MSS * 54 * 2^3)
1036800 (25-60 Mbit lines depending on latency. MSS * 54 * 2^4)
Your TCP Window limits you to: 2621 kbps (328 KBytes/s) @ 200ms
Your TCP Window limits you to: 1049 kbps (131 KBytes/s) @ 500ms
TTL value is ok.
von
vor 9 Jahren
Werte bei LTE , Hybrid, LTE + VPN , Hybrid+ VPN und sogar DSL+ VPN
MTU 1384, MSS 1344
Werte bei nur DSL: MTU 1452, MSS 1412
Momentan betrifft die Drosselung des VPN nur DSL-only und Hybrid.
LTE -only wird nicht gedrosselt.
Alles ganz mysteriös. Ich denke das ist hoffnungslos.
Eine Stellungnahme seitens der Telekom wäre nur mal ganz schön.
Uneingeloggter Nutzer
von
Akzeptierte Lösung
akzeptiert von
vor 8 Jahren
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
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"
0
vor 8 Jahren
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...
Bildschirmfoto 2017-11-02 um 11.12.26.png
0
2
von
vor 8 Jahren
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-OpenVPN-ueber-UDP/m-p/2908672#M854667
Gruß
Waage1969
0
von
vor 8 Jahren
@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
0
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von