58
OpenVPN - Erreiche Netzwerk hinter Client nicht
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:
FRITZ!Box 6490 Routen:
Vielen Dank vorab für Hilfe!
Freundliche Grüße
techSmile
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
push "route 192.168.182.0 255.255.255.0"
push "route 192.168.15.0 255.255.255.0"
push "route 192.168.15.0 255.255.255.0"
push "dhcp-option DNS 192.168.182.1"
push "dhcp-option DNS 192.168.180.1"
push "dhcp-option DNS 192.168.15.1"
push "dhcp-option WINS 192.168.182.1"
push "dhcp-option WINS 192.168.180.1"
comp-lzo
dev tun
cipher AES-256-CBC
management 127.0.0.1 1195
auth SHA512
server 192.168.15.0 255.255.255.0
topology subnet
cipher AES-256-CBC
auth SHA512
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
max-clients 15
persist-tun
persist-key
verb 3
#log-append /var/log/openvpn.log
keepalive 10 60
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
client-config-dir ccd
status /tmp/ovpn_status_2_result 30
status-version 2
proto tcp6-server
port 4433Client.conf
client
cipher AES-256-CBC
auth SHA512
dev tun
port 4433
proto tcp4-client
remote vpn.meinnetz.de
nobind
ca /etc/openvpn/ca.crt
comp-lzo
persist-key
persist-tun
tls-version-min 1.0
auth-user-pass /etc/openvpn/auth.txt
verb 3ccd vpns2s
ifconfig-push 192.168.15.4 255.255.255.0FRITZ!Box 7490 Routen:
FRITZ!Box 6490 Routen:
Vielen Dank vorab für Hilfe!
Freundliche Grüße
techSmile
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 530283
Url: https://administrator.de/contentid/530283
Ausgedruckt am: 23.11.2024 um 20:11 Uhr
58 Kommentare
Neuester Kommentar
Im Endeffekt ist die Lösung die gleiche wie in den letzten 20 Fragen zu genau dem Thema.
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.
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.
Die Fritte in Netz 2 braucht eine Rückroute für das VPN Netz da diese das Netz ja nicht kennt.
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....
Hallo,
vielen Dank für die ausführliche Antwort. Mit der kann ich etwas anfangen.
Dazu aber unten mehr.
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.
Ist einfach ein kleines Bastelprojekt, um dabei was zu lernen.
Trotzdem Danke für den Hinweis!
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.
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.
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
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.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
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?iroute 192.168.180.0 255.255.255.0
ifconfig-push 192.168.15.4 255.255.255.0
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 !!!
Fertisch, Danke!- 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 !
VPN-Client ist ein Raspberry Pi 4 inklusive IPv4 Forwarding und IPTables MASQUERADE für TUN0 - beides aktiviert bzw. konfiguriert.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 ...
War eigentlich nicht meine Idee, sowas zusätzlich zu kaufen.https://www.amazon.de/GL-iNet-GL-MT300N-V2-Repeater-Performance-Compatib ...
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:
Oben bereits angesprochen, möchte ich kurz genauer erläutern, wieso ich das mache.- 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 !
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
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:
Clientverbindung OpenVPN Mikrotik
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....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:
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: ROUTE_GATEWAY 192.168.180.1/255.255.255.0 IFACE=eth0 HWADDR=dc:a6:32:28:b8:d0
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: TUN/TAP device tun0 opened
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: TUN/TAP TX queue length set to 100
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: /sbin/ip link set dev tun0 up mtu 1500
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: /sbin/ip addr add dev tun0 192.168.15.4/24 broadcast 192.168.15.255
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: /sbin/ip route add 192.168.182.0/24 via 192.168.15.1
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: /sbin/ip route add 192.168.15.0/24 via 192.168.15.1
Dez 31 18:06:57 raspberrypi-4 openvpn[444]: RTNETLINK answers: File exists
Dez 31 18:06:57 raspberrypi-4 ovpn-client[444]: ERROR: Linux route add command failed: external program exited with error status: 2Leider 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 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 !!
Leider funktioniert die Verbindung aus Netzwerk 1 zu Netzwerk 2 nach wie vor nicht.
Traceroute zeigt folgendes von Windows Server im Netzwerk 1:
Routenverfolgung zu 192.168.180.1 über maximal 30 Hops
1 1 ms 1 ms 1 ms fritz.box [192.168.182.1]
2 62.155.24X.XXX meldet: Zielnetz nicht erreichbar.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:
traceroute to 192.168.180.1 (192.168.180.1), 30 hops max, 38 byte packets
1 192.168.15.4 (192.168.15.4) 36.446 ms 29.032 ms 27.256 ms
2 192.168.180.1 (192.168.180.1) 37.098 ms 27.681 ms 28.589 msSieht so aus, als ob die FB direkt ins Internet routet, aber warum?
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.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.
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.
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
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:
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!
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!
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 !
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:
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.
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:
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.
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)
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.
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 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
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:
Server Configfile:
push "route 192.168.182.0 255.255.255.0"
push "route 192.168.15.0 255.255.255.0"
push "dhcp-option DNS 192.168.182.1"
push "dhcp-option DNS 192.168.180.1"
dev tun
cipher AES-256-CBC
auth SHA1
server 192.168.15.0 255.255.255.0
keepalive 5 60
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
max-clients 15
persist-tun
persist-key
verb 3
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
client-config-dir ccd
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 4433
tun-mtu 1380
comp-lzo
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216" CCD für den Client:
iroute 192.168.180.1 255.255.255.0
ifconfig-push 192.168.15.4 255.255.255.0Client:
client
cipher AES-256-CBC
auth SHA1
dev tun
port 4433
proto udp4
tun-mtu 1380
mssfix 1300
remote hXXXXXXXXXX.de
nobind
ca /etc/openvpn/ca.crt
comp-lzo
persist-key
persist-tun
tls-version-min 1.0
auth-user-pass /etc/openvpn/auth.txt
verb 3
reneg-sec 0
mute-replay-warnings
route 192.168.182.0 255.255.255.0Ich 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
Fehler Server Konfig:
Was eigentlich auch nicht gehen kann:
Gravierend sind aber abgesehen von dem v4/v6 Protokoll Mismatch die Konfig Fehler des Servers und das trotz der expliziten Konfig Beispiele von oben
- 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.
Was eigentlich auch nicht gehen kann:
- Der Server arbeitet mit proto udp6 erzwungen mit IPv6 !
- Der Client hingegen mit proto udp4 erzwungen mit IPv4 !
Gravierend sind aber abgesehen von dem v4/v6 Protokoll Mismatch die Konfig Fehler des Servers und das trotz der expliziten Konfig Beispiele von oben
1
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.
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.
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.
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.
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.
Wie bekomme ich es so hin, dass dies automatisiert funktioniert?
In der Fritzbox ist doch die statische Route eingetragen.
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 !
Sorry, aber ein bischen genauer wenn es geht...
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...
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?
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:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.182.1 192.168.182.2 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.56.0 255.255.255.0 Auf Verbindung 192.168.56.1 281
192.168.56.1 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.56.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.182.0 255.255.255.0 Auf Verbindung 192.168.182.2 281
192.168.182.2 255.255.255.255 Auf Verbindung 192.168.182.2 281
192.168.182.255 255.255.255.255 Auf Verbindung 192.168.182.2 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.182.2 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.56.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.182.2 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 192.168.182.1 Standard
===========================================================================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?
Habe versuchsweise nun LA deaktiviert, doch leider hat das auch nichts gebracht.
Anbei noch Traceroute:
Anbei noch Traceroute:
Routenverfolgung zu 192.168.180.1 über maximal 30 Hops
1 2 ms 3 ms 1 ms fritz.box [192.168.182.1]
2 62.155.245.142 meldet: Zielnetz nicht erreichbar.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:
Dazu dann das Pendant auf der Switchseite:
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 !
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
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
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.
habe nun die Routen entsprechend angepasst, bekomme aber leider weiterhin keine Verbindung zur Box.
Ping gibt folgendes aus:
Antwort von 62.155.245.142: Zielnetz nicht erreichbar.Traceroute:
Routenverfolgung zu 192.168.180.1 über maximal 30 Hops
1 1 ms 1 ms 2 ms fritz.box [192.168.182.1]
2 62.155.245.142 meldet: Zielnetz nicht erreichbar.
Ablaufverfolgung beendet.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.
Damit das Drama jetzt hoffentlich hier mal ein Ende hat....
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.
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.
(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 !!!
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.)
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.
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.
(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
C:\Windows\User1>ping -n 3 192.168.1.1
Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Ping-Statistik für 192.168.1.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 4ms, Maximum = 4ms, Mittelwert = 4ms C:\Windows\User2>ping -n 3 192.168.1.1
Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten:
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Antwort von 192.168.1.1: Bytes=32 Zeit=4ms TTL=62
Ping-Statistik für 192.168.1.1:
Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 4ms, Maximum = 4ms, Mittelwert = 4ms 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 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.)
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
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
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.
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
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
1
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
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
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 !
Guckst du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
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:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
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
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
Moin,
vielen Dank für die schnelle Rückmeldung.
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
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.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 !
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
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
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
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.
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.
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
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
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
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
Ja, das geht natürlich.
Mit 2 einfachen Optionen kann man das erreichen:
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 !
Merkzettel: VPN Installation mit OpenVPN
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).
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 !
Merkzettel: VPN Installation mit OpenVPN
Moin,
vielen Dank erstmal.
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.
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.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.
Bitte lies dir das hiesige OpenVPN Tutorial zu dem Thema genau durch !! Da ist das alles haarklein erklärt !
Merkzettel: VPN Installation mit OpenVPN
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?Merkzettel: VPN Installation mit OpenVPN
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.
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.
Ein bischen Grundlagen zu IP Routing findest du hier:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
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.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
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.
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:
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):
push "route 192.168.182.0 255.255.255.0"
push "route 192.168.183.0 255.255.255.0"
push "dhcp-option DNS 192.168.182.1"
push "dhcp-option DNS 192.168.183.1"
route 192.168.183.0 255.255.255.0
dev tun
tun-mtu 1480
mssfix 1440
cipher AES-256-CBC
auth SHA256
server 192.168.15.0 255.255.255.0
keepalive 5 60
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
max-clients 15
persist-tun
persist-key
verb 3
reneg-sec 0
plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn
client-config-dir ccd
status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 4433
log-append /var/log/openvpn.logclient.conf auf Client1&2:
client
cipher AES-256-CBC
auth SHA256
dev tun
port 4433
proto udp
remote vpn.XX.XXX
nobind
ca /etc/openvpn/ca.crt
persist-key
persist-tun
auth-user-pass /etc/openvpn/auth.txt
verb 3
tls-version-min 1.0
reneg-sec 0
mute-replay-warnings
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:
Geschwindigkeitsunterschiede Verschlüsselung OpenVPN vs. HTTPS
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:
Geschwindigkeitsunterschiede Verschlüsselung OpenVPN vs. HTTPS
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
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
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.
Alles klar,
In der Serverconf habe ich tun-mtu und mssfix entfernt.
Hier die Ausgabe:
Client1 (LAN):
Client2 (WLAN)
In der Serverconf habe ich tun-mtu und mssfix entfernt.
Hier die Ausgabe:
Client1 (LAN):
NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1569,1441] remote->local=[1569,1441]
This connection is unable to accomodate a UDP packet size of 1569. Consider using --fragment or --mssfix options as a workaroundClient2 (WLAN)
NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1569,1569] remote->local=[1569,1569]
Hallo, tut mir Leid das Thema nach so langer Zeit nochmal hoch zu holen, aber bevor ich ein neues aufmache und mir alle nur den Link zu diesem Thread posten.....
...ich habe so ziemlich das gleiche Problem allerdings mit einem kleinen Unterschied, ich benutze als VPN-Server meinen Asus RT-AC68U Router.
Netzwerk 1:
Netzbereich: 192.168.0.0/24
VPN-Server IP: 192.168.0.9
ArbeitsPC: 192.168.0.12 (Windows10 PC)
Asus RT-AC68U WHITE
Netzwerk 2:
Netzbereich: 192.168.1.0/24
VPN-Client IP: 192.168.1.2 (Windows 10 PC)
FRITZ!Box 6820 LTE (192.168.1.1)
VPN-Netz:
192.168.2.0/24
(Asus RT-AC68U WHITE --->192.168.2.5)
(VPN-Client --->192.168.2.6)
Ich habe versucht alle Tipps aus dem Thread (und was ich sonst im Netz gefunden habe) umzusetzen, aber iwie kann ich aus dem Netzwerk1 das Netzwerk2 nicht erreichen. Umgedreht funktioniert es, das heißt ich habe Zugriff auf die Clients im Netzwerk 1. Ich habe am VPN-Client in der Registry ip-forwarding aktiviert und mit Routen rumprobiert. Leider alles ohne Erfolg. Habe die Routen wieder gelöscht und der aktuelle Stand ist folgender:
Auf der Fritzbox habe ich folgende Routen eingetragen:
die RoutingTabelle des VPN-Clients sieht folgendermaßen aus:
Auf dem Asus-Router (VPN-Server) habe ich folgende Route eingerichtet:
meine Client.ovpn sieht folgendermaßen aus:
Die server-config kann ich hier nur per Screen posten da ich das nur in der Oberfläche fest einstellen kann:
Ich hoffe ich habe hier alle benötigten Details mitgeteilt.
Bei einem Ping von meinem ArbeitsPC bekomme ich folgende Antwort:
Leider weiß ich gerade gar nicht mehr an welcher Stelle (vermutlich) eine Route fehlt. Ich wäre sehr dankbar wenn sich das mal jmd anschauen könnte.
Für mein Verständnis läuft auf dem Asus Router alles da die Anfrage ja durchgeleitet wird. Aber muss ich noch was an der Konfig der Fritzbox oder eher am VPN-Client vornehmen?
Vielen Dank schonmal im Voraus!!!
mfg, ehorn
...ich habe so ziemlich das gleiche Problem allerdings mit einem kleinen Unterschied, ich benutze als VPN-Server meinen Asus RT-AC68U Router.
Netzwerk 1:
Netzbereich: 192.168.0.0/24
VPN-Server IP: 192.168.0.9
ArbeitsPC: 192.168.0.12 (Windows10 PC)
Asus RT-AC68U WHITE
Netzwerk 2:
Netzbereich: 192.168.1.0/24
VPN-Client IP: 192.168.1.2 (Windows 10 PC)
FRITZ!Box 6820 LTE (192.168.1.1)
VPN-Netz:
192.168.2.0/24
(Asus RT-AC68U WHITE --->192.168.2.5)
(VPN-Client --->192.168.2.6)
Ich habe versucht alle Tipps aus dem Thread (und was ich sonst im Netz gefunden habe) umzusetzen, aber iwie kann ich aus dem Netzwerk1 das Netzwerk2 nicht erreichen. Umgedreht funktioniert es, das heißt ich habe Zugriff auf die Clients im Netzwerk 1. Ich habe am VPN-Client in der Registry ip-forwarding aktiviert und mit Routen rumprobiert. Leider alles ohne Erfolg. Habe die Routen wieder gelöscht und der aktuelle Stand ist folgender:
Auf der Fritzbox habe ich folgende Routen eingetragen:
die RoutingTabelle des VPN-Clients sieht folgendermaßen aus:
Auf dem Asus-Router (VPN-Server) habe ich folgende Route eingerichtet:
meine Client.ovpn sieht folgendermaßen aus:
remote xxx.com 1194
float
nobind
proto udp
dev tun
sndbuf 0
rcvbuf 0
keepalive 10 30
auth-user-pass
client
auth SHA512
cipher AES-256-CBC
remote-cert-tls server
<ca>Die server-config kann ich hier nur per Screen posten da ich das nur in der Oberfläche fest einstellen kann:
Ich hoffe ich habe hier alle benötigten Details mitgeteilt.
Bei einem Ping von meinem ArbeitsPC bekomme ich folgende Antwort:
Leider weiß ich gerade gar nicht mehr an welcher Stelle (vermutlich) eine Route fehlt. Ich wäre sehr dankbar wenn sich das mal jmd anschauen könnte.
Für mein Verständnis läuft auf dem Asus Router alles da die Anfrage ja durchgeleitet wird. Aber muss ich noch was an der Konfig der Fritzbox oder eher am VPN-Client vornehmen?
Vielen Dank schonmal im Voraus!!!
mfg, ehorn
Es fehlt natürlich keine Route. Das Problem ist der Asus selber, der Firmware bedingt unnötigerweise NAT (IP Adress Translation) im Tunnel macht. Damit ist die Kommunikation prinzipbedingt imemr eine Einbahnstrasse, da du das NAT in Rückrichting nicht überwinden kannst.
Dummerweise ist das NAT im Tunnel per Setup nicht abschaltbar bei diesem Router. Das ist der Nachteil wenn man konfektionierte Systeme betreibt wo du von dem Willen des Herstellers abhängig bist.
Mit dieser Hardware kannst du dein Problem nicht lösen.
Beschaffe dir einen 25 Euro Mikrotik o.a., damit hast du jede Freiheit im Setup von jedem beliebigen VPN Protokoll.
Dummerweise ist das NAT im Tunnel per Setup nicht abschaltbar bei diesem Router.
Das ist der Nachteil wenn man konfektionierte Systeme betreibt wo du von dem Willen des Herstellers abhängig bist.Mit dieser Hardware kannst du dein Problem nicht lösen.
Beschaffe dir einen 25 Euro Mikrotik o.a., damit hast du jede Freiheit im Setup von jedem beliebigen VPN Protokoll.
Vielen Dank für deine schnelle Antwort. Ein wenig baut mich das ja auf, es lag also nicht an meinem Verständnis des Ganzen 😅
Alternativ habe ich in meinem Heimnetz einen Windows2019 Server, welcher wohl auch die Rolle des OpenVPN Servers einnehmen könnte. Damit sollte es funktionieren oder?
Alternativ habe ich in meinem Heimnetz einen Windows2019 Server, welcher wohl auch die Rolle des OpenVPN Servers einnehmen könnte. Damit sollte es funktionieren oder?
Ja, aber ob es besonderst intelligent ist einen 80 Watt Klotz unnötig dafür glühen zu lassen wenn es ein 25 Euro Mikrotik mit 20 Euro Jahreskosten auch kann musst du natürlich selber entscheiden.
Auch ob man überhaupt noch das etwas in die Jahre gekommene OpenVPN verwendet wenn man einfacher mit bordeigenen VPN Clients arbeiten kann.
Auch ob man überhaupt noch das etwas in die Jahre gekommene OpenVPN verwendet wenn man einfacher mit bordeigenen VPN Clients arbeiten kann.
Naja der 80Watt Klotz läuft eh...also würde es sich anbieten denk ich. Das mit dem OpenVPN finde ich (wenns einmal läuft) recht einfach zu handeln, vorallem in Bezug auf die Clients (mit der client.ovpn).
Ich werde mich mal damit beschäftigen die Tage und danke dir vielmals für deine Antwort, ich hätte wohl noch eine Weile gesucht.
Danke aqui!!
Ich werde mich mal damit beschäftigen die Tage und danke dir vielmals für deine Antwort, ich hätte wohl noch eine Weile gesucht.
Danke aqui!!
Das mit dem OpenVPN finde ich (wenns einmal läuft) recht einfach zu handeln
Wireguard wäre noch einfacher...
So sähe dann deine WG Kopplung 2er Netze mit einem internen WG Server und Client aus:
Die wichtigsten ToDos:
❗️ Tip:
Da WG Server und Client quasi auch Router sind (IP Forwarding muss aktiviert sein! Siehe oben!) sollten deren IP Adressen im jeweiligen LAN immer fest sein und sich nicht ändern. Ob das über eine statische Zuweisung oder über eine feste IP Reservierung im DHCP Server passiert ist eine kosmetische Frage.
Macht man das nicht, besteht die Gefahr das aufgrund der Dynamik von DHCP sich die IP Adressen ändern was dann zur Folge hat das sowohl die statischen Routen als auch das Port Forwarding auf der Server Seite die fest auf diese Adressen zeigen mit einmal ins IP Nirwana verweisen und das VPN dann außer Funktion ist!
⚠️ Achtung auch bei Winblows Komponenten im VPN und deren lokale Firewall! Das WG Interface sollte hier ein privates, lokales Profil zugewiesen haben!
Windows blockt zudem immer ICMP (Ping) und generell auch Zugriffe von fremden IP Netzen auf seine lokalen Dienste.
Das muss man ggf. immer in der lokalen Firewall customizen. (Windows Firewall mit erweiterter Sicherheit)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Die wichtigsten ToDos:
- IP Adressierung ggf. deinen Belangen anpassen. Achte auf eine sinnvolle VPN IP Adressierung!!
- Der Internet Router auf der Server Seite (und nur der!) hat natürlich noch ein Port Forwarding konfiguriert was den WG UDP Port auf die lokale WG Server IP mappt!
- ⚠️ Routing auf auf dem Windows Rechnern Server und Client unbedingt aktivieren! Den Registry Editor mit "regedit" starten und unter HKEY_LOCAL_MACHINE/System/CurrentControlSet/Tcpip/Parameters den Wert von IPEnableRouter auf 1 setzen!
❗️ Tip:
Da WG Server und Client quasi auch Router sind (IP Forwarding muss aktiviert sein! Siehe oben!) sollten deren IP Adressen im jeweiligen LAN immer fest sein und sich nicht ändern. Ob das über eine statische Zuweisung oder über eine feste IP Reservierung im DHCP Server passiert ist eine kosmetische Frage.
Macht man das nicht, besteht die Gefahr das aufgrund der Dynamik von DHCP sich die IP Adressen ändern was dann zur Folge hat das sowohl die statischen Routen als auch das Port Forwarding auf der Server Seite die fest auf diese Adressen zeigen mit einmal ins IP Nirwana verweisen und das VPN dann außer Funktion ist!
⚠️ Achtung auch bei Winblows Komponenten im VPN und deren lokale Firewall! Das WG Interface sollte hier ein privates, lokales Profil zugewiesen haben!
Windows blockt zudem immer ICMP (Ping) und generell auch Zugriffe von fremden IP Netzen auf seine lokalen Dienste.
Das muss man ggf. immer in der lokalen Firewall customizen. (Windows Firewall mit erweiterter Sicherheit)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Hallo allerseits,
darf auch ich das Thema nochmals aufmachen und um eure Ideen bitten:
Entsprechend der Anleitung wurden die Routen-Konfiguration am Open-VPN-Server (Synology NAS) vorgenommen sowie die Routen an den physischen Netgear-Routern gesetzt.
Netzwerk 1:
Netzbereich: 10.0.1.0/24
VPN-Server IP: 10.0.1.1 (Synology NAS)
Netgear Router IP: 10.0.1.80
Netzwerk 2:
Netzbereich: 192.168.0.0/24
VPN-Client IP: 192.168.0.1 (Windows 10 PC)
Netgear Router IP: 192.168.0.80
VPN-Netz:
10.8.0.0/24
VPN-IP des VPN-Clients: 10.8.0.6 (Windows 10 PC)
Leider kann ich von Netzwerk 1 nur direkt auf den VPN-Client (am Windows 10 PC) in Netzwerk 2 zugreifen (bei Deaktivierung der Windows 10 Firewall). Der Zugriff auf die anderen Clients im Netzwerk 2 ist nicht möglich.
(Zugriff vom Netzwerk 2 auf die Clients im Netzwerk 1 war bereits zuvor und ist immer noch möglich.)
1) Traceroute an VPN-Client in Netzwerk 2 (erfolgreich):
2) Traceroute an Netgear-Router in Netzwerk 2 (schlägt fehlt):
Meine Vermutung ist, dass es mit einer fehlenden Einstellung in Windows 10 als VPN-Client zusammenhängt. Wenn man zwecks IP4-Forwarding den Windows-10-Dienst "Routing und RAS" einschaltet, wird eine neue Netzwerkverbindung "Eingehende Verbindung" erstellt. (Nicht so, wenn man nur den Registry-Eintrag setzt.) Diese lässt einige Konfigurationsmöglichkeiten zu. Allerdings ist gleich beim 1. Einstellungs-Tab "Allgemein" keine Hardware unter Geräte ersichtlich.
darf auch ich das Thema nochmals aufmachen und um eure Ideen bitten:
Entsprechend der Anleitung wurden die Routen-Konfiguration am Open-VPN-Server (Synology NAS) vorgenommen sowie die Routen an den physischen Netgear-Routern gesetzt.
Netzwerk 1:
Netzbereich: 10.0.1.0/24
VPN-Server IP: 10.0.1.1 (Synology NAS)
Netgear Router IP: 10.0.1.80
Netzwerk 2:
Netzbereich: 192.168.0.0/24
VPN-Client IP: 192.168.0.1 (Windows 10 PC)
Netgear Router IP: 192.168.0.80
VPN-Netz:
10.8.0.0/24
VPN-IP des VPN-Clients: 10.8.0.6 (Windows 10 PC)
Leider kann ich von Netzwerk 1 nur direkt auf den VPN-Client (am Windows 10 PC) in Netzwerk 2 zugreifen (bei Deaktivierung der Windows 10 Firewall). Der Zugriff auf die anderen Clients im Netzwerk 2 ist nicht möglich.
(Zugriff vom Netzwerk 2 auf die Clients im Netzwerk 1 war bereits zuvor und ist immer noch möglich.)
1) Traceroute an VPN-Client in Netzwerk 2 (erfolgreich):
traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 60 byte packets
1 10.8.0.6 (10.8.0.6) 72.812 ms 72.704 ms 72.701 ms
2 10.8.0.6 (10.8.0.6) 72.702 ms 72.703 ms 72.706 ms2) Traceroute an Netgear-Router in Netzwerk 2 (schlägt fehlt):
traceroute to 192.168.0.80 (192.168.0.80), 30 hops max, 60 byte packets
1 10.8.0.6 (10.8.0.6) 315.582 ms 315.600 ms 315.624 ms
2 * * *
3 * * *Meine Vermutung ist, dass es mit einer fehlenden Einstellung in Windows 10 als VPN-Client zusammenhängt. Wenn man zwecks IP4-Forwarding den Windows-10-Dienst "Routing und RAS" einschaltet, wird eine neue Netzwerkverbindung "Eingehende Verbindung" erstellt. (Nicht so, wenn man nur den Registry-Eintrag setzt.) Diese lässt einige Konfigurationsmöglichkeiten zu. Allerdings ist gleich beim 1. Einstellungs-Tab "Allgemein" keine Hardware unter Geräte ersichtlich.
Meine Vermutung ist, dass es mit einer fehlenden Einstellung in Windows 10 als VPN-Client zusammenhängt.
Das kann sehr gut sein. Leider machst du keinerlei hilfreiche und zielführende Angaben zu diesen Einstellungen. 2 sehr wichtige Punkte sind dafür auf dem Winblows PC umzusetzen:
- Auf dem PC muss IPv4 Forwarding (Routing) aktiviert sein (Registry). Siehe dazu HIER. Eine neue Netzwerk Verbindung wird damit natürlich nicht erstellt, das ist Unsinn, denn das eine hat mit dem anderen nichts zu tun!
- Auf dem Netgear Router an Netzwerk 2 müssen zwingend 2 statische Routen gesetzt sein:
- Zielnetz: 10.8.0.0/24, Gateway: 192.168.0.1
- Zielnetz: 10.0.1.0/24, Gateway: 192.168.0.1
Hier siehst du genau so ein Szenario wie deins nochmal im Detail.
Alle weiteren Details dazu kannst du auch nochmals im OpenVPN Tutorial nachlesen!
1
Heureka, das wars:
Die 2. statische Route im Client-Netzwerk für das "virtuelle" Open-VPN-Netzwerk hat gefehlt.
Habe deren Notwendigkeit in den obigen Ausführungen wohl übersehen
P.S.: Zum IP4-Forwarding in Windows 10: Nur der Registry-Eintrag reicht auf meinem PC nicht (mehr) aus, es muss (auch) der Dienst "Routing und RAS" aktiv sein. Sobald der Dienst gestartet ist, erscheint die Netzwerkverbindung "Eingehende Verbindung". Deren Konfiguration ist offenbar ohne Belang für dieses Vorhaben.
Die 2. statische Route im Client-Netzwerk für das "virtuelle" Open-VPN-Netzwerk hat gefehlt.
Habe deren Notwendigkeit in den obigen Ausführungen wohl übersehen
Zitat von @aqui:
Auf dem Netgear Router an Netzwerk 2 müssen zwingend 2 statische Routen gesetzt sein:
Vielen lieben Dank @aqui für deine rasche Hilfe!Auf dem Netgear Router an Netzwerk 2 müssen zwingend 2 statische Routen gesetzt sein:
- Zielnetz: 10.8.0.0/24, Gateway: 192.168.0.1
- Zielnetz: 10.0.1.0/24, Gateway: 192.168.0.1
P.S.: Zum IP4-Forwarding in Windows 10: Nur der Registry-Eintrag reicht auf meinem PC nicht (mehr) aus, es muss (auch) der Dienst "Routing und RAS" aktiv sein. Sobald der Dienst gestartet ist, erscheint die Netzwerkverbindung "Eingehende Verbindung". Deren Konfiguration ist offenbar ohne Belang für dieses Vorhaben.
Nur der Registry-Eintrag reicht auf meinem PC nicht (mehr) aus, es muss (auch) der Dienst "Routing und RAS" aktiv sein.
Ist so hier auf einem Win 10 und Win 11 (22H2) nicht nachzuvollziehen. Bei beiden reicht die Anpassung der Registry und das Forwarding ist dann nach einem Reboot sofort aktiv!!Sowas wie "Eingehende Verbindung" usw. erscheint nicht. Was sollte das auch sein? Hat ja mit IPv4 Forwardings auch nichts zu tun. Vermutlich ist da an deinem Winblows schon was "verschlimmbessert"?! Aber egal... Hauptsache es klappt.
Bedenklicher ist eher das in die Jahre gekommene und wenig skalierende, da nicht multithreading fähige OpenVPN mit seiner mickrigen Performance noch zu verwenden. Ein Bild sagt mehr als 1000 Worte...
Ja, leider hat Synology in seinem VPN-Server WireGuard immer noch nicht implementiert
Na ja, abgesehen davon gehört ein VPN niemals auf interne Komponenten, schon gar nicht auf ein besonders schützenswertes Gerät wie ein NAS. So musst du beidseitig ungeschützten Internet Traffic in lokale Netze lassen was niemals eine gute Idee ist. Das wissen mittlerweile auch Netzwerk Laien.
VPNs gehören deshalb bekanntlich immer auf die Peripherie wie Router oder Firewall sofern die Datensicherheit ein Kriterium beim Design ist. Zur Not mit einer Router Kaskade.
Und...Wireguard ist ja noch nicht alles, es gibt auch noch IPsec!!
VPNs gehören deshalb bekanntlich immer auf die Peripherie wie Router oder Firewall sofern die Datensicherheit ein Kriterium beim Design ist. Zur Not mit einer Router Kaskade.
Und...Wireguard ist ja noch nicht alles, es gibt auch noch IPsec!!
