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]

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.

[#4]

Da eine Vernetzung von Standorten, zum Beispiel über eine VPN Verbindung, lt. Vertrag ohnehin untersagt ist, brauchst du dich doch nicht beschweren.

[#5]

---

@CyberSW schrieb:
Da eine Vernetzung von Standorten, zum Beispiel über eine VPN Verbindung, lt. Vertrag ohnehin untersagt ist, brauchst du dich doch nicht beschweren.

---

Du schießt in Deiner knackigen Art hier deutlich übers Ziel hinaus.

Es ist nicht von Standortvernetzung die Rede.

Ist mein OVPN-Server bei mir zu Hause etwa Vertragsbrüchig? Quelle bitte mal verlinken.

[#6]

---

@Gelöschter Nutzer schrieb:
Ist mein OVPN-Server bei mir zu Hause

---

@Gelöschter Nutzer

Es wurde hier im Thread nicht explizit geschrieben - aber ich gehe davon aus (lassen wir mal rechtliche Erwägungen beiseite und fokussieren auf die technische Fragestellung), dass der Fall des TE ist, dass der OVPN-Server nicht daheim steht und es nicht um einen Zugriff von unterwegs durch NAT hindurch geht, sondern dass es darum geht, von daheim aus (natürlich auch durch NAT hindurch, aber diesen Fall behandelt ein NAT Router u.U. freundlicher) auf einen OVPN-Server zuzugreifen. Z.B. in der Firma. Oder im Ausland um Geofencing zu umgehen. Oder...

(Eine Vernetzung von Standorten hat man ja immer wenn man sich ins Internet begibt - und wenn ich nur die Seite telekomhilft.telekom.de aufrufe. Was gem. AGB untersagt ist: eine dauerhafte Vernetzung von Standorten - ob es um eine solche im vorliegenden Fall geht weiß ich nicht. Siehe 2.2

Pauschal abgegoltene Leistungen dürfen ... nicht über eine dauerhafte Wählverbindung für die Vernetzung oder Verbindung von Standorten bzw. Telekommunikationsanlagen sowie für den Betrieb von Kassensystemen genutzt werden.

http://www.telekom.de/dlp/agb/pdf/44564.pdf

und PPPoE ist ja technisch eine "Wählverbindung"

Ich darf gem. AGB also z.B. keine dauerhaft stehende VPN-Verbindung meiner Fritzbox zur Fritzbox meines Vaters aufbauen)

[#7]

Hallo @björn_335

wurde denn der MTU Size DSL / LTE bei Deiner Netzwerkverbindung angepasst ?
Prüfen / eingrenzen könntest Du das mal durch abnschalten des LTE und testen

Gruß

Waage1969

[#8]

@CyberSW
Danke für gar nix.
Wenn Sie nicht helfen wollen, dann schreiben Sie Ihre konstruktiven Beitrage in Zukunft doch bitte in andere Bereiche des Forums, Dankeschön.

Einige versierte Nutzer - zu welchen ich mich zählen würde - sind nämlich durchaus in der Lage sich einen OpenVPN Server im Eigenheim einzurichten. Womit ich dann beispielsweise von Unterwegs (selbst wenn sich meine Wenigkeit am anderen Ende der Welt befindet) eine Verbindung nach Hause aufbauen kann, um auf die Inhalte meines NAS zuzugreifen.

Zitat: "nicht über eine dauerhafte Wählverbindung"
Da meine Verbindung nur temporär besteht, verstoße ich also nicht gegen die AGBs. Es sei denn, in diesen steht explizit geschrieben, dass "...die Verwendung von OpenVPN nicht gestattet ist". Mir ist hierzu jedenfalls nichts bekannt.

Wenn Sie also schon klugscheißen müssen, dann doch bitte mit dem nötigen Hintergrundwissen, Belegen und einem vernünftigen Umgangston.

Nun denn, back to topic...

@Gelöschter Nutzer

Danke! So sieht es nämlich aus.
Ich habe weder von Geo-Unblocking, Standort-Vernetzung oder ähnlichem geredet. Mir geht es einzig und allein um die Tatsache, dass scheinbar eine Drosselung bei Verwendung bestimmte Protokolle stattfindet.

@muc80337_2

Das kann ich gerne mal versuchen. Würde aber nichts an der Tatsache ändern, dass ich einen Hybrid Anschluss habe und diesen auch gern als solchen nutzen möchte.

@Waage1969

An den Werten habe ich nichts verändert.
Am Speedport ist diesbezüglich alles auf Werkeinstellung und am PC auch. Von einer falschen Adapter Konfiguration/Anpassung sehe ich ab, da ich es auch an meinem Androiden (OS 7.1.2) und Linux PC getestet habe.
Außerdem hat mein Freund ja den gleichen Fehler, dieser verbindet sich zwar auf einen externen OpenVPN Server, aber das Fehlerbild ist das gleiche.
Wenn ich einen externen OpenVPN Server verwende, ist das Fehlerbild auch vorhanden.

[#9]

Hallo @björn_335

hast Du die Verbindung denn schon mit abgeschaltetem LTE getestet ?

Und ergänzend noch mal der Hinweis:
was man bei dem Speedport Hybrid Tarif auch beachten muss ist das die MTU bei 1384 liegt statt bei 1492 wie bei normalen DSL. Falls die Übertragung lahmt sollte man kontrollieren wie die MTU beim eigenen Rechner eingestellt ist. 

Gruß

Waage1969

[#10]

Hallo @björn_335

habe da ggf. noch etwas für Dien OPEN VPN Thema / Probelm gefunden:

Hast du es mal mit "--tun-mtu 1500 --fragment 1300 --mssfix" (aus der Open VPN Dokumentation ) probiert :wink

Gruß

Waage1969

[#11]

Falls der @danXde derzeit aktiv sein sollte - er hat Hybrid und auch gewissen Erfahrungen mit VPN.

Es wäre gut wenn klar werden würde ob es sich um eine netzseitige oder um eine routerseitige Restriktion handelt.

Das mit den AGB - das sehe ich selbst nicht so eng. Die Telekom übrigens gelegentlich auch nicht.

Das wird in den meisten Fällen erst dann relevant, wenn die Telekom sich beschweren sollte wegen Verstoßes gegen die AGB.

So wie umgekehrt auch. Ich denke da nur an die SmartHome Wartungsfenster gem. AGB, aber die Wartungen finden zu x-beliebigen Zeiten statt. Aber das ist ein anderes Thema.

[#12]

@björn_335  ...du schreibst leider nicht, was sonst so die Rahmenbedingungen ausserhalb des openVPN sind.   DSL-Sync-Raten sieht man in  dem einen Bild, wie steht's mit den Empfangsbedingungen bei LTE aus.

Das vertrackte bei  Hybrid sind die beiden unterschiedlichen  GRE-Tunnel.  Über DSL können die Pakete 1492 sein, hingegen bei LTE nur  1384.    Wenn jetzt der Tunnel auf DSL aufgebaut wird. ...und  der Client das "Don't Fragment"-Bit setzt, können die Pakete nicht über LTE transportiert werden.  Daher bleibt er bei der DSL Uploadbandbreite oder gar drunter hängen.   Wenn der Tunnel mit 1384 Pakete aufgebaut wird, kommt es hingegen bei der Zuschaltung zu keinen Problemen. ..da die Pakete auch über  den LTE-pfad transportiert werden können.  Wenn das Bit nicht gesetzt wird, können die Pakete fragmentiert werden,  das könnte zu einem höheren Load beim Empfänger kommen, da dieser die Pakete wieder zusammen bauen muss. ...und die beiden Wege DSL und LTE haben auch noch unterschiedliche Laufzeiten,  das  könnte  also passieren, das die Pakete nicht in der Reihenfolge eintreffen, so das  viel gepuffert und sortiert werden muss.   Auch doof.   Daher mal die Tipp's von @Waage1969 checken.  ...ich bin  selbst nicht mit OpenVPN unterwegs, daher  etwas allgemeingültiger gehalten. Für IPsec und Anyconnect getestet.

Nachtrag:  Schau mal hier vorbei: https://michael.stapelberg.de/Artikel/mtu_openvpn.

Grüße

danXde

[#13]

Hab jetzt mal mit den MTU Werten rumgespielt.

Das Tool "SG TCP Optimizer" hat tatsächlich auch den optimalen MTU Wert von 1384 ausgespuckt.
Windows selber hat das setzen von diesem Wert untersagt, mit dem Tool ging es aber dennoch.

Allerdings konnte ich den Wert nur beim Ethernet und WLAN Adapter setzen.

Wenn ich den Parameter tun-mtu 1384 im OpenVPN Client verwende, bricht der Tunnel unter geringster Last sofort zusammen.

OpenVPN über UDP funktioniert auch mit dem optimalen MTU Wert nicht. (Gesetzt beim Ethernet Adapter)

OpenVPN über TCP mit MTU 1384 am Ethernet Adapter schwankt zwischen 300 und 400 Kbyte/s. Kurzzeitig geht es auch mal auf 500 hoch.

Ich vermute, es wird wieder verstärkt nur der DSL Teil genutzt.

Ich verstehe halt auch nicht, warum es vor einer Woche noch einwandfrei funktioniert hat. Obwohl ich an meiner Konfiguration nichts geändert habe.

Kann denn der Router den Endgeräten den optimalen MTU Wert mitteilen? Denn standardmäßig steht der in Windows ja immer auf 1500, da müssten doch einige Hybrid Kunden, egal ob Sie VPN nutzen oder nicht, massive Speedprobleme haben.

Hab mal noch die LTE Stats beigefügt.
(Wetter Sonnig, klarer himmel, 12:30 Uhr Mittags) Diese Faktoren spielen ja sicher eine große Rolle.

Der Router steht übrigens direkt am Fenster Richtung Norden.

Nachtrag:
Gerade nochmal ein paar Test gemacht.
LTE ist heute mal wieder gar nicht ausgelastet.
Ohne VPN 4-6 Mbit mit VPN ebenfalls, egal welcher MTU Wert gesetzt ist. Der scheint also nicht der Ursprung des Problems zu sein. Muss die Geschwindigkeiten heute abend nochmal testen.

[#14]

@björn_335bezüglich LTE:  der RSRQ ist mit -11 nicht optimal.   Oder fand zu dem Zeitpunkt eine Datenübertragung statt.  Beim Senden sackt der RSRQ immer um ca. 4 dBm ab.  Optimal wäre ein RSRQ von -6 dBm.   ..der RSRP ist soweit ok.  zumindest kann man bei diesen Werten durchaus wesentlich mehr  Bandbreite erreichen.  

Die Fenster sind hoffentlich nicht wärmeisoliert.  ..weil, dann machen sie wahrscheinlich das  Signal kaputte/bzw. verschlechtern es.

Hier wäre eine externe Antenne sicher eine potentielle Change auf  optimierung.

Nun zurück zum  Tunnel.  Den MTU-Size direkt auf dem WLAN/Ethernet Interface zu setzen kann helfen.  Bei dem Tunnelaufbau musst Du noch beachten,  das der Tunnel selbst noch weitere Bytes benötigt.  Schau mal hier.    Kann also sein, das  Du bei der Tunnelkonfiguration für den Internen Paketsize noch weitere Bytes abziehen musst und z.B. mit  1384-69  = 1315 operieren musst.

Kann auch sein, das TCP und UDP unterschiedliche  Header und damit unterschiedliche Größen benötigen....

"Ich habe nix geändert,trotzdem ist was anders."  ...da muss man leider sagen,  das  Hybrid immer noch im Reife-Prozess ist. ...und leider informiert uns die Telekom nicht, wenn sie an  den HAAP's was ändern.  Man bekommt es nur mit, wenn sich zeitgleich noch die Speedport Hybrid-Software ändert,  da findet sich dann auch mal ein Verweis in den Releasenotes.

Grüße

danXde

[#15]

Downloads waren zu dem Zeitpunkt keine Zugange.

Ich hab übrigens gerade festgestellt, der MTU Wert bringt eine Verbesserung.
Beim FTP Speedtest 3x 1GB Datei mit JDownloader (3 Verbindungen pro Datei) erreiche ich mit MTU 1500 ca. 1 MByte/s ohne VPN und die geliebten 60 KByte/s mit VPN über TCP.

Bei MTU 1384 sind es 1,8 MByte/s (also fast maximum meiner Leitung) ohne VPN und mit VPN immerhin schon 600 KByte/s.

Muss wohl wirklich mal noch bisschen mit den MTUs spielen.

Aber entstehen da für mich eigentlich Nachteile, wenn ich einen MTU von 1300 gesetzt habe und dann am VDSL Anschluss meines Bruders mit dem MTU Wert unterwegs bin?

Solange ich eh nicht mehr als LTE Speed S buchen darf, brauche ich wahrscheinlich auch keine externe Antenne.

[#16]

@björn_335  Im Intresse einer stabileren Verbindung  macht eine externe Antenne auch bei S Sinn.     Es ist was anderes, wenn er aufgrund der Fehlerraten die S-Bandbreite mit Ach-und Krach erreicht. ...aber viele Pakete  mehrfach übertragen werden müssen - oder mann  halt aufgrund des Profiles bei der Bandbreite beschränkt ist, diese aber dann stabil abgerufen werden können.

Die Nachteile sind, das er  bei einem Anschluss mit 1500er MTU dann  pro Paket  200 Bytes weniger sendet. ...man also nicht das  Maximum des mit MTU 1500 arbeitenden Anschlusses erreichen kann, da er halt Bytes verschenkt.. ... grade, wenn man über die Netzwerkkarte auch auf  benachbarte NAS zugreift,  würde das ebenfalls bemerkbar werden.

Grüße

danXde

[#17]

@danXde

Um das mal festzuhalten.
Das ganze Problem ist also wieder der Hybrid Technik geschuldet, oder vielmehr deren Umsetzung.

Gibt es einen technischen Grund, warum unterschiedliche MTUs bei LTE und DSL verwendet werden?Okay, aber das mit der Antenna ist ja jetzt erstmal ein anderes Thema.

[#18]

Ich würde mal rein interesehalber auf dieser Seite den Button "TCP Analyzer" drücken

https://www.speedguide.net/

und zwar für die Fälle (aus dem heimischen LAN heraus)

1. ohne VPN mit Hybridtunnel aktiv (also DSL + LTE aktiv)
2. ohne VPN nur mit DSL (LTE deaktiviert in der GUI des Speedport)
3. ohne VPN nur mit LTE (DSL-Kabel abgezogen)

Und dann noch einmal mit VPN (aus dem heimischen LAN bzw. von außerhalb im Zugriff auf Deinen VPN-Server).

[#19]

@björn_335...ich bin weder Angestellter der Telekom, noch  Huawei.   Ich gehe mal davon aus, Telekom hat spezifiziert und Huawei hat umgesetzt.  ....ergo müsste die Frage, nach dem "Warum" eher an die beiden Firmen gehen.  Ansonsten gehe ich davon aus, daß sie keine Bandbreite verschenken wollten, daher auf  jedem Medium jeweils die maximale MTU.

Grüße

danXde

[#20]

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:

TCP options string = 020405ac0103030801010402

MTU = 1492 MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.

MSS = 1452 MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.

Default TCP Receive Window (RWIN) = 66560 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)

bandwidth * delay product (Note this is not a speed test😞 Your TCP Window limits you to: 2662 kbps (333 KBytes/s) @ 200ms Your TCP Window limits you to: 1065 kbps (133 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 111 hops TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 00000000 (0)

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:

TCP options string = 020405b40103030801010402

MTU = 1500 MTU is fully optimized for broadband.

MSS = 1460 Maximum useful data in each packet = 1460, which equals MSS.

Default TCP Receive Window (RWIN) = 65536 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)

bandwidth * delay product (Note this is not a speed test😞 Your TCP Window limits you to: 2621 kbps (328 KBytes/s) @ 200ms Your TCP Window limits you to: 1049 kbps (131 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 104 hops TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 00000000 (0)

[#21]

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!)

TCP options string = 020404b00103030801010402

MTU = 1240 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 = 1200 MSS is not optimized for broadband. Consider increasing your MTU value.

Default TCP Receive Window (RWIN) = 65536 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)

bandwidth * delay product (Note this is not a speed test😞 Your TCP Window limits you to: 2621 kbps (328 KBytes/s) @ 200ms Your TCP Window limits you to: 1049 kbps (131 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 109 hops TTL value is ok.

Timestamps (RFC1323) = OFF

Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 00000000 (0)

[#22]

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.

[#23]

Hallo @björn_335

Rückmeldung Telekom / Team wäre schön, OK, glaube zwar nicht das es was bringt, aber mal einen Rundruf diesbezüglich @Anne W. @Henning H. @Stefan D. 
Gruß
Waage 1969

[#24]

@björn_335

---

björn_335 schrieb: Alles ganz mysteriös. Ich denke das ist hoffnungslos.
Eine Stellungnahme seitens der Telekom wäre nur mal ganz schön.

---

Du hast hier schon erstklassige Unterstützung aus der Runde bekommen, dafür ein großes DANKE an dieser Stelle. Mehr Ideen habe ich auch nicht, weil auch mein Horizont irgendwann erreicht ist.

@Waage1969
Ja, ist schwierig, weil auch die besten Ideen irgendwann ausgehen.

Greetz
Stefan D.

[#25]

Hallo @Stefan D.

so ist es.

Vieles bekommt man mit Einstellungen / experimentieren der Werte des MTU hin.

Manchmal sind es Kleinigkeiten (Einstellungen der Netzwerkkarte und des MTU) dort und dann halt in der VPN Software selbst die MTU Einstellungen. Hier muss bei den Betiebssystemen aber auch schön darauf geachtet werden das die Softwareinstellungen auch vom Betriebssystem zugelassen werden und nicht geblockt werden (Freigabe / Porgammberechtigung).

Manchmal findet man das leider nur durch Zufall

Gruß

Waage1969

[#26]

@Waage1969

---

Waage1969 schrieb: Vieles bekommt man mit Einstellungen / experimentieren der Werte des MTU hin.(…) Manchmal findet man das leider nur durch Zufall

---

Vieles ist einfach Vater Zufall oder findet man beiläufig heraus, obwohl man meint, bereits vieles zu wissen.

Greetz
Stefan D.