Openvpn langsamer Durchsatz

  • Hallo zusammen!

    nach langem hin und her googeln habe ich mich doch mal hier im Forum registriert, da ich folgendes Problem einfach nicht gelöst bekomme:


    Zur Ausgangssituation:


    Ich besitze einen Netcup vServer, auf welchem ich Openvpn als Server installiert habe. Bei mir am Heimnetz hängt ein Raspberry Pi 3, welcher sich als client mit dem Server verbindet und als gateway zu meinem privaten LAN dienen soll. Wenn ich mich nun zB mit meinem Laptop innerhalb eines anderen Netzwerkes als client im VPN anmelde, kann ich via client-to-client Verbindung auf mein Heimnetz zugreifen.

    Das funktioniert auch alles soweit super, ich bin dabei nach dieser Anleitung vorgegangen Link.


    Nun zu meinem Problem:


    wie bereits geschrieben, die Verbindung zwischen den clients wird aufgebaut und ich habe Zugang zum Heimnetz von überall. An meinem Heimnetz hängt ein NAS (WD Mycloud Mirror), von welchem ich gerne Fotos/Videos über den Tunnel anschauen möchte. Das klappt auch soweit, jedoch ist die Übertragungsgeschwindigkeit alles andere als schnell (max. 5 Mbit/s).


    Nun habe ich bereits folgendes getestet:


    - Download vom NAS auf externen client (Laptop) mit max. 5 Mbit/s

    - Upload von Daten auf den NAS vom externen client (Laptop) läuft (für mich akzeptabel) schnell mit ca 20 Mbit/s.

    - Zugriff auf den Pi3 (gateway) vom externen client via sftp. Upload/Download auf/vom pi klappt schnell mit bis zu 20 Mbit/s.


    Ab hier bin ich ratlos und weiß nicht wo ich weitersuchen muss. Komisch ist, dass der Download vom Pi direkt (über den tunnel) schnell läuft, jedoch der Download vom NAS hinterm Pi ewig und 3 Tage dauert.


    Ich hoffe sehr dass jemand von euch ne Idee hat!


    Danke schonmal,


    Gruß,

    Daniel

  • Danke für euere Antworten! Ich sollte vielleicht dazu sagen, dass ich von der ganzen Netzwerk/VPN Geschichte nicht allzu viel Ahnung habe (rudimentäre Vorkenntnisse). Habe mich daher strikt an die oben verlinkte Anleitung gehalten.

    Quote

    Wie sieht deine OpenVPN Konfiguration aus? (Cipher, Compression, Segment Size / MTU, L4 Protocol)

    IPv4 / IPv6 außerhalb des Tunnels? Wenn IPv4, ist CG-NAT / DS-Lite im Spiel? Welchen Provider hast du?

    Ich werde gleich mal meine configs posten. Mein Provider ist 1&1, also ipv6 und dslite soweit ich weiß? Daher habe ich den vServer gebucht, um eine feste ipv4 Adresse zu bekommen und mich auch per ipv4 ins vpn einloggen zu können. Was genau ist CG-NAT?


    Als vServer habe ich den VPS 200 G8


    Ich hoffe, das hilft erstmal weiter.

  • Was genau ist CG-NAT?

    Carrier Grade NAT, wenn du DS-Lite hast und keine IPv4 direkt anliegen hast.

    Kabel Deutschland hatte damals enorme Probleme mit UDP VPNs über IPv4.


    Die Tunnelendpunkte sollten deshalb IPv6 sein.

    Mehr Spaß macht es natürlich mit den Netcup Rootservern, u.U. stößt du beim VPS an die Grenzen, allerdings sollte da mehr als 5 Mbit/s drinne sein.

  • soo, hier mal die configs:


    client:



    Und hier vom Server:



    weiterhin liegt unter /etc/openvpn/ccd/ folgende config für den pi:


    Code
    1. # Feste IP für den Client (Client-IP Subnet)
    2. ifconfig-push 10.8.0.3 255.255.255.0
    3. # Internes Routing zum Heimnetz über diesen Client
    4. iroute 192.168.178.0 255.255.255.0
  • [...]


    Die Tunnelendpunkte sollten deshalb IPv6 sein.

    Mehr Spaß macht es natürlich mit den Netcup Rootservern, u.U. stößt du beim VPS an die Grenzen, allerdings sollte da mehr als 5 Mbit/s drinne sein.


    Danke für die Erklärung :thumbup:

    Als mich wundert halt, dass wenn ich mich als client einlogge, dann via sftp eine Verbindung zum pi (gateway) aufbaue (über das VPN Subnet, also nicht die ip des pi´s im privaten Heimnetz), dann schaffe ich schnelle Up- und Downloads. hierzu habe ich einfach eine große Videodatei einmal vom client auf den pi kopiert und zurück vom pi auf den client.

    Kann da vllt irgendwo ein Problem mit dem Routing vom VPN aufs Heimnetz bestehen?

  • dronedale also die Konfiguration schaut schon einmal nicht wirklich übel aus. Was mir Sorgen macht, ist die hohe Verschlüsselung, die Du dem RPi3 abverlangst. Bedenke, dass OpenVPN mit Multithreading nicht wirklich umgehen kann. Zwar taktet der BCM2837 mit 1,2GHz einigermaßen hoch, er unterstützt nach meinem Kenntnisstand jedoch kein instruction set für AES-Beschleunigung. D.h. der Quad-Core kann de facto nur mit einem Kern die Daten verarbeiten und muss dort komplexe Berechnungen anstellen, um die AES-Verschlüsselung, die Du eingestellt hast, zu verarbeiten. OpenVPN ist auch nicht unbedingt bekannt für hohe Performanz.


    Weitere Punkte, die mir aufgefallen sind:

    1. tun-mtu 1500, aber keine Definition von „fragment“. Der Standardwert 1472 für eine MTU Deiner Internetverbindung von 1500 wäre korrekt. Bei DS-Lite ist die MTU vermutlich geringer. IPv6 kann da generell nur 1480 nützen (da der IP-Header gegenüber IPv4 um 20 Byte länger ist). Darin wird zudem dann IPv4 verkapselt, d.h. weitere 20 Byte für den IP-Header gehen verloren. Effektiv wird das wohl nur Fragmente von 1432 verarbeiten können. Der Rat von H6G , den Tunnel -sofern möglich- auf IPv6 aufzubauen, ist da sicher hilfreich. Der Wert für fragment sollte dann 1452 betragen. (1500 MTU - 40 Byte IPv6-Header - 8 Byte UDP)

    2. kein mssfix - eventuell ergänzen.

    3. Du kannst noch mit txqueuelen spielen: 1000 ist default, 10000 könnte auf Kosten erhöhter Latenz mehr Durchsatz bringen.

    4. Die Werte für sndbuf und rcvbuf sind ok, könnten aber auch etwas höher sein. OpenVPN regelt das an sich selbst, es gab jedoch Bugs auf diversen Platformen.

    5. Cipher - wie gesagt, wohl für den Raspi zuviel. Für die Auth-Header sind 512 Byte Cipherlänge wohl auch etwas zu hoch. Auf einem PC, der AES-NI beherrscht, sollte das weniger ins Gewicht fallen.

  • Besten Dank schonmal allen für die rege Anteilnahme!

    eripek

    Ich habe die Verschlüsselung schon von 256 auf 128 runtergesetzt, ohne erkennbaren Erfolg. Sollte ich da noch weiter runtergehen?

    Habe den mtu Wert mal auf 1432 reduziert, mit subjektiv leicht erhöhter Geschwindigkeit(ca 1 MB/s). Vielleicht sollte ich diesen Wert noch weiter optimieren? Muss ich den Wert server- sowie clientseitig anpassen?

    Bei der Option „fragment“ hatte ich gelesen, dass dann per ios keine Verbindung zum VPN mehr möglich sei, kann das stimmen?

    Du schreibst, dass Openvpn generell nicht sehr „performant“ sei, sollte ich darüber nachdenken, einen anderen VPN Dienst zu nutzen? Kannst du da was empfehlen? florian2833z schrieb ja etwas von WireGuard?

    Alternativ wäre ich auch grundsätzlich dazu bereit auf ipv6 umzustellen, in wie weit müsste ich dann meine vorhandene Konfiguration „umbauen“? Mir wäre es jedoch schon wichtig auch via ipv4 (Mobilfunk) auf das VPN zugreifen zu können.


    Gruß,

    Daniel

  • Bei einem Kunden habe ich mssfix auf 1300 eingestellt, da auch beim ihm am DSLite Anschluss der Durchsatz nicht so berauschend war.

    Du kannst natürlich den Server auf beides horchen lassen, v4 sowie v6. Der Tunnel vom DSLite Anschluss kommt über v6 und intern wird halt ein v4 aufgebaut.

    Andere Clients könnten weiterhin mittels v4 sich verbinden.

  • OpenVPN fällt direkt in die Handhabbarkeits-Kategorie von openssl rein. Unverständliche Dokumentation, die man nur nach einem Studium mit genau diesem Schwerpunkt versteht. Daher läuft da auch so viel schief. Aber ich denke das wollen die Leute Macher der Software auch so.


    wireguard dagegen so: https://www.wireguard.com/performance/ + https://www.wireguard.com/quickstart/

  • Ich habe die Verschlüsselung schon von 256 auf 128 runtergesetzt, ohne erkennbaren Erfolg. Sollte ich da noch weiter runtergehen?

    Habe den mtu Wert mal auf 1432 reduziert, mit subjektiv leicht erhöhter Geschwindigkeit(ca 1 MB/s). Vielleicht sollte ich diesen Wert noch weiter optimieren? Muss ich den Wert server- sowie clientseitig anpassen?

    Bei der Option „fragment“ hatte ich gelesen, dass dann per ios keine Verbindung zum VPN mehr möglich sei, kann das stimmen?

    Du schreibst, dass Openvpn generell nicht sehr „performant“ sei, sollte ich darüber nachdenken, einen anderen VPN Dienst zu nutzen? Kannst du da was empfehlen?

    Ein PC oder Einplatinencomputer, der AES unterstützt, würde etwaige Prozessorengpässe für OpenVPN besser handeln. Wie stark Deine CPU während eines Datentransfers tatsächlich ausgelastet ist, darüber gibt Dir etwa „top“ Auskunft.

    Zur MTU - wenn Du Deine beiden Endpunkte mit gesetztem Don't Fragment Flag pingst, erfährst Du den optimalen Wert: ping -Mdo -s1472 -c1 [openvpn-server-externe-ip] und von dort, soweit möglich, den Client in derselben Weise zu pingen, ermittelt den Maximalwert, den Du für Fragment einstellst. Wenn die Nutzlast von 1472 zu einem Timeout oder einer Antwort „message too big“ führt, pings sonst aber funktionieren, dann ist die MTU geringer als 1500 (1472 + 8 + 20). Da UDP und ICMP-Header gleich lang sind, können die Werte auf diese Weise leicht ermittelt werden.


    In der Wildnis häufig anzutreffende Werte für die Nutzlast sind etwa: 1412, 1432, 1452, 1454, 1460, 1462 oder 1464 und eben 1472.


    Mssfix in OpenVPN kann einen Sekundärparameter bekommen, benötigt ihn aber nicht zwingend. Afaik ist die MSS typischerweise MTU - 40 Byte.

    Die Option wirkt sich allerdings nur auf TCP aus, nicht auf UDP. Siehe: https://de.wikipedia.org/wiki/Maximum_Segment_Size



    Zu fragment und ios kann ich nichts sagen, aber, wenn tun-mtu als Parameter verwendet wird, soll laut OpenVPN-Dokumentation stets auch fragment verwendet werden. Man kann alternativ auch mit mtu und mtu-extra arbeiten, aber fragment liefert zuverlässige Ergebnisse, da die ausgehenden Pakete samt Overhead nie größer als das werden.


    OpenVPN arbeitet auf dem Application-Layer und hat keine Kernel-Module. D.h. es interagiert auf einem höheren Level, als notwendig wäre. In der Folge leidet es wohl auch eher an Bufferbloat. Zudem benützt es pro Dienst nur einen Prozessorkern, was bei fehlender AES-Unterstützung zusätzlich ins Gewicht fällt. Derzeit wird das zuvor schon erwähnte Wireguard als Lösung angepriesen, es soll aber auch noch ein paar Kinderkrankheiten haben. https://www.wireguard.com/



    Die Vorteile von OpenVPN liegen im Verbreitungsgrad der Software und ihrer Vielseitigkeit. Darin liegt aber auch die Komplexität. pmtud funktioniert nicht immer und auf allen Plattformen, die Verwendung von Kompression ist im Moment nicht unbedingt zu empfehlen, wenn zugleich 2.4.x und 2.3.x verwendet werden soll. Wie immer ist es wichtig, Logfiles lesen zu können und auch zu lesen. Irreführend ist oft, dass man glaubt, eine Verbindung seit aufgebaut, nur weil der Dienst im Log als laufend angezeigt wird, oder periodische Einträge aufgrund von ping/ping-restart (Option) aufscheinen. Das ist wertlos, solange nicht „connection initialized“ oder ähnlich geloggt wird. Fehler hingegen stechen mit „error“ auch heraus.

    Fragment-Errors - bei Verwendung einer falschen Fragmentgröße (die muss auf beiden Seiten gleichwertig eingestellt sein) - werden indes recht penetrant aufgezeichnet und fallen auf, wenn man sie sieht.

  • Ich habe aktuell gute Erfahrungen mit Wireguard (läuft auch auf dem RPi).

    Was die Performance auf dem Raspi angeht, hab ich aber nicht groß gemessen. Insgesamt hab ich aber schon den Eindruck, dass es besser performt. Nachteil: bei großen Netzwerken wirds anstrengend, weil die Konfigs auf alle Rechner muss. Vorteil: Mesh :)

  • Mssfix in OpenVPN kann einen Sekundärparameter bekommen, benötigt ihn aber nicht zwingend. Afaik ist die MSS typischerweise MTU - 40 Byte.

    Die Option wirkt sich allerdings nur auf TCP aus, nicht auf UDP. Siehe: https://de.wikipedia.org/wiki/Maximum_Segment_Size

    Das stimmt. In diesem Fall auch, aber für TCP im Tunnel.

    The –mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. –proto udp.

    Ok, man muss sollte dann auch noch die MTU anpassen (das hätte ich auch noch dazu schreiben sollen). Man muss halt bei den DSLite Zugängen etwas testen.

    Die Verbindung hier auf v6 umzustellen, würde ggf. am besten sein.