Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWünsch Dir wasWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

gelöst OpenVPN - Erreiche Netzwerk hinter Client nicht

Mitglied: techSmile

techSmile (Level 1) - Jetzt verbinden

30.12.2019, aktualisiert 17:14 Uhr, 2039 Aufrufe, 27 Kommentare, 1 Danke

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 - Klicke auf das Bild, um es zu vergrößern

FRITZ!Box 6490 Routen:
2019-12-301 - Klicke auf das Bild, um es zu vergrößern

Vielen Dank vorab für Hilfe!

Freundliche Grüße

techSmile
27 Antworten
Mitglied: Spirit-of-Eli
30.12.2019 um 18:24 Uhr
Im Endeffekt ist die Lösung die gleiche wie in den letzten 20 Fragen zu genau dem Thema.
Bitte warten ..
Mitglied: techSmile
30.12.2019 um 19:40 Uhr
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.
Bitte warten ..
Mitglied: Spirit-of-Eli
31.12.2019 um 00:51 Uhr
Die Fritte in Netz 2 braucht eine Rückroute für das VPN Netz da diese das Netz ja nicht kennt.
Bitte warten ..
Mitglied: aqui
31.12.2019, aktualisiert um 12:25 Uhr
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....
Bitte warten ..
Mitglied: techSmile
31.12.2019 um 14:37 Uhr
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
Bitte warten ..
Mitglied: aqui
31.12.2019, aktualisiert um 15:21 Uhr
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.
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....
Bitte warten ..
Mitglied: techSmile
31.12.2019, aktualisiert um 18:53 Uhr
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
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.
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
Bitte warten ..
Mitglied: aqui
01.01.2020, aktualisiert um 17:05 Uhr
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
Ebenso fehlt ein ip route list oder netstat -rn auf dem RasPi mit aktivem VPN Client !
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.
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.

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

ovpn-router - Klicke auf das Bild, um es zu vergrößern
Bitte warten ..
Mitglied: techSmile
23.02.2020 um 14:21 Uhr
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!
Bitte warten ..
Mitglied: aqui
24.02.2020, aktualisiert um 09:20 Uhr
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...
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 !
Bitte warten ..
Mitglied: techSmile
24.02.2020 um 12:28 Uhr
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 - Klicke auf das Bild, um es zu vergrößern

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.
Bitte warten ..
Mitglied: aqui
24.02.2020, aktualisiert um 12:54 Uhr
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.
Bitte warten ..
Mitglied: techSmile
24.02.2020, aktualisiert um 17:35 Uhr
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 - Klicke auf das Bild, um es zu vergrößern
FB 6490

fb-7490 - Klicke auf das Bild, um es zu vergrößern
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
Danke
Bitte warten ..
Mitglied: aqui
24.02.2020, aktualisiert um 18:44 Uhr
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 ! 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
Bitte warten ..
Mitglied: techSmile
24.02.2020 um 19:33 Uhr
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.
Bitte warten ..
Mitglied: techSmile
24.02.2020 um 22:22 Uhr
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.
Bitte warten ..
Mitglied: techSmile
24.02.2020 um 22:26 Uhr
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.
Bitte warten ..
Mitglied: aqui
25.02.2020, aktualisiert um 09:31 Uhr
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...
Bitte warten ..
Mitglied: techSmile
25.02.2020 um 09:41 Uhr
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?
Bitte warten ..
Mitglied: techSmile
25.02.2020 um 10:10 Uhr
Habe versuchsweise nun LA deaktiviert, doch leider hat das auch nichts gebracht.

Anbei noch Traceroute:
Bitte warten ..
Mitglied: aqui
25.02.2020 um 14:51 Uhr
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 - Klicke auf das Bild, um es zu vergrößern
lag2 - Klicke auf das Bild, um es zu vergrößern

Dazu dann das Pendant auf der Switchseite:
lag3 - Klicke auf das Bild, um es zu vergrößern

Da ist vermutlich also bei dir auch schon was gründlich schiefgegangen !
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.
Entferne überall diese Routen. Belasse einzig und allein NUR die Default Routen zur jeweiligen FritzBox in ALLEN Endgeräten, dann klappt das auch sofort !
Bitte warten ..
Mitglied: techSmile
25.02.2020 um 15:49 Uhr
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
Bitte warten ..
Mitglied: techSmile
26.02.2020, aktualisiert um 16:27 Uhr
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.
Bitte warten ..
Mitglied: aqui
LÖSUNG 28.02.2020, aktualisiert 15.04.2020
Damit das Drama jetzt hoffentlich hier mal ein Ende hat....

1.) Testaufbau:
Simulation genau deines Netz Aufbaus.
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.
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 - Klicke auf das Bild, um es zu vergrößern

(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 Server spezifischen Client Kommandos in der Datei /etc/openvpn/csconf/client01 auf dem Server. "client01" ist hier der Common Name im Zertifikat des Clients.

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 VPN Router in den jeweiligen Netzen.
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 !!!
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 haben ja quasi mit dem Betrieb eines NAS ja immer auch einen (O)VPN Server nebenbei. Sie haben aber 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 muss aber jeder für sich entscheiden.
Besser 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.)
Bitte warten ..
Mitglied: techSmile
01.03.2020 um 16:16 Uhr
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
Bitte warten ..
Mitglied: aqui
LÖSUNG 01.03.2020, aktualisiert um 18:27 Uhr
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.
Bitte warten ..
Mitglied: techSmile
27.03.2020 um 14:23 Uhr
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
Bitte warten ..
Ähnliche Inhalte
Router & Routing

Openvpn client Netzwerk durchreichen Mac zu Windows

gelöst Frage von moxalisaRouter & Routing12 Kommentare

Guten Abend, ich möchte auf einen Mac einen Openvpn Client installieren und das Routing so einrichten das ich von ...

Linux Netzwerk

OpenVPN Client-to-Client

Frage von FreezzenLinux Netzwerk

Moin Moin. Vorweg, Ubuntu war bis Ostern uninteressant für mich. Seitdem lerne ich es lieben. Moment beschäftige ich mich ...

Router & Routing

OpenVPN-Client Router

gelöst Frage von IT-ProRouter & Routing11 Kommentare

Hallo, Habe gehört, dass es Router gibt, die man direkt als Client für ein VPN verwenden kann. Damit soll ...

LAN, WAN, Wireless

OpenVPN Client Fehlermeldungen

Frage von chris84LAN, WAN, Wireless21 Kommentare

Hallo Zusammen, wir nutzen seit kurzem einen neuen Router und den OpenVPN Client. Die VPN Verbindung klappt; allerdings kommen ...

Neue Wissensbeiträge
Sicherheit

Mehrere Sicherheitslücken in QNAP-NAS-Systemen aufgetaucht

Information von transocean vor 13 StundenSicherheit

Moin, QNAP hat drei Sicherheitsprobleme publik gemacht und empfiehlt sofortiges Update. Gruß Uwe

DNS

"Quickie": Mozillas "DNS over HTTPS" in pfSense blockieren

Anleitung von FA-jka vor 15 StundenDNS2 Kommentare

Hallo, Mozilla macht jetzt wohl wirklich Ernst mit "DNS over HTTPS" (kurz: DoH). Damit werden sämtliche DNS-Anfragen zu entsprechenden ...

Sicherheit
Störung bei Telematikinfrasturktur GEMATIK
Information von lcer00 vor 1 TagSicherheit

Am 27. Mai 2020 ist es offenbar zu einer Fehlkonfiguration in der Zentralen Telematikinfrastruktur gekommen. Nähreres dazu findet sich ...

Informationsdienste

Trump vs Twitter - Angriff auf die Meinungsfreiheit?

Information von Frank vor 1 TagInformationsdienste3 Kommentare

Trump nutzt Twitter rege. Nach Hinweisen auf Falschbehauptungen drohte er dem Dienst. Was das bedeutet und die Konsequenzen dazu ...

Heiß diskutierte Inhalte
Sicherheits-Tools
Passwortmanager DGSVO (Deutscher Anbieter - Hoster)
Frage von SoccerdeluxSicherheits-Tools39 Kommentare

Hallo zuammen, ich arbeite für meine Kunden auf unterschiedlichen Geräten / Notebooks. Ich ärgere mich jedesmal, das ich mein ...

Batch & Shell
Ip-Adresse-Konfiguration speichern zur Wiederherstellung
gelöst Frage von alex1991Batch & Shell20 Kommentare

Hallo, ich bin eigentlich nicht in der IT-Abteilung, aber als Programmierer bin ich noch am nächsten dran. Deshalb wurde ...

Exchange Server
Automatische Antwort - Weiterleitung - zweite automatische Antwort - keine Weiterleitung?
Frage von dertowaExchange Server18 Kommentare

Hallo zusammen, da mich der Microsoftsupport ein wenig fassungslos machte versuche ich hier mal mein Glück und wenn es ...

LAN, WAN, Wireless
Haus Netzwerk neu Strukturieren aber wie am besten? Pfsense, WLAN AP
Frage von Motte990LAN, WAN, Wireless14 Kommentare

Hallo Liebe ITler, ich habe endlich die Freigabe meiner Regierung bekommen das Haus Netzwerk umzubauen. Sprich neuer großer Switch ...