OpenVPN - Erreiche Netzwerk hinter Client nicht

techsmile
Goto Top
Guten Tag,

derzeit schlage ich mich mit einem Problem herum, dem ich nicht auf die Schliche komme.
Folgendes Szenario:

Netzwerk 1:
Netzbereich: 192.168.182.0/24
VPN-Server IP: 192.168.182.3
Windows Server IP: 192.168.182.2
FRITZ!Box 7490

Netzwerk 2:
Netzbereich: 192.168.180.0/24
VPN-Client IP: 192.168.180.2
FRITZ!Box 6490 Cable

VPN-Netz:
192.168.15.0/24
VPN Client hat die statische IP 192.168.15.4


Die Konfiguration führe ich mit OpenVPN durch.
Auf meiner Synology DS läuft der OVPN-Server unter Netzwerk 1.
Der Client befindet sich in Netzwerk 2.

Was funktioniert?
Ich kann vom Netzwerk 2 die Geräte im Netzwerk 1 erreichen = Routing in Netzwerk 1 scheint zu stimmen.
Ebenfalls kann ich von Netzwerk 1 den VPN-Client unter 192.168.15.4 erreichen.

Was funktioniert nicht?
Wenn ich nun aber beispielsweise die FRITZ!Box im Netzwerk 2 anpinge, erhalte ich direkt: Antwort von 62.155.XXX.XXX: Zielnetz nicht erreichbar.

Warum ich das mache:
Ich habe unter der FRITZ!Box 6490 Cable leider eine DS-Lite Adresse und kann somit keine Ports freigeben VPN-Server betreiben.


Nun, was mache ich falsch?


Server.conf

Client.conf

ccd vpns2s

FRITZ!Box 7490 Routen:
2019-12-30

FRITZ!Box 6490 Routen:
2019-12-301

Vielen Dank vorab für Hilfe!

Freundliche Grüße

techSmile

Content-Key: 530283

Url: https://administrator.de/contentid/530283

Ausgedruckt am: 01.07.2022 um 17:07 Uhr

Mitglied: Spirit-of-Eli
Spirit-of-Eli 30.12.2019 um 18:24:56 Uhr
Goto Top
Im Endeffekt ist die Lösung die gleiche wie in den letzten 20 Fragen zu genau dem Thema.
Mitglied: techSmile
techSmile 30.12.2019 um 19:40:55 Uhr
Goto Top
Danke, ein Link wäre vielleicht schön.

Wenn du iroute meinst, wird die Konfiguration nicht übernommen. Nach jedem Neustart der VPN Verbindung steht wieder nur ifconfig-Push drin und iroute ist verschwunden.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 31.12.2019 um 00:51:19 Uhr
Goto Top
Die Fritte in Netz 2 braucht eine Rückroute für das VPN Netz da diese das Netz ja nicht kennt.
Mitglied: aqui
aqui 31.12.2019 aktualisiert um 12:25:26 Uhr
Goto Top
Nun, was mache ich falsch?
Das solltest du eigentlich auch selber sehen, denn das springt auch einem Laien ja förmlich sofort ins Auge !!!
Zuerst mal pushst du auf dem Server das interne IP Netz was vollkommender Blödsinn ist. Das dann auch gleich überflüssigerweise noch 2 mal mal was natürlich noch größerer Blödsinn ist.
Das gleich machst du dann nochmal mit den DHCP Options. Hier gibst du an den Client alle DHCP Server weiter, was natürlich völliger Unsinn ist.
Auch die Auth und Subnet Definition tauchen sinnloserweise alle doppelt auf was Probleme schafft.
Das aber was wichtig ist, nämlich die Route des remoten Netze zu propagieren tust du dann leider nicht. So ist es erwartbar das das so niemals klappen kann.
Du solltest also dringenst deine OVPN Server Konfig nochmal entwanzen die ist absoluter Murks !
So wäre es richtig:
port 1194
proto udp
dev tun
cipher AES-256-CBC
auth SHA512
server 192.168.15.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
push "route 192.168.182.0 255.255.255.0"
route 192.168.180.0 255.255.255.0
client-config-dir /etc/openvpn


Im Client Konfig Directory /etc/openvpn auf dem Server ist dann eine Datei "client1" (Das ist der Common Name deines OVPN Clients) die dann noch Client spezifische Routing Kommandos addiert wenn der Client mit dem Comman Name "client1" sich einwählt:
iroute 192.168.180.0 255.255.255.0
ifconfig-push 192.168.15.4 255.255.255.0


Jetzt brauchst du zwingend noch 2 Statische Route in den jeweiligen FritzBoxen !!!
  • FRITZ!Box 7490 (Netz 1) = Zielnetz: 192.168.15.0, Maske: 255.255.255.0, Gateway: 192.168.182.3 und Zielnetz: 192.168.180.0, Maske: 255.255.255.0, Gateway: 192.168.182.3
  • FRITZ!Box 6490 Cable (Netz 2) = Zielnetz: 192.168.15.0, Maske: 255.255.255.0, Gateway: 192.168.180.2 und Zielnetz: 192.168.182.0, Maske: 255.255.255.0, Gateway: 192.168.180.2
  • Fertisch !

Client Konfig ist bis auf die NICHT empfehlenswerte TCP Encapsulation soweit OK.
WICHTIG !:
Wenn dein VPN Client ein Rechner mit einem OS wie Winblows, Linux (Raspberry Pi etc.) oder Mac OS ist musst du hier zwingend zusätzlich IPv4 Forwarding sprich Routing im Betriebssystem aktivieren ! Generell ist das dort ausgeschaltet so das der Client dann NICHT ins lokale Netzwerk routen kann !
Sinnvoll ist es hier immer als Client einen kleinen OpenVPN Router zu verwenden der dort fest im lokalen Netz arbeitet:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...

Noch 2 grundsätzliche Fehler die du gemacht hast:
  • Niemals sollte man TCP Encapsulation nutzen bei OpenVPN oder generell VPN. Das verschlingt massiv Pewrformance und macht den Durchsatz extrem lahm. Zweitens bekommst du durch den massiven Protokoll Oberhead auch MTU Problem, die dann in weite Fragmentierung des VPN Traffics ausarten was die Performance dann och weiter in den Keller zwingt. Auch das OpenVPN Tutorial selber rät dringenst von TCP Encapsulation ab. Besser ist hier immer UDP !
  • Du nutzt Ports die in der Liste der offiziell registrierten IANA Ports liegen. Das ist nicht besonders toll und sollte man besser lassen. Zumal so oder so Portscanner alles diese vermeintlichen Ports eh abscannen dessen Nummerierung ähnlich von 443 ist. Security seitig ist das also nicht gut und auch nicht aus Standardtisierungssicht. Besser ist es hier immer welche der sog. Ephemeral_Ports zu verwenden im Bereich 49152 bis 65535 also z.B. 54433. Solche Ports sind erheblich sicherer.

Nebenbei: Wenn du die DS-Lite FB immer als sog. IPsec Initiator laufen lässt, sprich das sie IMMER die IPsec VPN Konfig initialisiert und die FB mit der öffentlichen IP als Responder müsst du kein Loch in deine Firewall bohren und ungeschützen Internet Traffic in dein lokales Netz und auch noch auf deinen zentralen NAS Speicher lotsen, sondern kannst, wie es VPN üblich ist, das VPN in der Peripherie auf den FBs terminieren....
Mitglied: techSmile
techSmile 31.12.2019 um 14:37:57 Uhr
Goto Top
Hallo,

vielen Dank für die ausführliche Antwort. Mit der kann ich etwas anfangen.

Das solltest du eigentlich auch selber sehen, denn das springt auch einem Laien ja förmlich sofort ins Auge !!!
Zuerst mal pushst du auf dem Server das interne IP Netz was vollkommender Blödsinn ist. Das dann auch gleich überflüssigerweise noch 2 mal mal was natürlich noch größerer Blödsinn ist.
Das gleich machst du dann nochmal mit den DHCP Options. Hier gibst du an den Client alle DHCP Server weiter, was natürlich völliger Unsinn ist.
Auch die Auth und Subnet Definition tauchen sinnloserweise alle doppelt auf was Probleme schafft.
Das aber was wichtig ist, nämlich die Route des remoten Netze zu propagieren tust du dann leider nicht. So ist es erwartbar das das so niemals klappen kann.
Du solltest also dringenst deine OVPN Server Konfig nochmal entwanzen die ist absoluter Murks !
So wäre es richtig:
port 1194
proto udp
dev tun
cipher AES-256-CBC
auth SHA512
server 192.168.15.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
push "route 192.168.182.0 255.255.255.0"
route 192.168.180.0 255.255.255.0
client-config-dir /etc/openvpn

Das habe ich soweit umgesetzt, bis auf den Port und das Protokoll.
Dazu aber unten mehr.

Im Client Konfig Directory /etc/openvpn auf dem Server ist dann eine Datei "client1" (Das ist der Common Name deines OVPN Clients) die dann noch Client spezifische Routing Kommandos addiert wenn der Client mit dem Comman Name "client1" sich einwählt:
iroute 192.168.180.0 255.255.255.0
ifconfig-push 192.168.15.4 255.255.255.0

Eine Idee, woran es liegen kann, dass die Client-Config jedes mal überschrieben wird?
Nach einem Neustart der VPN-Verbindung verschindet iroute 192.168.180.0 255.255.255.0 aus der Client-Config auf dem Server.
Ich habe dies jetzt nochmal gesetzt und werde beobachten, ob die Konfiguration wieder verschwindet.

Jetzt brauchst du zwingend noch 2 Statische Route in den jeweiligen FritzBoxen !!!
  • FRITZ!Box 7490 (Netz 1) = Zielnetz: 192.168.15.0, Maske: 255.255.255.0, Gateway: 192.168.182.3 und Zielnetz: 192.168.180.0, Maske: 255.255.255.0, Gateway: 192.168.182.3
  • FRITZ!Box 6490 Cable (Netz 2) = Zielnetz: 192.168.15.0, Maske: 255.255.255.0, Gateway: 192.168.180.2 und Zielnetz: 192.168.182.0, Maske: 255.255.255.0, Gateway: 192.168.180.2
  • Fertisch !
Fertisch, Danke!

Client Konfig ist bis auf die NICHT empfehlenswerte TCP Encapsulation soweit OK.
WICHTIG !:
Wenn dein VPN Client ein Rechner mit einem OS wie Winblows, Linux (Raspberry Pi etc.) oder Mac OS ist musst du hier zwingend zusätzlich IPv4 Forwarding sprich Routing im Betriebssystem aktivieren ! Generell ist das dort ausgeschaltet so das der Client dann NICHT ins lokale Netzwerk routen kann !
VPN-Client ist ein Raspberry Pi 4 inklusive IPv4 Forwarding und IPTables MASQUERADE für TUN0 - beides aktiviert bzw. konfiguriert.

Sinnvoll ist es hier immer als Client einen kleinen OpenVPN Router zu verwenden der dort fest im lokalen Netz arbeitet:
https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...
War eigentlich nicht meine Idee, sowas zusätzlich zu kaufen.
Ist einfach ein kleines Bastelprojekt, um dabei was zu lernen.
Trotzdem Danke für den Hinweis!

Noch 2 grundsätzliche Fehler die du gemacht hast:
  • Niemals sollte man TCP Encapsulation nutzen bei OpenVPN oder generell VPN. Das verschlingt massiv Pewrformance und macht den Durchsatz extrem lahm. Zweitens bekommst du durch den massiven Protokoll Oberhead auch MTU Problem, die dann in weite Fragmentierung des VPN Traffics ausarten was die Performance dann och weiter in den Keller zwingt. Auch das OpenVPN Tutorial selber rät dringenst von TCP Encapsulation ab. Besser ist hier immer UDP !
Oben bereits angesprochen, möchte ich kurz genauer erläutern, wieso ich das mache.
Ich nutze VOIP über OpenVPN. Wenn ich das UDP Protokoll verwende, hört mich die Gegenstelle, aber ich höre nichts.
Nach Umstellung auf TCP funktioniert das nun. Performancetechnisch merke ich keinen Unterschied, ich komme auf ca. 4,5 MB/s bei 40 MBit/s im Upload auf der VPN-Serverseite. Da ich sowieso nicht den ganzen Traffic über OpenVPN leite, ist das für mich vollkommen ausreichend.

* Du nutzt Ports die in der Liste der offiziell registrierten IANA Ports liegen. Das ist nicht besonders toll und sollte man besser lassen. Zumal so oder so Portscanner alles diese vermeintlichen Ports eh abscannen dessen Nummerierung ähnlich von 443 ist. Security seitig ist das also nicht gut und auch nicht aus Standardtisierungssicht. Besser ist es hier immer welche der sog. Ephemeral_Ports zu verwenden im Bereich 49152 bis 65535 also z.B. 54433. Solche Ports sind erheblich sicherer.
Auch damit habe ich vemehrt Probleme, wenn ich unterwegs bin.
Den Port 443 habe ich bereits durch einen Webserver in Verwendung, weshalb ich auf einen anderen Port ausweichen musste.
Nach etwas probieren bin ich bei diesem Port geblieben, da er in fast allen öffentlichen Hotspots und Hotelnetzwerken erlaubt ist und ich so auf Reisen telefonieren und RDP-Arbeiten betreiben kann. Zudem ist mir immer wieder aufgefallen, dass die VPN-Verbindung (Arbeitgeber) unter UDP (443) vemehrt bei einem Unitymediaanschluss verworfen wird (mit Wireshark überprüft) und ich somit das Nachbars-WLAN in Anspruch nehmen muss.

Nebenbei: Wenn du die DS-Lite FB immer als sog. IPsec Initiator laufen lässt, sprich das sie IMMER die IPsec VPN Konfig initialisiert und die FB mit der öffentlichen IP als Responder müsst du kein Loch in deine Firewall bohren und ungeschützen Internet Traffic in dein lokales Netz und auch noch auf deinen zentralen NAS Speicher lotsen, sondern kannst, wie es VPN üblich ist, das VPN in der Peripherie auf den FBs terminieren....

Nach Recherche ist dies nicht so leicht möglich, da beide FRITZ!Boxen versuchen die Verbindung aufzubauen. Man muss hier die Configdatei anpassen, was ich auch schon mal versucht habe. Leider hat das nicht geklappt und ich finde die Vorzüge des OpenVPN-Servers Clienttechnisch einfach besser.
Keine nervigen Konfigurationsparameter, die man jedes Mal eingeben muss - Datei von der Cloud runterladen, einbinden, fertig.

Ich teste die Konfiguration so mal und melde mich wieder.

Viele Grüße
techSmile
Mitglied: aqui
aqui 31.12.2019 aktualisiert um 15:21:12 Uhr
Goto Top
Eine Idee, woran es liegen kann, dass die Client-Config jedes mal überschrieben wird?
Ohne Angabe des Client Betriebsystem natürlich nicht !
Nur so viel:
Die beiden Kommandos: iroute 192.168.180.0 255.255.255.0 und ifconfig-push 192.168.15.4 255.255.255.0 stehen auf dem Server ! Bzw. im Client spezifischen Verzeichnis als Datei mit dem Namen client1 was mit client-config-dir /etc/openvpn in der Serverkonfig definiert ist. Möglich oder auch sehr wahrscheinlich das es in der OVPN App deines NAS ein anderes Verzeichnis ist.
Sofern sich also der Client mit dem Common Name aus der Client Zertifikats Konfig "client1" im Server anmeldet "sieht" der im Verzeichnis etc/openvpn nach ob es dort eine Datei client1 gibt. Da es diese gibt wird zusätzlich zur Server Konfig noch diese 2 Kommandos ausgeführt.
ifconfig-push 192.168.15.4 255.255.255.0 bewirkt das der Client immer fest die IP 192.168.15.4 im OVPN Netz bekommt.
iroute 192.168.180.0 255.255.255.0 pflanzt eine statische Route in die Routing Tabelle des Clients, das dieser eingehende Pakete für das Zielnetz 192.168.180.0 /24 ebenso in den VPN Tunnel routet. Sprich also genau was er soll im das Netz 1 zu erreichen ! Das kann man im Client auch einfach prüfen indem man sich dort die Routing Tabelle ansieht. (route print = Winblows, ip route list oder netstat -rn bei unixoiden OS)
Als quick and dirty Konfig könnte man auch dem Server fest das Kommando iroute 192.168.180.0 255.255.255.0 ohne Client spezifischen Bezug konfigurieren. Es bedeutet nur das dann alle Clients immer fest diese Route gepusht bekommen. Sofern du also nur diesen einen Client hast der dir die beiden Netze koppelt musst du die Client spezifische Konfig nicht machen !
und IPTables MASQUERADE für TUN0 - beides aktiviert bzw. konfiguriert.
Das ist ein Riesen Fehler !!!
Niemals solltest du ein Maquerading im Tunnel machen. Damit schaffst du dir eine routingtechnische Einbahnstrasse in der Kopplung beider Netze !!
Siehe eine entsprechende Raspberry Pi OVPN Beispielkonfig hier:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...
Masquerading (NAT) muss also zwingend deaktiviert werden da es hier kontraproduktiv bei der Netzkopplung ist !
Ist einfach ein kleines Bastelprojekt, um dabei was zu lernen.
👍 Das ist auch der weitaus bessere Weg !
Ich nutze VOIP über OpenVPN. Wenn ich das UDP Protokoll verwende, hört mich die Gegenstelle, aber ich höre nichts.
Das ist ein laienhafter Denkfehler ! Das hat rein gar nichts mit TCP oder UDP in der Tunnelencapsulation zu tun ! Denke mal bitte selber etwas nach !
Das Problem ist das du NAT machst im Tunnel !!! Das bedeutet das das RTP Protokoll (RTP transportiert die Sprachdaten !) was dynamische Ports innerhalb des Tunnels benutzt keine bidirektionale Spachverbindung aufbauen kann weil eine Seite an der Tunnel NAT Firewall des OVPN hängen bleibt da du fälschlicherweise den Tunnel selber NATest was ein Konfig Fehler ist wie oben schon gesagt ! Im internen Netz braucht man logischerweise nirgendwo NAT.
DAS ist das Problem und nicht die Encapsulation. Im gegenteil, gerade bei VoIP benötigst du Latenz armen Traffic und den kannst du einzig nur mit einer UDP Encapsulation garantieren die du dann auch besser zwingend aktivieren solltest. Der Port ist dabei kosmetisch aber auch da sollte man sich besser an Standards halten.
Auch damit habe ich vemehrt Probleme, wenn ich unterwegs bin.
Gut das liegt dann daran das du dann in Firewalls usw. hängen bleibst bei manchen Netzen. OK, der Port ist dann auch mehr oder minder kosmetisch, NICHT aber das fehlerhafte NAT was du im Tunnel machst !
Nach Recherche ist dies nicht so leicht möglich, da beide FRITZ!Boxen versuchen die Verbindung aufzubauen.
Es ist leicht wenn man die Konfig Datei anpasst...natürlich richtig, das ist klar. ;-) face-wink
Wenn du mit der reduzierten Sicherheit leben kannst ist das kein Thema, dann belasse das mit OVPN so wie es ist.
Ich teste die Konfiguration so mal und melde mich wieder.
Wir sind gespannt....
Mitglied: techSmile
techSmile 31.12.2019 aktualisiert um 18:53:19 Uhr
Goto Top
Ohne Angabe des Client Betriebsystem natürlich nicht !

Das Client-BS ist ein simples Raspbian in Version 4.19 (aktuellste Version - erst vor kurzem installiert)
Das Log auf dem Raspi gibt das aus:
iroute 192.168.180.0 255.255.255.0 steht in der clientspezifischen Config für den Benutzer so wie angesprochen.
Leider scheint es keine Wirkung zu haben.

Nur so viel:
Die beiden Kommandos: iroute 192.168.180.0 255.255.255.0 und ifconfig-push 192.168.15.4 255.255.255.0 stehen auf dem Server ! Bzw. im Client spezifischen Verzeichnis als Datei mit dem Namen client1 was mit client-config-dir /etc/openvpn in der Serverkonfig definiert ist. Möglich oder auch sehr wahrscheinlich das es in der OVPN App deines NAS ein anderes Verzeichnis ist.
Sofern sich also der Client mit dem Common Name aus der Client Zertifikats Konfig "client1" im Server anmeldet "sieht" der im Verzeichnis etc/openvpn nach ob es dort eine Datei client1 gibt. Da es diese gibt wird zusätzlich zur Server Konfig noch diese 2 Kommandos ausgeführt.
ifconfig-push 192.168.15.4 255.255.255.0 bewirkt das der Client immer fest die IP 192.168.15.4 im OVPN Netz bekommt.
iroute 192.168.180.0 255.255.255.0 pflanzt eine statische Route in die Routing Tabelle des Clients, das dieser eingehende Pakete für das
Als quick and dirty Konfig könnte man auch dem Server fest das Kommando iroute 192.168.180.0 255.255.255.0 ohne Client spezifischen Bezug konfigurieren. Es bedeutet nur das dann alle Clients immer fest diese Route gepusht bekommen. Sofern du also nur diesen einen Client hast der dir die beiden Netze koppelt musst du die Client spezifische Konfig nicht machen !
Das ist ein Riesen Fehler !!!
Niemals solltest du ein Maquerading im Tunnel machen. Damit schaffst du dir eine routingtechnische Einbahnstrasse in der Kopplung beider Netze !!
Ist nun deaktiviert. Habe nochmal alle Routen gelöscht und anschließend neugestartet --flush :-) face-smile
Leider funktioniert die Verbindung aus Netzwerk 1 zu Netzwerk 2 nach wie vor nicht.
Traceroute zeigt folgendes von Windows Server im Netzwerk 1:


Scheinbar weiß die FRITZ!Box nicht, wohin mit dem Paket. So sieht es zumindest für mich aus.
Wenn ich direkt über die Synology DS (VPN-Server) Traceroute starte erhalte ich folgendes:


Sieht so aus, als ob die FB direkt ins Internet routet, aber warum?

Siehe eine entsprechende Raspberry Pi OVPN Beispielkonfig hier:
https://administrator.de/content/detail.php?id=359367&token=695#comm ...

Ich kann nicht erkennen, was auf der Serverseite zu tun ist, damit der Client hinter dem Server das Netzwerk hinter dem Raspi erreichen kann.

Das ist ein laienhafter Denkfehler ! Das hat rein gar nichts mit TCP oder UDP in der Tunnelencapsulation zu tun ! Denke mal bitte selber etwas nach !
Das Problem ist das du NAT machst im Tunnel !!! Das bedeutet das das RTP Protokoll (RTP transportiert die Sprachdaten !) was dynamische Ports innerhalb des Tunnels benutzt keine bidirektionale Spachverbindung aufbauen kann weil eine Seite an der Tunnel NAT Firewall des OVPN hängen bleibt da du fälschlicherweise den Tunnel selber NATest was ein Konfig Fehler ist wie oben schon gesagt ! Im internen Netz braucht man logischerweise nirgendwo NAT.
DAS ist das Problem und nicht die Encapsulation. Im gegenteil, gerade bei VoIP benötigst du Latenz armen Traffic und den kannst du einzig nur mit einer UDP Encapsulation garantieren die du dann auch besser zwingend aktivieren solltest. Der Port ist dabei kosmetisch aber auch da sollte man sich besser an Standards halten.
Ich habe auf UDP gewechselt und hatte am Anfang wieder die Probleme, dass nach wenigen Sekunden die Sitzung einfriert, Seitenaufbau stoppt, etc.
Nach Recherche bin ich darauf gestoßen, dass es mit MTU zusammenhängen kann und somit des Rätsels Lösung gefunden.
In der Clientconfig habe ich hierzu mssfix 1430 eingetragen, nachdem ich den MTU-Wert überprüft habe. Zu beachten ist hierbei MTU-40=MSS
Gut das liegt dann daran das du dann in Firewalls usw. hängen bleibst bei manchen Netzen. OK, der Port ist dann auch mehr oder minder kosmetisch, NICHT aber das fehlerhafte NAT was du im Tunnel machst !
Es ist leicht wenn man die Konfig Datei anpasst...natürlich richtig, das ist klar. ;-) face-wink
Wenn du mit der reduzierten Sicherheit leben kannst ist das kein Thema, dann belasse das mit OVPN so wie es ist.

Ist das denn wirklich ein so hohes Risiko, wenn ich den Port auf den VPN-Server zeigend geöffnet habe?
Es wird ja nach wie vor das korrekte Zertifikat benötigt. Zumal ich den OpenVPN-Server trotzdem für mein Smartphone und Laptop betreiben möchte. So einfach wie mit OpenVPN ist das mit dem Fritten-VPN nicht realisierbar.

Danke für deine ausführlichen Antworten, das ist echt spitze!

Viele Grüße
techSmile
Mitglied: aqui
aqui 01.01.2020 aktualisiert um 17:05:38 Uhr
Goto Top
iroute 192.168.180.0 255.255.255.0 steht in der clientspezifischen Config für den Benutzer so wie angesprochen. Leider scheint es keine Wirkung zu haben.
Bedenke das mit clientspezifischen Config eine Konfig Datei gemeint ist die auf dem Server liegt, sprich also in der Server Konfig !!!
Du solltest über den Shell Zugang (PuTTY etc.) auf deinem NAS explizit sicherstellen das es dieses Verzeichnis auch wirklich gibt und das die Server Konfig mit dem Kommando client-config-dir /etc/openvpn(clients dieses existierende Verzeichnis auch dem Server bekannt macht ! Ebenso das die eintsprechende Client Config Datei in diesem Verzeichnis entsprechende Leserechte (chmod 755) hat !!
Vermutlich existiert entweder das verzeichnis auf dem OVPN Server nicht, der Konfig Eintrag fehlt oder die Client Konfig Datei liegt nicht in dem ZVerzeichnis oder fehlende Rechte ?! Es kann nur diese 3 Gründe geben.
Checke das also über den SSH Shellzugang !
Letztlich ist wie gesagt aber diese Datei nicht zwingend. Wenn du nur einen singulären Client hast dann kannst du das iroute Kommando iroute 192.168.180.0 255.255.255.0 auch so in die Server Konfig legen.
Wichtig ist das dann beide route Kommamndos route... und auch iroute... dort definiert sind.

An der Client Fehlermeldung raspberrypi-4 ovpn-client[444]: ERROR: Linux route add command failed: external program exited with error status: 2 kannst du ja ganz deutlich sehen das hier was schief läuft. Dein OVPN Prozess rennt mit falschen Rechten so das die vom Server propagierten Routen NICHT installiert werden oder werden können !!!
Dadurch hat dein Client eine fehlerhafte Routing Tabelle ! So kann das dann logischerweise niemals klappen. Es lohnt also mal die Fehler auch zu erkennen die im Log stehen, denn das Log lügt nie !
Leider hast du es nicht geschafft hier einmal die Client Konfig zu posten :-( face-sad
Ebenso fehlt ein ip route list oder netstat -rn auf dem RasPi mit aktivem VPN Client ! :-( face-sad
Letztere beiden Kommandos würden dir dann die Routing Tabelle zeigen die bei dir ob der Fehlermelsung natürlich fehlerhaft ist !
Eine Fehleranalyse ist so nicht gerade einfach da wir die Kristallkugel bemühen müssen. :-( face-sad
Leider funktioniert die Verbindung aus Netzwerk 1 zu Netzwerk 2 nach wie vor nicht.
Klar...siehe Routing Fehlermeldung des Clients oben !!! Da fehlt die Route !
Scheinbar weiß die FRITZ!Box nicht, wohin mit dem Paket. So sieht es zumindest für mich aus.
Ist möglich ! Wenn du natürlich die oben angegebenen 2 statischen Routen ! in jeder der FritzBoxen vergessen hast ist es logisch das es nicht klappt ! Sind die eingetragen ?!
Knackpunkt ist aber der OVPN Client wegen der fehlenden Route !
So sähe eine saubere und korrekte RasPi Client Konfig aus:
dev tun
proto udp
remote <FritzBox_WAN_IP> 1194

ca keys/ca.crt
cert keys/client1.crt
key keys/client1.key
cipher AES-256-CBC
auth SHA1

auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup

persist-tun
persist-key
mute-replay-warnings

verb 1
pull
route 192.168.182.0 255.255.255.0
(auth-user-pass auth.cfg)

Das Handling der OVPN Konfig auf dem RasPi unter systemd hast du auf dem Radar ??
Die Client Konfig Datei kommt ins Subdirectory /clients mit entsprechendem Namen.
Start oder Restart des Client Daemon dann immer mit "systemctl start openvpn-client@<Client_Datei_Name>" wenn man Änderungen gemacht hat.
Heisst die Datei also client1.conf dort dann lautet der Befehl um den Daemon nach Änderungen usw. neu zu starten: systemctl restart openvpn-client@client1
Klever ist es beim ersten Testen von Konfig Dateien den Daemon zu stoppen (systemctl stop openvpn) und den OVPN Client dann immer manuell zu starten ! (openvpn --config /etc/openvpn/clients/client1.conf)
Das sollte man mit Root Rechten machen also immer sudo su VOR dem manuellen Start !
Dann sieht man ggf. vorhandene Fehlermeldungen gleich auf der Konsole und kann diese korrigieren. (Stop einfach mit <ctrl> c)
Rennt der manuelle Start fehlerfrei, kann man den Daemnon mit systemctl start openvpn-client@client1 dann wieder im Hintergrund starten. ;-) face-wink

So sähe dein Netzwerk IP technisch aus wenn du alles richtig und sauber konfiguriert hast:

ovpn-router
Mitglied: techSmile
techSmile 23.02.2020 um 14:21:09 Uhr
Goto Top
Hallo,

ich melde mich wieder, da ich leider für das Problem nach wie vor keine Lösung habe.
In der FRITZ!Box 7490 auf der OVPN-Serverseite wurden die Routen entsprechend eingetragen, doch leider gibt ping oder tracert direkt aus,
dass das Zielnetz nicht erreichbar wäre (mit einer öffentlichen IPv4 Adresse der Telekom)

Leider weiß ich nicht, woran es liegt. Ich habe alles so umgesetzt wie es hier beschrieben wurde.

Nochmal kurz zur Erläuterung was funktioniert:
Ping von Netz hinter FRITZ!Box 6490 in das Netz hinter der 7490 funktioniert.
Ebenso erreiche ich den VPN-Client (192.168.15.4) vom Netz der FRITZ!Box 7490 ausgehend.

Was funktioniert nicht:
Erreichen des Netzes hinter der 6490 (192.168.180.0/24)
Auch nicht, wenn ich mich direkt auf die Synology aufschalte und darüber versuche beispielsweise die 192.168.180.1 zu erreichen.

Gibt es eventuell noch etwas, was übersehen wurde und zum Ziel führt?

Danke vorab!
Mitglied: aqui
aqui 24.02.2020 aktualisiert um 09:20:01 Uhr
Goto Top
Ping von Netz hinter FRITZ!Box 6490 in das Netz hinter der 7490 funktioniert.
Das bedeutet ja schon mal das generell alles soweit mit der reinen LAN zu LAN Kopplung des OpenVPN sauber funktioniert !
Ebenso erreiche ich den VPN-Client (192.168.15.4) vom Netz der FRITZ!Box 7490 ausgehend.
Gut, besagt das der VPN Client sauber eine VPN Verbindung mit dem Server hergestellt hat.
Was funktioniert nicht: Erreichen des Netzes hinter der 6490 (192.168.180.0/24)
Mmmhhh...
Das widerspricht jetzt aber diametral dem was du eben oben gesagt hast: (Zitat) "Ping von Netz hinter FRITZ!Box 6490 in das Netz hinter der 7490 funktioniert."
Damit bestätigst du doch ganz klar das eine Kopplung der beiden LAN Netze .180.0 und .182.0 fehlerfrei funktioniert ?!
Oder jetzt mir einmal dann doch nicht. Was denn nun wirklich ??
Gibt es eventuell noch etwas, was übersehen wurde und zum Ziel führt?
Dazu müssten wir jetzt im freinen Fall raten oder die berühmte Kristallkugel bemühen denn du hast es versäumt hier einmal die OVPN Konfig Dateien deines Servers und des Clients zu posten.
Das hätte uns in die Lage versetzt hier zielführend zu helfen. Der Fehler steckt dort. Entweder in einem Konfig Fehler auf Serverseite oder Clientseite. Worst Case auf beiden... Leider hat es bei dir dazu nicht gereicht... :-( face-sad
Oder wie hattest du dir sonst vorgestellt hier eine Lösung zu finden ? Hand auflegen geht ja auch nicht....

Nur mal nebenbei:
Warum machst du generell diesen Aufwand mit externem VPN. Klar geht das natürlich auch aber wäre es doch nicht erheblich einfacher die VPN Funktion der FritzBoxen zu nutzen und diese zu koppeln ? Das ist mit 3 Mausklicks im Router GUI erledigt !
Mitglied: techSmile
techSmile 24.02.2020 um 12:28:50 Uhr
Goto Top
Hallo nochmal.

Vielen Dank für die Rückmeldung!

Grundsätzlich sollte die LAN-LAN Kopplung funktionieren, wenn ich beim Pingen eine Rückantwort erhalte, doch irgendwas schein faul zu sein.


Nochmal als Erläuterung, da da wohl etwas missverstanden wurde:

Die Geräte hinter der Fritzbox 7490 erreichen die Geräte hinter der Fritzbox 6490 nicht. In umgekehrter Reihenfolge klappt es aber.
Zudem erreiche ich das VPN-GW (Raspi), wenn ich vom Client im Netz der 7490 pinge.

Im Anhang eine Grafik um das Ganze zu veranschaulichen:
netzplan_aktuell

Leider kann ich die VPN-Funktion der FritzBoxen nicht nutzen, da ich beim Unitymediaanschluss nur eine IPv4 DS-Lite Adresse habe.

Die VPN-Configs kommen separat.
Mitglied: aqui
aqui 24.02.2020 aktualisiert um 12:54:02 Uhr
Goto Top
Die Geräte hinter der Fritzbox 7490 erreichen die Geräte hinter der Fritzbox 6490 nicht. In umgekehrter Reihenfolge klappt es aber.
Das zeigt aber ganz deutlich das es NICHT ein VPN Fehler ist sondern vermutlich eins der lokalen Firewalls.
Ein Ping basiert auf dem ICMP Protokoll indem der Sender ein ICMP Echo Request Paket sendet und daraufhin der Empfänger ein ICMP Echo Reply Paket an den Sender zurücksendet.
Wenn also ein Ping in nur eine Richtung fehlerfrei klappt, dann kommen Pakete an und gehen auch zurück was auf eine fehlerfrei, bidirektionale Verbindung schliessen lässt. Andernfalls würde kein fehlerfreier Ping angezeigt.
Wenn es einseitig NICHT geht, dann ist das in der Regel zu 99% eine fehlerhafte Firewall Konfiguration. In aller Regel die der Windows Komponenten, denn dort lauern gleich 2 böse (Firewall) Fallen:
  • ICMP ist in Windows bzw. der lokalen FW dort generell IMMER geblockt und muss im Firewall Setup erst freigeschaltet werden ! https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ... Ohne das geht es nicht.
  • Absender IP Adressen aus fremden IP Netzen werden ebenfalls generell geblockt ! Auch hier müssen diese Netze (oder generell alles) aus fremden Netzen explizit immer erst freigeben werden. (Firewall mit erweiterter Sicherheit... Setup)
Fazit:
Wie bereits gesagt wären die Routing Setups beider Fritzboxen (GUI Screenshot) und die OVPN Konfig Files hier hilfreich.
Du hast aber sehr wahrscheinlich gar kein VPN Problem, sondern ganz sicher eins deiner lokalen Firewalls !
Leider kann ich die VPN-Funktion der FritzBoxen nicht nutzen, da ich beim Unitymediaanschluss nur eine IPv4 DS-Lite Adresse habe.
Das ist natürlich Unsinn aus VPN Sicht, denn wenn der Unitymedia Anschlus als IPsec Initiator arbeitet (also der, der die VPN Tunnelverbindung initiiert) hat er ja im CGN des Providers dann einen gültigen Session Table Eintrag und die Telekom Seite kann darauf antworten ! Zwingend ist hier nur NAT Traversal im IPsec (UDP 4500) was die FBs aber im Default schon machen.
Das gleiche Problem hättest du doch dann logischerweise mit OpenVPN auch !!
Hier irrst du also gewaltig mit deiner Annahme... Auch ein reines FB VPN kommt da fehlerfrei zustande.
Aber wie bereits gesagt klappt es mit dem Umweg OpenVPN ja auch wie du siehst. Nur das dein Problem sehr wahrscheinlich gar nicht das VPN selber ist sondern, wie leider fast immer, Winblows.
Mitglied: techSmile
techSmile 24.02.2020 aktualisiert um 17:35:15 Uhr
Goto Top
Hallo nochmal.

ein Problem mit den lokalen Firewalls schließe ich aus, da ich auch über den VPN-Server (Ping von Synology in das Netz hinter der 6490) kein Gerät erreiche. Wenn ich von der Synology per Putty versuche den Raspi zu pingen, sollte es ja eigentlich funktionieren, wie soll es dann die Firewall sein?

Anbei die Routen aus den FBs:
fb-6490
FB 6490

fb-7490
FB 7490

Server Configfile:

CCD für den Client:


Client:

Ich möchte ungern die Fritz LAN-LAN Kopplung nutzen.
Habe ich schonmal probiert nie festlegen können, welche Box nun die Verbindung aufbauen soll.
Das ist schlecht, denn somit bricht auch immer die Internetverbindung ab.
Hatte dann auch keine Lust mich mit dem Thema weiter zu befassen,
da ich so oder so einen OpenVPN-Server betreiben wollte.

Viel Erfolg beim Fehler finden :-) face-smile
Danke
Mitglied: aqui
aqui 24.02.2020 aktualisiert um 18:44:48 Uhr
Goto Top
Fehler Server Konfig:
  • Ein Push Route auf das eigene interne OVPN IP Netz ist Quatsch und kontraproduktiv, solltest du zwingend entfernen
  • Grober Fehler trotz mehrfacher Hinweise oben: Die Server Kernel Route ins remote Client Netz fehlt !!! route 192.168.180.0 255.255.255.0 ! Damit kann es per se nicht funktionieren !
  • Weuter grober Fehler im ccd Teil: Dort steht eine völlig falsche Hostroute und keine Netzwerk Route. Ein weiterer Kardinalsfehler trotz mehrfacher Hinweise oben ! :-( face-sad Richtig ist: iroute 192.168.180.0 255.255.255.0
  • Receive und Sendbuffer Tuning sollte man erstmal weglassen (Default) und nur dann konfigurieren wenn man es wirklich braucht.
Rest ist richtig, auch die lokale FB Konfig.

Was eigentlich auch nicht gehen kann:
  • Der Server arbeitet mit proto udp6 erzwungen mit IPv6 !
  • Der Client hingegen mit proto udp4 erzwungen mit IPv4 !
Normal sollten die niemals so zueinander kommen, denn ein IPv4 Host kann logischerweise niemals direkt mit einem IPv6 Host kommunizieren. Man kann auch nicht direkt mit einem v4 Browser auf einen v6 Webserver zugreifen. Das weiss auch ein Laie.
Gravierend sind aber abgesehen von dem v4/v6 Protokoll Mismatch die Konfig Fehler des Servers und das trotz der expliziten Konfig Beispiele von oben :-( face-sad
Mitglied: techSmile
techSmile 24.02.2020 um 19:33:21 Uhr
Goto Top
Hallo nochmal,

fürs UDPv6 hatte ich noch in Planung OVPN im DS-Modus zu betreiben. Ändere ich aber.

Melde mich wieder mit Ergebnissen.

Danke! Habe mich eine Weile nicht mehr damit befasst, den Thread nicht mehr gelesen und ändere das zeitnah ab.
Mitglied: techSmile
techSmile 24.02.2020 um 22:22:26 Uhr
Goto Top
So jetzt, alles entsprechend umgesetzt.

Ping direkt von der Synology (Putty) in Richtung 192.168.180.1 funktioniert nun,
doch leider klappt es nicht von den Clients im Netzwerk 192.168.182.0/24.

Noch eine Idee?
Folgende Fehlermeldung erhalte ich sowohl von Linux als auch Windows: Antwort von 62.155.245.142: Zielnetz nicht erreichbar.
Firewall ist aus.
Mitglied: techSmile
techSmile 24.02.2020 um 22:26:30 Uhr
Goto Top
Nach Hinzufügen einer statischen Route unter Windows funktioniert das Ganze nun.
Wie bekomme ich es so hin, dass dies automatisiert funktioniert?

In der Fritzbox ist doch die statische Route eingetragen.
Mitglied: aqui
aqui 25.02.2020 aktualisiert um 09:31:50 Uhr
Goto Top
Statische Route auf dem Windows Server ist eigentlich Blödsinn, denn wir gehen hier mal davon aus das der, wie üblich, eine Default Route auf die lokale FritzBox 192.168.182.1 hat, oder etwa nicht ??
Die FritzBox "kennt" dann doch als zentraler Router im .182.0er Netz alle Routen in dein gesamtes Netzwerk !! Sie sind ja oben dort auch richtig eingetragen !
Eine Default Route reicht dort also vollends auf allen Komponenten im .182.0er Netz !
Wie bekomme ich es so hin, dass dies automatisiert funktioniert?
Was genau meinst du mit "automatisiert" ?? Das sich der Webserver automatisch startet wenn du durch die Haustür kommst ?
Sorry, aber ein bischen genauer wenn es geht... ;-) face-wink
Mitglied: techSmile
techSmile 25.02.2020 um 09:41:10 Uhr
Goto Top
Hallo aqui,

gern möchte ich das mit der statischen Route vermeiden, da ich sonst allen Clients im Netzwerk die Route mitgeben müsste.
Ich erreiche ja zum Beispiel den Raspberry Pi über 192.168.15.4, aber nicht über 192.168.180.2.

In der FRITZ!Box sind die Routen entsprechend eingerichtet.

Anbei mal die Routing-Tabelle unter Windows:

Kann es sein, dass die FRITZ!Box nicht weiß, wohin die Anfrage soll, da an der Synology LA aktiviert ist und somit die 192.168.182.3 doppelt in der Netzwerkübersicht vorkommt?
Mitglied: techSmile
techSmile 25.02.2020 um 10:10:38 Uhr
Goto Top
Habe versuchsweise nun LA deaktiviert, doch leider hat das auch nichts gebracht.

Anbei noch Traceroute:
Mitglied: aqui
aqui 25.02.2020 um 14:51:12 Uhr
Goto Top
gern möchte ich das mit der statischen Route vermeiden, da ich sonst allen Clients im Netzwerk die Route mitgeben müsste.
Das ist ja auch völliger Blödsinn, denn es reicht wenn jeder Client eine Default Route auf die FB hat !!
Diese "kennt" doch alle Netze und routet sie entsprechend. Zusatzrouten auf Endgeräten sind damit dann überflüssiger Unsinn !
da an der Synology LA aktiviert ist und somit die 192.168.182.3 doppelt in der Netzwerkübersicht vorkommt?
Mit LA meinst du Link Aggregation ??
Wenn die IP .3 doppelt auftaucht hast du die LA dann vollkommen falsch eingerichtet !!
LACP Link Aggregation ist eine reine Layer 2 Geschichte die entsprechend auch so eingerichtet werden muss.
Beide Ports bündelt man am NAS in einen LACP LAG und entsprechend macht man dies auf der "anderen Seite" sprich dem Switch !
Hier mal am Beispiel eines QNAP NAS:
lag1
lag2

Dazu dann das Pendant auf der Switchseite:
lag3

Da ist vermutlich also bei dir auch schon was gründlich schiefgegangen ! :-( face-sad
Anbei mal die Routing-Tabelle unter Windows:
In welchem Netz ?? Vermutlich (geraten) wohl .180.0, oder ?
WO kommen dort die Routen ins .182.0er und ins .56.0 IP Netz her ???
Die dürften da NICHT stehen, das ist grundsätzlich falsch. Man kann nur vermuten das du diese Routen irgendwann mal mit dem Kommando route add und dem Parameter "-p" manuell dazukonfiguriert hast und vergessen hast dann wieder zu entfernen und es oben auch nicht erwähnt !!! Damit hast du die Hilfe Community dann hier wissentlich ins Messer laufen lassen. :-( face-sad
Entferne überall diese Routen. Belasse einzig und allein NUR die Default Routen zur jeweiligen FritzBox in ALLEN Endgeräten, dann klappt das auch sofort !
Mitglied: techSmile
techSmile 25.02.2020 um 15:49:26 Uhr
Goto Top
Hallo nochmal. Die Routingtabelle ist vom Client (192.168.182.2)...

Lösche alles mal raus und versuche es erneut. LA habe ich auf der Synology deaktiviert und stecke heute Abend Zuhause das zweite Netzwerkkabel aus.
Habe LA einfach eingerichtet (Adaptive Load Balancing), der Switch untersützt das aber nicht.

Melde mich wieder und gebe Rückmeldung, wie es dann aussieht.

Grüße
Mitglied: techSmile
techSmile 26.02.2020 aktualisiert um 16:27:49 Uhr
Goto Top
Hallo aqui,

habe nun die Routen entsprechend angepasst, bekomme aber leider weiterhin keine Verbindung zur Box.

Ping gibt folgendes aus:

Traceroute:

Wenn ich traceroute unter Linux anwende, erhalte ich ebenfalls keine Verbindung.
Von der Synology (192.168.182.3) direkt über SSH kann ich die 192.168.180.1 aber anpingen.

So langsam bin ich am verzweifeln.
Mitglied: aqui
Lösung aqui 28.02.2020, aktualisiert am 04.09.2021 um 14:18:01 Uhr
Goto Top
Damit das Drama jetzt hoffentlich hier mal ein Ende hat.... ;-) face-wink

1.) VPN-Netz Aufbau:
Simulation genau deines Netz Aufbaus. (die 10er IPs simulieren die Internet IPs !)
Der OVPN Server auf dem Synology NAS ist hier ersetzt durch einen Raspberry Pi 4. Was ja nur kosmetisch ist. Was da als OVPN Server OS und Hardware werkelt ist ja vollkommen Wumpe, denn die OVPN Konfig ist ja immer gleich. Ein großer Vorteil bei OVPN Installationen. ;-) face-wink
Open VPN Client ist ein Raspberry Pi Zero mit Ethernet_USB_OTG_Adapter. Auch diese Hardware ist egal, denn auch da ist die Konfig identisch.

ovpn-test

(Optional könnte man noch das 172.18.18.0 /24 in die statischen Routen aufnehmen. Es ist aber in einer reinen LAN zu LAN VPN Lösung nicht erforderlich. Nur dann, wenn sich zusätzlich auch remote Clients einwählen.)

2.) OpenVPN Konfigurations Datei Server (server.conf ):

dev tun
proto udp4
port 1194
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/test-server.crt
key /etc/openvpn/server/test-server.key
dh /etc/openvpn/server/dh.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 172.18.18.0 255.255.255.0
topology subnet
push "topology subnet"
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
push "route 192.168.1.0 255.255.255.0"
route 192.168.188.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/csconf


Die Client spezifischen Routing Konfig Kommandos auf dem Server liegen in den Client spezifischen Dateien unter /etc/openvpn/csconf/ auf dem Server. Z.B. "client01" ist hier im Beispiel der Common Name im Zertifikat des ersten Clients und entsprechend heisst auch die Client 1 spezifische Datei dann client01.
Wichtig und entscheident ist hier welche Common Names in den Client Zertifikaten pro Client definiert wurden.
(Wenn es nur einen einzigen Routing Client bei LAN zu LAN gibt ist das irrelevant und kann dann natürlich entfallen. Es reicht dann die Route in der Server Konfig.)

ifconfig-push 172.18.18.2 255.255.255.0
iroute 192.168.188.0 255.255.255.0


ACHTUNG !: Auf dem Server muss zwingend das IPv4 Forwarding (Routing) aktiviert werden !! Logisch, denn sowohl OpenVPN Server als auch OpenVPN Client müssen ja zwischen ihrem LAN Interface und dem VPN Tunnelinterface den Traffic routen !
Sie sind quasi als weitere IP Router in den jeweiligen Netzen zu sehen.
Bei Linux basierten Plattformen wie deinem Synology NAS und den RasPi's hier, ist das die Zeile net.ipv4.ip_forward=1 die in der Datei /etc/sysctl.conf entkommentiert ( "#" entfernen) werden muss. Danach müssen die Systeme rebootet werden um es zu aktivieren.

3.) OpenVPN Konfigurations Datei Client (client.conf ):

dev tun
proto udp4
client
remote 10.99.1.99 1194
(Muss in der Praxis mit der Internet IP oder DynDNS Namen des Routers 1 ersetzt werden !)
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client01.crt
key /etc/openvpn/client/client01.key
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
persist-tun
persist-key
mute-replay-warnings
pull


AUCH HIER GILT: IPv4 Forwarding (Routing) muss hier ebenfalls aktiviert werden !!
(Entkommentieren von net.ipv4.ip_forward=1 und Reboot !!)

4.) Ping Checks:
Vom Client im 192.168.188.0er Netz auf das remote Router 1 LAN Interface
Vom Client im 192.168.1.0er Netz auf das remote Router 2 LAN Interface

Fazit:
Das ganze war in nicht einmal 20 Minuten am Fliegen und...
Works as designed !!! :-D face-big-smile
Beschreibt so auch die offizielle OpenVPN Doku unter:
https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-t ...

(Nebenbei bemerkt sind solche Designs zwar problemlos machbar und funktionieren auch problemlos. Viele NAS Benutzer haben ja quasi mit dem Betrieb eines NAS immer auch einen (O)VPN Server über den App Store des NAS Herstellers nebenbei.
Sie haben aber immer wegen der innen, im lokalen LAN liegenden VPN Komponenten, einige sicherheitstechnische Nachteile. Auf der OVPN Server Seite muss ungeschützter Internet Traffic via Port Forwarding im Router/Firewall auf das lokale LAN gelassen werden was generell keine gute Idee ist unter Sicherheits Aspekten. Das Risiko muss aber jeder für sich abschätzen.
Ein besseres VPN Design ist immer, sofern man es denn kann, die (O)VPN Funktion auf den Internet Routern oder Firewall direkt in der Peripherie laufen zu lassen. So bleibt ungeschützter Verkehr immer draußen.)

Mitglied: techSmile
techSmile 01.03.2020 um 16:16:21 Uhr
Goto Top
Hallo aqui,

funktioniert leider trotz deiner Hilfe nicht.
Ich habe auch nochmal die Routingtabelle der Synolgy überprüft, aber auch hier keine Auffälligkeiten.

Deshalb mache ich nun ein Ticket bei AVM auf, da scheinbar irgendwas mit dem Routing der Box nicht stimmt.
Die Pakete ins Netz 192.168.180.0/24 werden direkt ins Internet geroutet, hingegen kann ich das VPN-GW im VPN Netz mit der IP 192.168.15.4 direkt erreichen.

Sobald ich in den Endgeräten eine statische Route eintrage, funktioniert alles. Was ist da los?

Bin gespannt, ob eventuell ein Bug in der AVM-Firmware dafür verantwortlich ist (Nutze FRITZ!Labor)

Viele Grüße
Mitglied: aqui
Lösung aqui 01.03.2020 aktualisiert um 18:27:15 Uhr
Goto Top
funktioniert leider trotz deiner Hilfe nicht.
Sorry, aber dann sind wir hier mit der Forenhilfe am Ende ! Du kannst ja oben selber an dem dort detailiert geposteten, einfachen OVPN Setup, was absolut fehlerfrei funktioniert, selber sehen das das im Grunde kein Hexenwerk ist und die Konfig eigentlich recht banal.
Viele Fehler kann man da wahrlich nicht machen.....
Habs hier parallel auch nochmal an einem QNAP NAS getestet um ganz sicherzugehen. Funktioniert fehlerlos...!
Wie bereits oben gesagt ist es sehr wichtig das das IPv4 Forwarding auf deinem NAS aktiviert ist.
Mit einem cat /proc/sys/net/ipv4/ip_forward auf der SSH Shell (CLI) sagt dir das dein Synology. Als Ergebnis bzw. Inhalt dieser Datei muss dort eine "1" zurückkommen. Kommt stattdessen eine "0" ist das IPv4 Forwarding (Routing) deaktiviert und dann ist es klar das es nicht laufen kann.
Hoffen wir hier also mal das du das wasserdicht auf dem Synology geprüft hast !? Das Kommando dürfte da identisch zu einem QNAP sein.
Wichtig ist zudem das zusätzlich natürlich auch dein OVPN Client IPv4 Forwarding aktiviert hat !!
Sobald ich in den Endgeräten eine statische Route eintrage, funktioniert alles. Was ist da los?
Das wäre natürlich Unsinn, denn das konterkariert ja einen Router. Muss man auch nicht machen.
Das würde in der Konsequenz aber tatsächlich bedeuten das das statische Routing in der FB defekt ist. Möglich das das z.B. in einer gebrandeten Provider FB deaktiviert wurde. Musst du dann klären über die Hotline.

So sollte deine OpenVPN Server Konfig Datei aussehen:
dev tun
proto udp4
port 1194
cipher AES-256-CBC
auth SHA1
server 192.168.15.0 255.255.255.0
topology subnet
push "topology subnet"
dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh1024.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key
push "route 192.168.182.0 255.255.255.0"
route 192.168.180.0 255.255.255.0

max-clients 15
persist-tun
persist-key
verb 3
reneg-sec 0
username-as-common-name
duplicate-cn
client-config-dir ccd

Im /ccd Verzeichnis eine Datei genau wie der Common Name des Clients mit dem Inhalt:
ifconfig-push 192.168.15.2 255.255.255.0
iroute 192.168.180.0 255.255.255.0


Die statischen Routen auf der FritzBox auf der OpenVPN Server Netz Seite lauten:
192.168.180.0, Maske: 255.255.255.0, Gateway: 192.168.182.3
192.168.15.0, Maske: 255.255.255.0, Gateway: 192.168.182.3
(Optional, bei LAN zu LAN VPN nicht zwingend erforderlich)

Fertig, das wars.
Das funktioniert (getestet) fehlerlos.
(Port TCP 4433 sollte man nicht verwenden, denn das ist ein offizell von der IANA vergebener Port !! Siehe: https://www.iana.org/assignments/service-names-port-numbers/service-name ...
Besser ist dann einen Port aus der Range der freien Ephemeral_Ports 49152 to 65535 zu verwenden.
Sinnvoll wäre dann z.B. 64433.
Mitglied: techSmile
techSmile 27.03.2020 um 14:23:39 Uhr
Goto Top
Eine kurze Rückmeldung.

Leider lag es an AVM, da sie die Adresse 192.168.180.x irgendwie über das DSL-Modem routen.
Drum habe ich gebeten, dies in Ihren Hilfebereich mit aufzunehmen.

Nun funktioniert alles. Vielen Dank an aqui!

Grüße
Mitglied: Reku66
Reku66 30.12.2020 um 19:50:11 Uhr
Goto Top
Hallo techSmile,

ich stehe gerade vor dem gleichen Problem und könnte Hilfe gbrauchen. Ich habe eine Synology als VPNServer und am entfernten Ort ebenfalls eine Synology als VPNClient. Die VPN Verbindung steht, jedoch kann ich die Geräte hinter dem VPNClienten (zB FritzBox, IPCams, Solarlog) nicht erreichen.

Ich habe alles soweit übernommen wie in der detaillierten Anleitung von "aqui".
Es geht um den Befehl "client-config-dir ccd" in der Datei openvpn.conf der Synology (Server). Wo ist der Ordner "ccd" anzulegen, im root Verzeichnis oder im openvpn Verzeichnis. Und um die Datei mit dem Clientnamen zu erstellen, benötige ich ja den common name des Zertifikates des Clienten, ist das der Hostname?

VG
Mitglied: aqui
aqui 30.12.2020 um 19:57:23 Uhr
Goto Top
Du legst ihn im OpenVPN Verzeichnis an. Letztlich ist es egal wo es liegt, denn du verweist in der Konfig ja explizit auf den kompletten Pfad. Es macht aber natürlich logisch Sinn ihn auch in das OpenVPN Verzeichnis /etc/openvpn zu legen !
benötige ich ja den common name des Zertifikates des Clienten, ist das der Hostname?
Das ist der Name den du bei der Client Zertifikats Generierung dem Zertifikat als Common Name mitgegeben hast.
Guckst du hier:
https://administrator.de/tutorial/openvpn-server-installieren-pfsense-fi ...
Mitglied: techSmile
techSmile 30.12.2020 aktualisiert um 20:51:34 Uhr
Goto Top
Hallo,

das mit dem Zertifikat ist bei Synology so eine Sache. Nimm einfach das, was bereits in der Host-Config steht. Verändern musst du hierbei nichts.
Den Common-Name habe bei mir gar nicht angepasst und es funktioniert alles seit März ohne Probleme.

Zu beachten ist, dass du explizit einen Site-to-Site User unter DSM erstellst und diesen nur dafür verwendest, da es sonst zu Problemen bei der IP-Adressvergabe des DHCP-Severs der Synology kommen kann. Ich habe hierbei für meinen Laptop und für mein Handy weitere User angelegt.

Der CCD Ordner ist unter /var/packages/VPNCenter/etc/OpenVPN zu erstellen und die Dateien dann je nach Synologybenutzer

Beispiel:
/var/packages/VPNCenter/etc/openvpn/ccd/techsmile

In die Datei techsmile (ohne Dateiendung) dann die Parameter eintragen. Die Benamung der Datei erfolgt je nach Synologybenutzer. Einen Common-Name musst du hier nicht eintragen.

Bei Bedarf kann ich dich gerne mit deiner Konfiguration unterstützen.

Beachte bitte, dass es schon etwas leistungsstärkere Synologys sein sollten, da bei mir mit 100 MBits Transferrate die CPU-Auslastung gerne mal auf 30-40% ansteigt. Ansonsten wird die Geschwindigkeit des Tunnels stark eingeschränkt.

Viele Grüße
Mitglied: Reku66
Reku66 31.12.2020 um 07:46:39 Uhr
Goto Top
Moin,

vielen Dank für die schnelle Rückmeldung.
Zitat von @aqui:

Du legst ihn im OpenVPN Verzeichnis an. Letztlich ist es egal wo es liegt, denn du verweist in der Konfig ja explizit auf den kompletten Pfad. Es macht aber natürlich logisch Sinn ihn auch in das OpenVPN Verzeichnis /etc/openvpn zu legen !
So müsste es korrekterweise ausgeführt werden. Die Synology ist da wohl besonders eigen, daher bin ich zunächst der Beispielkonfiguration der Synology nachgegangen (openvpn-sample.conf), dort wird auf die Erstellung des Ordners "ccd" hingewiesen ohne Pfadangabe.
Durch den zusätzlichen Hinweis von techSmile, den Benutzernamen als Dateinamen für die Clientdatei im Ordner "ccd" zu verwenden, klappt es tatsächlich. Allerdings musste ich die Ausführung "ifconfig-push 10.8.0.6 255.255.255.0" (=IP meines Clienten) in der clientspezifischen Datei weglassen, damit es funktioniert.

VG
Mitglied: Reku66
Reku66 31.12.2020 um 07:52:24 Uhr
Goto Top
Zitat von @techSmile:

Hallo,

das mit dem Zertifikat ist bei Synology so eine Sache. Nimm einfach das, was bereits in der Host-Config steht. Verändern musst du hierbei nichts.
Den Common-Name habe bei mir gar nicht angepasst und es funktioniert alles seit März ohne Probleme.

Zu beachten ist, dass du explizit einen Site-to-Site User unter DSM erstellst und diesen nur dafür verwendest, da es sonst zu Problemen bei der IP-Adressvergabe des DHCP-Severs der Synology kommen kann. Ich habe hierbei für meinen Laptop und für mein Handy weitere User angelegt.

Der CCD Ordner ist unter /var/packages/VPNCenter/etc/OpenVPN zu erstellen und die Dateien dann je nach Synologybenutzer

Beispiel:
/var/packages/VPNCenter/etc/openvpn/ccd/techsmile

In die Datei techsmile (ohne Dateiendung) dann die Parameter eintragen. Die Benamung der Datei erfolgt je nach Synologybenutzer. Einen Common-Name musst du hier nicht eintragen.

Bei Bedarf kann ich dich gerne mit deiner Konfiguration unterstützen.

Beachte bitte, dass es schon etwas leistungsstärkere Synologys sein sollten, da bei mir mit 100 MBits Transferrate die CPU-Auslastung gerne mal auf 30-40% ansteigt. Ansonsten wird die Geschwindigkeit des Tunnels stark eingeschränkt.

Viele Grüße

Vielen Dank auch an techSmile,

es funktioniert mit der Benamung der Datei mit dem Benutzernamen in der Synology. Ich probiere noch ein wenig aus bzw. ich sende zeitnah mal die Inhalte der Konfig-Dateien.

VG
Mitglied: techSmile
techSmile 31.12.2020 um 15:05:27 Uhr
Goto Top
Hallo,

vielen Dank für deine Rückmeldung.
Freut mich, dass es auch bei dir klappt.

Wegen nicht funktionierender IP-Vergabe, prüfe mal ob die IP-Adresse bei den aktuellen Sitzungen im VPN-Center bereits vergeben ist. Dies führte bei mir dazu, dass die Verbindung zwar aufgebaut wird, aber kein Traffic möglich ist.

Bei mir sieht das dann so aus und funktioniert mit der statischen IP-Vergabe für Clients.

d9d066f4-037d-492e-8139-30ab3aa2e81b.
Mitglied: Reku66
Reku66 02.01.2021 um 14:53:30 Uhr
Goto Top
Hallo,

so sieht meine VPN Konstruktion aus.
Vielleich könnte Aqui wenn möglich auf die Schnelle mal drüber schauen ob alles so passig ist bw. Verbesserungsoptionen vorhanden sind.
Es funktioniert soweit alles, Zugriff auf die Clienten, den Router und die NAT Geräte dahinter.

Vielen Dank und VG
grafikvpn
Mitglied: Reku66
Reku66 05.01.2021 um 13:12:20 Uhr
Goto Top
Hallo,

vielleicht kann mir noch jemand beantworten, ob und wie es möglich ist, dass nur ein spezieller NAT-Client des lokalen Subnetzes über VPN rootet und der Rest des Subnetzes nicht.

Beispiel:
Laptop am Standort2 (Netzt2) mit der lokalen IP 192.168.10.21 soll das VPN Gateway des OpenVPN Servers (10.8.0.1) nutzen, damit sämtlicher Verkehr über VPN Läuft. Die anderen Nat-Clienten in diesem Netz sollen ganz normal das lokale Gateway der Fritzbox (192.168.10.1) fürs Internet nutzen.

Aktuell ist in der client.conf der Eintrag "redirect-gateway def1" auskommentiert, was ja bedeutet, dass alles aus Netz2 über VPN läuft.
Die Einträge
route 192.168.178.0 255.255.255.0 und
route 192.168.20.0 255.255.255.0
sollen die anderen lokalen Subnetze erreichbar machen.

Welchen Eintrag müsste ich noch in der client.conf hinzufügen oder ändern?

VG
Mitglied: aqui
aqui 05.01.2021 aktualisiert um 16:37:44 Uhr
Goto Top
Ja, das geht natürlich.
Mit 2 einfachen Optionen kann man das erreichen:
  • 1.) Eine IP Access Liste auf dem Router die nur die Hostadresse 192.168.10.21 ins Zielnetz 10.8.0.0/24 erlaubt.
  • 2.) Indem du die statische Route auf dem Router zum OpenVPN Server löscht und diese Route nur bei dem Client direkt einträgst. route add 10.8.0.0 mask 255.255.255.0 <ip_ovpn_server> -p (Beispiel für einen Windows Client).
Bei 2. können Clients im Netz dann generell nicht mehr den OVPN Server erreichen. Mit Ausnhame des dedizierten Clients der eine eigene Route dahin hat.
Aktuell ist in der client.conf der Eintrag "redirect-gateway def1" auskommentiert, was ja bedeutet, dass alles aus Netz2 über VPN läuft.
Nein, das ist nicht ganz richtig !
Bei einem Gateway Redirect des Clients mit "redirect-gateway def1" wird ALLES an Traffic des Clients in den Tunnel geroutet, also auch lokaler Internet Trafic usw. Das Default Gateway dieses Clients ist dann nicht mehr der lokale Router sondern der VPN Tunnel.
Nur mit einem "push route..." Kommando machst du ein Split Tunneling und routest dann rein nur relevanten Traffic für die angegebenen remoten IP Netze in den Tunnel. Lokaler und Internet Traffic bleibt dann auch lokal.

Bitte lies dir das hiesige OpenVPN Tutorial zu dem Thema genau durch !! Da ist das alles haarklein erklärt !
https://administrator.de/tutorial/merkzettel-vpn-installation-openvpn-56 ...
Mitglied: Reku66
Reku66 06.01.2021 um 08:06:10 Uhr
Goto Top
Moin,
vielen Dank erstmal.
* 1.) Eine IP Access Liste auf dem Router die nur die Hostadresse 192.168.10.21 ins Zielnetz 10.8.0.0/24 erlaubt.
Bedeutet das eine neue statische Route in der Fritzbox?
* 2.) Indem du die statische Route auf dem Router zum OpenVPN Server löscht und diese Route nur bei dem Client direkt einträgst. route add 10.8.0.0 mask 255.255.255.0 <ip_ovpn_server> -p (Beispiel für einen Windows Client).
Bei 2. können Clients im Netz dann generell nicht mehr den OVPN Server erreichen. Mit Ausnhame des dedizierten Clients der eine eigene Route dahin hat.
Das wäre keine so gute Alternative für mich. Aber ich meine, dass Router mit openWRT (zB Asus oder Netgear) auf ihrem Gerät die LAN Ports unterschiedlich bestimmen können, also zB LAN1-->sämtlicher traffic über VPN und LAN2-4--> lokal. Das wäre für mich denkbar, da der Windows PC als VPNClient zeitnah ausgetauscht werden soll.
Aktuell ist in der client.conf der Eintrag "redirect-gateway def1" auskommentiert, was ja bedeutet, dass alles aus Netz2 über VPN läuft.
Nein, das ist nicht ganz richtig !
Bei einem Gateway Redirect des Clients mit "redirect-gateway def1" wird ALLES an Traffic des Clients in den Tunnel geroutet, also auch lokaler Internet Trafic usw. Das Default Gateway dieses Clients ist dann nicht mehr der lokale Router sondern der VPN Tunnel.
Ja richtig, Ziel soll sein, mit dem Laptop am Standort 2 mit der öffentlichen IP des Standortes 1 im Internet aufzutauchen.
Bitte lies dir das hiesige OpenVPN Tutorial zu dem Thema genau durch !! Da ist das alles haarklein erklärt !
https://administrator.de/tutorial/merkzettel-vpn-installation-openvpn-56 ...
Danke, echt gute und mühsame Arbeit, Respekt. Dazu vielleicht doch noch eine Frage, in der Abbildung unten wird in der Server.conf das IP Netz des VPNServers gepusht (192.168.182.0. ...), außerdem wird beim VPNclienten (RasPi) zusätzlich die Route eingetragen (route 192.168.182.0 ...). Ist das erforderlich, da ja quasi doppelt oder als Alternative gedacht?
beispielaufbau
Mitglied: aqui
aqui 06.01.2021 aktualisiert um 10:43:37 Uhr
Goto Top
Bedeutet das eine neue statische Route in der Fritzbox?
Seit wann haben IP Routen irgendetwas mit IP Access Listen zu tun ??? Kann es sein das du hier etwas gründlich missverstanden hast ? Das sind 2 völlig verschiedene Baustellen.
außerdem wird beim VPNclienten (RasPi) zusätzlich die Route eingetragen (route 192.168.182.0 ...). Ist das erforderlich, da ja quasi doppelt oder als Alternative gedacht?
Da musst du den Kontext des Tutorials richtig zu lesen....
Dieser Route Eintrag im Client ist ausnahmsweise nur deswegen gemacht, weil der Client auch sein eigenes lokales Netzwerk auf die andere Seite routet. Es ist also quasi ein LAN zu LAN Design.
In einem reinen VPN Client Dialin ist das ja nie der Fall, denn du willst ja keinesfalls das dann z.B. das Hotspot Netz im Cafe oder ICE mit in dein Netzwerk geroutet wird. Dort entfällt also natürlich immer dieser Konfig Part.
Das gilt ausschliesslich nur wenn man mit dem Client auch ein Site-to-Site Routing machen will, sonst NICHT.
Mitglied: Reku66
Reku66 06.01.2021 um 16:36:36 Uhr
Goto Top
Seit wann haben IP Routen irgendetwas mit IP Access Listen zu tun ??? Kann es sein das du hier etwas gründlich missverstanden hast ? Das sind 2 völlig verschiedene Baustellen.
Und diese Baustelle ist mir nicht bekannt ;) Gibts da irgendwo eine Anleitung für Fritzbox, evtl. einen Link?

Vielen Dank.
Mitglied: aqui
aqui 06.01.2021 aktualisiert um 17:47:44 Uhr
Goto Top
Ein bischen Grundlagen zu IP Routing findest du hier:
https://administrator.de/tutorial/routing-2-ip-netzen-windows-linux-rout ...
Und Access Listen sind halt Access Listen. Da sagt man einem Interface welcher IP Traffic da durchdarf und welcher nicht. Das ist quasi so wie die Eingangskontrolle an der Disko.
Der Türsteher an der Disko bestimmt aber nicht welcher Besucher über welchen Anreiseweg zur Disko kommt. Das machen Verkehrschilder (Routing Tabellen) und Kreuzungen.
Vielleicht wirds so etwas transparenter für dich... 😉
FritzBox supportet als billiger Consumer Router keine Access Listen.
Mitglied: techSmile
techSmile 25.02.2021 um 23:45:35 Uhr
Goto Top
Hallo Aqui,

derzeit habe ich wieder ein kleines Problem und hoffe auf deine Hilfe.
Die Uploadgeschwindigkeit vom OVPN-Client zum Server lässt sehr zu wünschen übrig.

Maximal erreiche ich eine Geschwindigkeit von 12-15 MBit/s, was aber auch immer wieder auf ca. 7 MBit/s zusammenbricht.

Folgendes habe ich bereits versucht:
Verschlüsselung geändert --> keine Besserung
tun-mtu und mssfix angepasst --> keine Besserung
Anpassung sndbuf und rcvbuf --> keine Besserung

Folgende Geschwindigkeiten liegen vor:

OpenVPN-Server: VDSL 100/40 an F7490 (wird bald durch 7590 ersetzt)
OpenVPN-Client1: VF Cable 1000/50 an FB6591
OpenVPN-Client2: Glasfaseranbindung 1000/1000 an Sophos FW

Wenn ich mir die CPU vom VPN-Server (wie oben beschrieben - DS1010+) angucke, langweilt sich diese und hat nur bei Ausreizung des vollen Uploads (38 MBit/s) ca. 30% Auslastung - Apropos: Beim Download (also Server --> Client) erreiche ich stets die volle Geschwindigkeit.
Bei den Clients ist die Auslastung nochmal um einiges geringer (Raspi 4GB & Lenovo Thinkpad mit Intel Core i7)

Normalerweise sollte es mit der Verschlüsselung keine Probleme geben, oder täusche ich mich?
Wenn der Download vom Server zum Client passt, sollte doch auch der Upload vom Client zum Server kein Problem sein.

Im Anhang noch die VPN-Config von Server und Client:
server.conf auf Synology (fungiert auch als S2S mit Client1):


client.conf auf Client1&2:
Mitglied: aqui
aqui 26.02.2021 aktualisiert um 09:33:36 Uhr
Goto Top
Tunnel MTU oder MSS wären da immer die erste Anlaufstelle aber das hast du ja schon probiert. Oft sind Mismatches da und die dann daraus resultierende Fragmentierung eine Ursache.
Interessant wäre noch zu wissen ob du beim Tunnelaufbau MTU oder MSS spezifische Messages bekommst.
Dazu müsstest du ggf. mal temporär den Verbosity Level hochschrauben.
Sehr lesenswert dazu ist das hier:
https://administrator.de/forum/geschwindigkeitsunterschiede-verschlü ...
Mitglied: techSmile
techSmile 26.02.2021 um 11:35:12 Uhr
Goto Top
Hallo Aqui,

ja, die erhalte ich beim Verbindungsaufbau mit einem Windowsclient.
Hier der Verbindungsaufbau protokolliert:

Fri Feb 26 11:06:58 2021 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1601', remote='link-mtu 1549'
Fri Feb 26 11:06:58 2021 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1480'


Witzig ist, dass link-mtu gar nicht verwendet wird.

Am Serverstandort ist die maximale MTU-Größe 1492, da DSL.
An den Clientstandorten (beide mit öffentlicher IPv4 und IPv6 Subnet) ist laut Ping-Befehl (ping -f -l 1000) ein Wert von 1472 möglich --> also MTU 1500. Ich habe deshalb in den Client-Configs keinen MTU-Wert gesetzt (Standard 1500).


Soll ich auf dem Server das Verbositylevel hochschrauben, oder genügt dir das schon?
Gib mir kurz Bescheid, dann mache ich das, mache einen Testupload von Client zu Server und lade anschließend das Logfile hier hoch.

Kann ich dies dir ggf. auch per PN zusenden, damit ich im Log nicht jede IP anonymisieren muss?

Viele Grüße
Mitglied: aqui
aqui 26.02.2021 um 11:45:39 Uhr
Goto Top
Witzig ist, dass link-mtu gar nicht verwendet wird.
Wenn es in der Konfig nicht auftaucht nutzt es den Default Wert:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...
Normal sollte man am link-mtu Wert nichts fummeln.
Eine Link MTU von 1601 ist nicht einmal Standard Konform (max. 1500), da hast du also ein Problem ! Ebenso wie mit einer nicht Standard konformen Tunnel MTU größer 1500 die es niemals geben dürfte.
Am besten lässt du erstmal alles weg was MTU und MSS Settings sind arbeitest mit den Default Werten.
Dann setzt du temporär mal den Parameter mtu-test und lässt OpenVPN einmal selber messen beim Tunnelaufbau:
–mtu-test
To empirically measure MTU on connection startup, add the –mtu-test option to your configuration. OpenVPN will send ping packets of various sizes to the remote peer and measure the largest packets which were successfully received. The –mtu-test process normally takes about 3 minutes to complete.

Mitglied: techSmile
techSmile 26.02.2021 aktualisiert um 12:26:29 Uhr
Goto Top
Alles klar,

In der Serverconf habe ich tun-mtu und mssfix entfernt.

Hier die Ausgabe:

Client1 (LAN):

Client2 (WLAN)