4
OpenVPN Routing Problem Filialvernetzung
Moin zusammen.
Als SPS-Entwickler stoße ich mit dem Thema hier an meine Grenzen - es ist sicher schon öfters diskutiert worden, aber ich finde keine Lösung für folgenden Sachverhalt, vielleicht gibt es ja in der Community hier einen Experten, der Rat weiß:
Es geht um den Aufbau einer Fernwartung für mehrere Standorte.
Mein Ansatz:
Zentral und aus dem Internet erreichbar ein Raspi mit Openvpn Server.
Die Clients sind alles Rutx08 VPN Router, die einen OpenVPN Tunnel zum Raspi aufbauen. Hinter diesen VPN-Routern soll das jeweilige Netzwerk für alle eingewählten "Teilnehmer" erreichbar sein, also eigentlich eine klassische Standortvernetzung.
Was derzeit funktioniert:
- OpenVPN Server läuft (VPN-Server IP 10.210.180.1)
- Einwahl von zwei Client Routern (A: 192.168.129.1 und B: 192.168.130.1)
- Einwahl von OpenVPN Software Clients.
Jetzt zu meinem Problem: Die Router sind jeweils gleich eingerichtet. Vom Server lässt sich jeder Ruter per Ping erreichen. Bei Router A kann ich auf sämtliche im Netz 192.168.129.0 hängenden Adressen zugreifen, bei Router B lediglich auf die 192.168.130.1, also den Router selbst. Das ist bestimmt nur irgendwo ein kleiner Denkfehler, aber ich finde den nicht. (Netzwerk ist nicht meine Stärke..). Wer weiß Rat ? Danke im voraus!
Hier die Configs:
Die Configs der Clients sind immer wie folgt aufgebaut:
Netz A:
Netz B:
Softwareclient:
Routing in Router A (192.168.129.1):
Routing in Router B (192.168.130.1):
Traceroute vom OpenVPNServer:
Als SPS-Entwickler stoße ich mit dem Thema hier an meine Grenzen - es ist sicher schon öfters diskutiert worden, aber ich finde keine Lösung für folgenden Sachverhalt, vielleicht gibt es ja in der Community hier einen Experten, der Rat weiß:
Es geht um den Aufbau einer Fernwartung für mehrere Standorte.
Mein Ansatz:
Zentral und aus dem Internet erreichbar ein Raspi mit Openvpn Server.
Die Clients sind alles Rutx08 VPN Router, die einen OpenVPN Tunnel zum Raspi aufbauen. Hinter diesen VPN-Routern soll das jeweilige Netzwerk für alle eingewählten "Teilnehmer" erreichbar sein, also eigentlich eine klassische Standortvernetzung.
Was derzeit funktioniert:
- OpenVPN Server läuft (VPN-Server IP 10.210.180.1)
- Einwahl von zwei Client Routern (A: 192.168.129.1 und B: 192.168.130.1)
- Einwahl von OpenVPN Software Clients.
Jetzt zu meinem Problem: Die Router sind jeweils gleich eingerichtet. Vom Server lässt sich jeder Ruter per Ping erreichen. Bei Router A kann ich auf sämtliche im Netz 192.168.129.0 hängenden Adressen zugreifen, bei Router B lediglich auf die 192.168.130.1, also den Router selbst. Das ist bestimmt nur irgendwo ein kleiner Denkfehler, aber ich finde den nicht. (Netzwerk ist nicht meine Stärke..). Wer weiß Rat ? Danke im voraus!
Hier die Configs:
dev tun
proto udp
port 11941
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/VPN-Server-MC_7b0ccea0-a6d6-49fc-a1a3-c7941748eec1.crt
key /etc/openvpn/easy-rsa/pki/private/VPN-Server-MC_7b0ccea0-a6d6-49fc-a1a3-c7941748eec1.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.210.180.0 255.255.255.0
push "route 192.168.128.0 255.255.255.0"
push "route 192.168.129.0 255.255.255.0"
push "route 192.168.130.0 255.255.255.0"
push "route 192.168.131.0 255.255.255.0"
push "route 192.168.132.0 255.255.255.0"
push "route 192.168.133.0 255.255.255.0"
push "route 192.168.134.0 255.255.255.0"
route 192.168.128.0 255.255.255.0
route 192.168.129.0 255.255.255.0
route 192.168.130.0 255.255.255.0
route 192.168.131.0 255.255.255.0
route 192.168.132.0 255.255.255.0
route 192.168.133.0 255.255.255.0
route 192.168.134.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 192.168.0.7"
push "dhcp-option DNS 192.168.0.254"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
#duplicate-cn
# Generated for use by PiVPN.ioDie Configs der Clients sind immer wie folgt aufgebaut:
Netz A:
ifconfig-push 10.210.180.10 255.255.255.0
iroute 192.168.129.0 255.255.255.0Netz B:
ifconfig-push 10.210.180.21 255.255.255.0
iroute 192.168.130.0 255.255.255.0Softwareclient:
ifconfig-push 10.210.180.2 255.255.255.0Routing in Router A (192.168.129.1):
(tun_c_Weber2) 0.0.0.0/1 10.210.180.1 0 main
wan 0.0.0.0/0 192.168.1.10 2 main
(tun_c_Weber2) 10.210.180.0/24 * 0 main
wan 93.240.2.154 192.168.1.10 0 main
(tun_c_Weber2) 128.0.0.0/1 10.210.180.1 0 main
wan 192.168.1.0/24 * 2 main
(tun_c_Weber2) 192.168.128.0/24 10.210.180.1 0 main
lan 192.168.129.0/24 * 1 main
(tun_c_Weber2) 192.168.130.0/24 10.210.180.1 0 main
(tun_c_Weber2) 192.168.131.0/24 10.210.180.1 0 main
(tun_c_Weber2) 192.168.132.0/24 10.210.180.1 0 main
(tun_c_Weber2) 192.168.133.0/24 10.210.180.1 0 main
(tun_c_Weber2) 192.168.134.0/24 10.210.180.1 0 main Routing in Router B (192.168.130.1):
(tun_c_JanPolen) 0.0.0.0/1 10.210.180.1 0 main
wan 0.0.0.0/0 172.17.1.253 1 main
(tun_c_JanPolen) 10.210.180.0/24 * 0 main
wan 93.240.2.154 172.17.1.253 0 main
(tun_c_JanPolen) 128.0.0.0/1 10.210.180.1 0 main
wan 172.17.1.0/24 * 1 main
(tun_c_JanPolen) 192.168.128.0/24 10.210.180.1 0 main
(tun_c_JanPolen) 192.168.129.0/24 10.210.180.1 0 main
lan 192.168.130.0/24 * 0 main
(tun_c_JanPolen) 192.168.131.0/24 10.210.180.1 0 main
(tun_c_JanPolen) 192.168.132.0/24 10.210.180.1 0 main
(tun_c_JanPolen) 192.168.133.0/24 10.210.180.1 0 main
(tun_c_JanPolen) 192.168.134.0/24 10.210.180.1 0 main Traceroute vom OpenVPNServer:
traceroute 192.168.129.1
traceroute to 192.168.129.1 (192.168.129.1), 30 hops max, 60 byte packets
1 192.168.129.1 (192.168.129.1) 29.541 ms 29.488 ms 29.490 ms
traceroute 192.168.129.100
traceroute to 192.168.129.100 (192.168.129.100), 30 hops max, 60 byte packets
1 10.210.180.10 (10.210.180.10) 31.903 ms 31.861 ms 31.947 ms
2 192.168.129.100 (192.168.129.100) 31.959 ms 31.975 ms 31.947 ms
traceroute 192.168.130.1
traceroute to 192.168.130.1 (192.168.130.1), 30 hops max, 60 byte packets
1 192.168.130.1 (192.168.130.1) 23.548 ms 23.680 ms 23.684 ms
traceroute 192.168.130.100
traceroute to 192.168.130.100 (192.168.130.100), 30 hops max, 60 byte packets
1 10.210.180.21 (10.210.180.21) 23.626 ms 23.575 ms 23.578 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671699
Url: https://administrator.de/forum/openvpn-routing-problem-filialvernetzung-671699.html
Ausgedruckt am: 03.03.2025 um 05:03 Uhr
4 Kommentare
Neuester Kommentar
Moin,
Zwei Ansätze:
Bei Router A kann ich auf sämtliche im Netz 192.168.129.0 hängenden Adressen zugreifen, bei Router B lediglich auf die 192.168.130.1, also den Router selbst. Das ist bestimmt nur irgendwo ein kleiner Denkfehler, aber ich finde den nicht.
Zwei Ansätze:
- im Netz mit der Netz-Adresse .130.0/24 fehlt den Teilnehmern entweder das Default-Gateway (glaube ich aber nicht) oder am hinterlegten Default-Gateway fehlt eine statische Route ala 10.210.180.0/ 24 an 192.168.130.0
- an den Systemen im Zielnetz erlaubt die Firewall an den WindowsClients die Zugriffe aus dem 10er Netz nicht…
Moin,
danke, das könnte was sein..
Punkt 1 ist nicht zutreffend, die route ist existent.
Punkt 2 Firewall ist ein Ansatz, allerdings nicht bei den Clients, das sind alles Linux-Kisten (SPS Steuerungen)..
danke, das könnte was sein..
Punkt 1 ist nicht zutreffend, die route ist existent.
Punkt 2 Firewall ist ein Ansatz, allerdings nicht bei den Clients, das sind alles Linux-Kisten (SPS Steuerungen)..
Ok.
Kommst du (per SSH) auf den RaspberryPi vor Ort und kannst von dort eine der SPSen anpingen?
Kommst du (per SSH) auf den RaspberryPi vor Ort und kannst von dort eine der SPSen anpingen?
Einfach mal die Suchfunktion benutzen...
Hier ist eine Live Bilderbuch Konfiguration deines Designs:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Vergleiche in aller Ruhe und genau die dortige funktionierende Beispiel Konfigurationen mit deinem Setup auf Server- und Clientseite und finde den Fehler!
Alle weiteren Grundlagen findest du, wie immer, im hiesigen OpenVPN Tutorial.
Lesen und verstehen...
Wenn ja, ist das OK. Wenn nein ist es sehr wahscheinlich das dort die statische Route auf die remoten Zielnetze und das interne OpenVPN Netz fehlt?! 🤔
Bedenke auch das solltest du dort Winblows Endgeräte im lokalen LAN pingen diese generell per Default ICMP (Ping) in der lokalen Firewall blocken! Hast du das auf dem Radar? (Firewall mit erweiterter Sicherheit im Suchfeld)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Zusätzlich blockt die lokale Windows Firewall grundsätzlich jeden eingehenden Traffic der nicht aus dem lokalen Netz kommt.
Zwei Fallen also in die du ggf. tappst wenn du Windows Geräte aus dem remoten Netz pingst.
Hier ist eine Live Bilderbuch Konfiguration deines Designs:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Vergleiche in aller Ruhe und genau die dortige funktionierende Beispiel Konfigurationen mit deinem Setup auf Server- und Clientseite und finde den Fehler!
Alle weiteren Grundlagen findest du, wie immer, im hiesigen OpenVPN Tutorial.
Lesen und verstehen...
bei Router B lediglich auf die 192.168.130.1, also den Router selbst.
Wir raten mal... Ist das dortige OpenVPN Endgerät identisch mit dem Router der als Default Gateway bei den Clients dort angegeben ist?Wenn ja, ist das OK. Wenn nein ist es sehr wahscheinlich das dort die statische Route auf die remoten Zielnetze und das interne OpenVPN Netz fehlt?! 🤔
Bedenke auch das solltest du dort Winblows Endgeräte im lokalen LAN pingen diese generell per Default ICMP (Ping) in der lokalen Firewall blocken! Hast du das auf dem Radar? (Firewall mit erweiterter Sicherheit im Suchfeld)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Zusätzlich blockt die lokale Windows Firewall grundsätzlich jeden eingehenden Traffic der nicht aus dem lokalen Netz kommt.
Zwei Fallen also in die du ggf. tappst wenn du Windows Geräte aus dem remoten Netz pingst.
