OpenVPN Verbindung ins Heimnetzwerk

  • Nun klappt die Verbdingung doch mit mtu 1350 und mssfix 1250. Mir ist allerdings aufgefallen, dass ich vom Handy aus weder Server noch Raspberry Pi Client anpingen kann, noch von Server oder Raspberry Pi das Handy. Server <-> Raspberry Pi lassen sich gegenseitig anpingen (~15ms).

  • Pappy Das Habe ich mir fast gedacht, als ich deinen Post gelesen habe. Daher habe ich mich drangehängt. Allerdings bin ich noch nicht soweit wie du. Für eine kleine Anleitung wäre ich sehr dankbar oder zumindest, was wo gemacht werden muss.


    Beispiel:

    Raspi:

    • xyz als VPN client
    • folgende config Datei bearbeiten


    Server:

    • VPN Server xyz <-- Raspi
    • VPN Server xyz <-- iOS
    • Ports x öffen auf VPN Server

    Das wäre schon ein Traum.


    Stefan

  • mtu ist wieder raus, mssfix auf 1250. Zum Test einmal "OpenVPN für Android" auf dem Handy installiert (vorher OpenVPN Connect). Nun lassen sich alle Geräte untereinander anpingen. Verbindung trotzdem noch sehr langsam.

  • mtu ist wieder raus, mssfix auf 1250. Zum Test einmal "OpenVPN für Android" auf dem Handy installiert (vorher OpenVPN Connect). Nun lassen sich alle Geräte untereinander anpingen. Verbindung trotzdem noch sehr langsam.

    Also ich habe mich selber mit OpenVPN -v.a. über LTE „Roadwarriors“ (also mobile Clients) eine Weile gespielt. Das Performanceproblem und das MTU-Problem hängen oft miteinander zusammen.


    Ich gebe einmal ein paar allgemeine Tips:

    1. Ermittlen der optimalen MTU:

    ping -c2 -M do -s 1472 openvpnserver-ipv4adresse

    ping6 -c2 -M do -s 1452 openvpnserver-ipv6adresse


    Diese beiden Kommandos senden je zwei Pingpakete mit einer Nutzlast für eine MTU von 1500 unter Verwendung des „Don't Fragment“ Flags an den Zielhost. Kommen sie nicht durch, war das Paket zu groß. Kommen sie durch und es wird eine Antwortzeit ausgegeben, passt alles.

    Mathematik dazu: Eine Nutzlast von 1472 addiert um 8 Byte für den ICMP-Header und 20 Byte für den IP-Header ergibt eine MTU von 1500 Byte.

    Bei IPv6 ist der IP-Header doppelt so groß, darum 40 Byte + 8 Byte +1452 Byte = 1500.


    2. Wie schon ein Vorposter meinte, kann man neben mss-fix auch Fragmente anpassen. Das OpenVPN-Manual meint dazu, dass man nur fragment und tun-mtu anpassen sollte.


    tun-mtu ist die Paketgröße innerhalb des Tunnels, fragment die, die über die Providerleitung geschickt wird. Da trägt man den größten Wert ein, bei dem der Ping mit IPv6 noch funktioniert hat. (Wenn nur Singlestack v4 benützt wird, diesen Wert.)

    Je mehr Pakete fragmentiert werden, desto mehr rechnet der Router und desto mehr Latenz gibt es.


    Exkurs zur MTU:

    Ein MTU-Problem löst man besser direkt am Providerrouter, falls möglich. PPPoE und VLANs (für Tripleplay-Dienste etc) verringern die MTU. Wenn ein Router Baby-Jumbo-Frames unterstützt und der Provider dies auch zulässt, dann arbeitet damit, um die MTU am Router auf 1500 anzuheben.

    (RFC4638). Gerade DSL-Modems mit älterem Linux-Kernel, respektive DSL-Treiber können das nicht. Etwa TP-Link VR200(v) ist so ein Problemkind, auch die Providerversionen der Fritzbox 7360v1, für die es keine Updates mehr gibt. Draytek-Modems im PPPoE-Passthrough-Mode kommen aber etwa damit zurecht.


    3. OpenVPN und Buffer...

    Frühere Versionen von OpenVPN hatten mit den Buffern bei Verwendung unterschiedlicher Binaries für Windows, Linux, *BSD Probleme.

    Es hilft manchmal, die Buffer fix einzustellen - auf beiden Seiten:

    Code
    1. sndbuf 524288
    2. rcvbuf 524288


    Mssfix hilft nur bei TCP. Auf UDP hat es keinen Einfluss. D.h. die in 1 und 2 genannten Tricks funktionieren umfassender.


    Wenn' s nicht hilft, bitte Deine Config (ohne Keys u.d.gl.) hier einmal posten.



    Noch ein Hinweis: Die Route zum VPNServer und die vom VPNServer muss nicht dieselbe MTU haben... Wenn Deine Gegenstelle hinter einem Carrier Grade NAT arbeitet oder ICMP blockt, funktioniert die MTU Path Discovery nicht. Wenn dann noch die effektive MTU kleiner ist, hast Du vor allem dann, wenn Du Openvpn verschlüsselst nützt plötzlich mehr Errors im OpenVPN Log. Es empfiehlt sich dann u.U. auch serverseitig die tun-mtu und fragments anzupassen.

  • So vielen dank schonmal für eure Bemühungen und ausführlichen Erklärungen. Den Test Server --> Raspberry Pi (VPN Client) Samba Share habe ich nun auch gemacht. Dabei ist die Geschwindigkeit genauso "schnell". Ping Kommando zur ermittlung der MTU habe ich auch für Handy --> Server und Raspberry Pi --> Server gemacht und bei beiden kommen die Pakete mit der genannten MTU durch(Pi --> Server ~30ms, Handy --> Server ~130ms). Ping6 konnte ich nicht durchführen, da komischerweise weder Server, noch Raspberry Pi eine globale IPv6 besitzen.

    Ich werde jetzt noch einmal alles neu aufsetzen, damit eventueller Pfusch von mir bereinigt ist. Welche Distribution bietet sich eigentlich für meinen Einsatz am besten an? Hatte bisher immer Debian Stretch bei beiden installiert.

    Ich befürchte auch langsam das dir Verbindung bei meiner Leitung nicht schneller werden kann bei maximal 1Mbit/s upload. Die andere OpenVPN APP(nicht Connect) zeigt immerhin auch mal Geschwindigkeiten bis 700kbit/s an.

  • Wenn du bei einer 16000er Leitung 700kb Upload hast, ist das gut. Du musst ja auch den Protokolloverhead mit berücksichtigen. Ich kann nachher ein Test beim Kunden von Client zu Client machen. Ein RS spielt auch da den VPN Server.

    Ich wollte auch für dieses Fall tinc ausprobieren, nur kam ich noch nicht dazu.

  • [...]

    Ich befürchte auch langsam das dir Verbindung bei meiner Leitung nicht schneller werden kann bei maximal 1Mbit/s upload. Die andere OpenVPN APP(nicht Connect) zeigt immerhin auch mal Geschwindigkeiten bis 700kbit/s an.

    Das ist natürlich ein wesentlicher Faktor, wenn es um den Upload vom VPN-Client Richtung Server geht. OpenVPN beherrscht allerdings auch Kompression - comp-lzo und neuerdings auch lz4. Die Kompressionseinstellung kann man in einer server - client - Konfiguration übrigens auch pushen. Die Firewall und Captive-Portal-Software pfSense ist übrigens für OpenVPN überaus komfortabel, wenn ich mir den Tip erlauben darf. Es handelt sich um ein BSD-Derivat. Auch OPNSense ist eventuell in ähnlicher Weise gut zu gebrauchen.


    Anbei eine ältere Konfiguration, wie ich sie bei den UMTS und LTE-Clients eingesetzt habe.


    remote gegenstelle.meinedomain.at

    tun-mtu 1500

    fragment 1400

    mssfix

    dev tun0

    dev-type tun

    proto udp

    client

    tls-auth ta.key 1

    ca /etc/openvpn/meineCA.crt

    cert /etc/openvpn/meinClient.crt

    key /etc/openvpn/meinClient.key

    remote-cert-tls server

    verb 5

    key-method 2

    auth SHA256

    cipher AES-256-CBC

    fast-io

    comp-lzo adaptive

    dh /etc/dhparam2048.pem

    persist-tun

    persist-key


    Variante:

    # dev tap0

    # dev-type tap

    # script-security 3

    # up /etc/scripts/ovpn-updown.sh

    # down /etc/scripts/ovpn-updown.sh



    Anmerkungen dazu: fragment 1400 bewirkt, dass eben keine Pakete größer als 1400 Byte gesendet werden. Die tun-mtu ist per Default-Einstellung 1500 und von den OpenVPN-Leuten wird empfohlen, die immer so zu belassen. Ebenso soll man link-mtu nicht angreifen und lediglich fragment und/oder mssfix verwenden) Da musst Du Dich mit Schätzwerten eben spielen, bis der optimale Wert gefunden ist (28 Byte habe ich abgezogen, weil wieder UDP im Spiel ist (nfs, samba, ...) und UDP-Header 8 Byte lang sind - genau wie im Beispiel oben mit ICMP. Wenn der Ping mit 1472 Byte problemlos durchgeht, dann ist daran aber auch nichts zu tun.

    type tun verwende ich, da ich nur IP routen möchte. Den ganzen Ethernetheader wie bei Tap zu übertragen, wäre overkill in meiner Broadcastsuppe; keine Ahnung, wie Du das machst, aber bei kompletten Ethernetframes, eventuell vlan müssen wir anders rechnen und womöglich mit tun-mtu-extra als Parameter arbeiten.

    Der Einser hinter tls-auth key 1 ist die Richtungsangabe. ca,cert,key: selbsterklärend. remote-cert-tls siehe https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage; script-security 3 (oder 2) brauche ich, wenn ich das Tunnelinterface etwa in eine Bridge legen möchte. Das up und down-Skript erfordern diese Berechtigung. auth und cipher müssen freilich bei client und server verfügbar und eingestellt sein. fast-io hilft CPU-Last unter Linux zu verringern. comp-lzo ist in den neueren OpenVPN-Versionen deprecated - stattdessen soll man nun „compress“ verwenden. Version 2.3 versteht den Parameter noch nicht. Compress alleine bewirkt aber nur packet framing compression... also compress lz4 oder compress lzo verwenden - muss auf Server und Client identisch sein. Debian 9 dh params muss man selbst erstellen, um sie benützen zu können: openssl dhparam -out /etc/dhparam.pem 2048 (da das auf Homeroutern sehr lange dauern kann, kann man das auf dem PC erstellen und rüberkopieren. persist-key behält die Tunnelkeys bei SIGUSR1 oder --ping-restart im Speicher, detto behält persist-tun die Konfiguration des tun-interfaces in diesen Fällen bei. Wenn Du mit up/down-script arbeitest um tun0 oder tap0 in eine bridge zu legen, wäre es überflüssig. Wenn Du übrigens tap-Devices verwendest, aber keine Notwendigkeit besteht alle Broadcasts zu übertragen, kannst Du mit ebtables -A FORWARD -j DROP auf der Bridge die direkte Kommunikation zwischen den Bridgeports vermeiden.


    Das Routing erledigt bei mir der Server der routen setzt: route 17.31.12.0/24 und dem Client Routen pusht: push "iroute 172.31.13.0/24"... Am Ende muss der Kernel dies dann nur richtig forwarden,... womit auch immer.


    Ist jetzt etwas viel Info und in Details nicht ganz korrekt, sollte aber als Starthilfe genügen.


    BTW: Kennst Du sshfs? Wäre vielleicht auch eine Lösung mit weit weniger Aufwand.

  • Gut geschrieben. Ein paar Anmerkungen:

    MTU: Wenn man einen DSLite Zugang hat (UnityMedia z.B.) muss man mit der MTU weiter runter gehen.

    Routing: Wenn man das Netz Zuhause komplett erreichen will und der Router auch nicht der VPN EndPoint ist, muss man dem Netz auch (z.B. über DHCP) die richtige Route mitgeben. Die Lösung habe ich so umsetzen müssen.

  • Gut geschrieben. Ein paar Anmerkungen:

    MTU: Wenn man einen DSLite Zugang hat (UnityMedia z.B.) muss man mit der MTU weiter runter gehen.

    Routing: Wenn man das Netz Zuhause komplett erreichen will und der Router auch nicht der VPN EndPoint ist, muss man dem Netz auch (z.B. über DHCP) die richtige Route mitgeben. Die Lösung habe ich so umsetzen müssen.

    Danke!

    Zu DSLite kann ich leider nichts beitragen. Mein Provider gibt mir natives Dual-Stack IP via PPPoE. Die minimal empfohlene MTU für IPv6 ist ohnedies 1280. Das muss man eben mit den ICMP-Probes mit don't fragment austesten, was die Obergrenze ist. Auf einer der OpenVPN-Listen hat sich einmal jemand die Mühe einer Tabelle gemacht, die scheint aber nur für tap-Devices zu gelten.


    Ad Routing: guter Punkt - Wenn der Heimrouter zugleich auch OpenVPN-Endpunkt und Default-Router für das Heimnetz ist, erübrigt sich das wohl.

    Ist er das nicht nicht, habe ich hier ein Posting dazu: https://forum.funkfeuer.at/t/r…manipulieren-solved/164/5 - kurz gefasst:


    Was zumeist funktioniert ist DHCP-Option 33 Hostrouten (RFC 2132).

    Nicht immer - vor allem nicht mit Android bis 4.4 funktioniert: RFC 3442: Option 121 (Classless Routes).

    Microsoft Option 249 ist ein Thema für sich...


    Und jetzt würde ich mich über eine Erfolgsmeldung freuen :-)

  • Macht das ganze einen Unterschied, wenn ich zu Innogy wechsel mit VDSL Vectoring 120/40 MBit? Ich bekomme mit meinem eigenen Router keine offentliche IPv4 zugewiesen. Ich muss ein Werksrouter nehmen, den ich nicht will. Ansonsten werde ich die Tage mal den Open VPN Server aufsetzten. Ich hatte mal kurz den c't Artikel umflogen, glaube Ausgabe 2. Sie gehen dort einen ganz anderen weg. Der Heimserver baut eine SSH Verbindung zum Server per RSA Key zum root User auf. Dort gibt es dann Regeln, welche Ports er dann weiterleitet zum Heimserver. Weiß net, finde VPN Verbindung irgendwie besser.

  • Macht das ganze einen Unterschied, wenn ich zu Innogy wechsel mit VDSL Vectoring 120/40 MBit? Ich bekomme mit meinem eigenen Router keine offentliche IPv4 zugewiesen. Ich muss ein Werksrouter nehmen, den ich nicht will. Ansonsten werde ich die Tage mal den Open VPN Server aufsetzten. Ich hatte mal kurz den c't Artikel umflogen, glaube Ausgabe 2. Sie gehen dort einen ganz anderen weg. Der Heimserver baut eine SSH Verbindung zum Server per RSA Key zum root User auf. Dort gibt es dann Regeln, welche Ports er dann weiterleitet zum Heimserver. Weiß net, finde VPN Verbindung irgendwie besser.

    Mit deutschen DSL-Providern kenne ich mich leider nicht aus, aber soweit mir bekannt ist, sind solche Angebote meist „best effort“, die Bandbreiten also Maximalwerte. Da sollte man nachschauen was vertraglich das Minimum ist. Ich selbst habe mit UMTS-Sticks auf OpenWRT für eine VÜ begonnen. Das war schon ok, da die nur bei Alarm Bilder gesendet hat. Der Stream war eher nicht damit möglich. Mittlerweile hat mein Prepaidprovider das LTE auf maximal 100/50 Mbit aufgestockt, der Alternativprovider hat 50/10. Zufriedenstellend war es für mich schon mit 20/6 Mbit/s, wobei effektiv 10:10 drübergegangen sind. Es ist also vieles machbar.


    Den Heise-Artikel habe ich nicht bei der Hand -ich kaufe das nur sporadisch, wenn das Inhaltsverzeichnis mich anspringt- ich habe aber kürzlich für eine Freifunk-artige Organisation die Wartung des Tunnelservers übernommen und da fahren wir mit ein paar handvoll Tunneln im peer2peer Mode über das besagte Bridge-Setup mit tap+ebtables+olsr, wobei die peers über unterschiedliche Anbindungen hereinkommen.


    ssh kann Portforwarding:

    ssh -L 26:192.168.1.1:25 meinrechner.meinedoma.in

    würde etwa Port 25 von 192.168.1.1, der hinter meinrechner.meinedoma.in liegt, auf dem lokalen Rechner, der ssh ausführt, unter port 26 verfügbar machen. Das ganze geht auch umgekehrt, meines Wisses mit "-g". Man kann übrigens mehrere "-L ..."-Optionen zusammen verwenden.


    Hier gibt es eine Anleitung für ssh reverse tunnel - vielleicht auch interessant:

    https://blog.devolutions.net/2…verse-ssh-port-forwarding


    sshfs hingegen würde gleich ein remote-Dateisystem als lokalen Mountpoint einbinden.


    Es gäbe auch curlftpfs - damit würde man einen FTP-Account lokal einbinden.


    Möglichkeiten gibt es viele - man muss nur den Wunsch genau artikulieren ;-)


    Was auch lustig ist, ist socat:

    http://www.dest-unreach.org/socat/doc/README - verwende es entweder wie netcat oder als VPN-Lösung oder als Modemserver oder als Terminalprogramm. Ich liebe es, aber es ist auch anspruchsvoll.

  • Zum Routing: Man kann euch einfach die Route auf dem Router setzen. bei FB ist das kein Problem. Dann braucht man keine statische Route per DHCP (oder manuell) setzen, sondern der Router schickt einfach alles zum VPN Einstiegspunkt weiter.

  • Zum Routing: Man kann euch einfach die Route auf dem Router setzen. bei FB ist das kein Problem. Dann braucht man keine statische Route per DHCP (oder manuell) setzen, sondern der Router schickt einfach alles zum VPN Einstiegspunkt weiter.

    Aber nur dann, wenn der Default Router dieser Router ist. Ein Verwandter hatte so ein Providermodem, wo man dies nicht konnte, weil alles wichtige gesperrt war. Die Lösung mit den Hostrouten war damals der praktikabelste Zugang, da ich ihm einen alternativen Router gebaut habe, der aber nicht Defaultrouter war und wo ich keine NAT-Kaskaden wollte.

  • Vielen Dank für eure Mühe mir das ganze ein wenig zu erklären. Ich habe jetzt noch einmal alles neu aufgesetzt und auf den Netgear Router die Firmware DD-WRT geflasht. Hab versucht den Router damit direkt als OpenVPN Client zu konfigurieren, jedoch bekomme ich diesen nicht so eingestellt, dass er sich mit dem Server verbindet. Also läuft das ganze erstmal wieder über den Pi und der Festplattenzugriff funktioniert mit der neuen Firmware jetzt auch (wenn auch immernoch sehr langsam: OpenVPN App 800kbit/s in, OpenVPN Connect App 100kbyte/s in / 4kbyte/s out). Ich werde jetzt erst einmal auf die Fertigstellung des Breitbandausbaus bei mir warten und dann schauen ob sich was an der VPN Geschwindigkeit getan hat (50000 werden bei mir verfügbar sein), da sich bisher gefühlt keine Einstellung auf die Geschwindigkeit ausgewirkt hat.

  • Vielen Dank für eure Mühe mir das ganze ein wenig zu erklären. Ich habe jetzt noch einmal alles neu aufgesetzt und auf den Netgear Router die Firmware DD-WRT geflasht. Hab versucht den Router damit direkt als OpenVPN Client zu konfigurieren, jedoch bekomme ich diesen nicht so eingestellt, dass er sich mit dem Server verbindet. Also läuft das ganze erstmal wieder über den Pi und der Festplattenzugriff funktioniert mit der neuen Firmware jetzt auch (wenn auch immernoch sehr langsam: OpenVPN App 800kbit/s in, OpenVPN Connect App 100kbyte/s in / 4kbyte/s out). Ich werde jetzt erst einmal auf die Fertigstellung des Breitbandausbaus bei mir warten und dann schauen ob sich was an der VPN Geschwindigkeit getan hat (50000 werden bei mir verfügbar sein), da sich bisher gefühlt keine Einstellung auf die Geschwindigkeit ausgewirkt hat.

    https://www.dd-wrt.com/wiki/in…/OpenVPN#GUI:_Client_Mode

    DD-WRT benütze ich schon ewig nicht mehr - zuletzt auf den WRT54G/GL ;-)

    Kann OpenWRT mit Deinem Router umgehen? https://wiki.openwrt.org/toh/s…lt%5BBrand*%7E%5D=netgear


    Zum PI: man muss wissen, dass bei all diesen Handy-SOC-Mini-Rechnern der Netzwerkanschluss über USB läuft. D.h. bei 100Mbit/s hast Du schon „Fullspeed“ bei Gigabit Ethernet beschränkt der SoC den Durchsatz auf zumeist 480 Mbit/s bei USB 2.0. Wenn Du eine lokale USB-Platte über das Netzwerk ansprichst teilen sich die die Bandbreite auch noch über den eingebauten Hub.


    Dennoch ist der Flaschenhals bei Dir definitiv das „Breitband“ Deines Providers. Da kann etwas Tuning keine Wunder bewirken, aber zumindest die Verlässlichkeit und die Latenzen verbessern helfen.


    Ad Warten auf das Ende vom Breitbandausbau: Kein Freifunk oder etwas in der Art in Deiner Stadt? https://freifunk.net/
    Manchmal muss man die Dinge eben auch selbst in die Hand nehmen. Funk ist zwar immer noch volatil, und garantiert ist nichts, aber Du kannst ja immer noch auf das DSL als Backup zurückgreifen.