Netze mit OpenVPN (Raspberrys) verbinden - nur ein Netz erreichbar
Hallo Community!
Basierend auf den Beitrag von Aqui am 28.02.2020 habe ich zwei entfernte Netzwerke via OpenVPN Tunnel, welcher von zwei Raspberry Pi‘s aufgebaut wird, verbunden. Die Config habe ich sozusagen fast 1:1 übernommen und funktioniert mMn auch einwandfrei (TOP!!!).
[=530283&token=984#comment-1430800]
Abgeändert habe ich den verwendeten Port (in der Config und im Port-Forwarding im Router) und die IP-Range des VPN Tunnels.
Da mein (Schrott-) Kabelrouter nur eine einzige statische Route kann, habe ich eine /16er Netzmaske verwendet, damit mit einer Route das Ziel- und das VPN- Netz zum VPN Client/Server geroutet werden.
Klar, ich weiß, hier wäre schon einmal ein besserer Router von Vorteil, nur hat hier mein Kabelanbieter die Hand drauf,… bzw. nur mit erheblichen Mehrkosten gegen einen Anderen, wiederum vom Kabelanbieter festgelegten Router möglich,…
Die Routen sind konfiguriert, das Port Forwarding an den Routern und das IPv4 Forwarding in den Raspberrys ist eingerichtet, die OpenVPN-Configs sind eingespielt und die VPN-Verbindung funktioniert auch perfekt, doch ich kann aus Netz 1 die Teilnehmer aus Netz 2 nicht erreichen!
Konkret kann ich aus Netz 1 den VPN Client mit der VPN-IP und der IP des Netz 2 erreichen. Seltsamerweise kann ich auch den Router (.1) des Netz 2 erreichen, aber alle anderen Teilnehmer in Netz 2 erreiche ich nicht.
Eine Verfolgung mittels traceroute zu den Teilnehmern im Netz 2 ist auch möglich… aber kein Ping…
Umgekehrt funktioniert die Verbindung jedoch tadellos!
Zur Fehlersuche habe ich bereits alle Firewalls deaktiviert – mit gleichem Ergebnis.
Ich habe auch die Rollen des VPN-Client und VPN-Server vertauscht – mit gleichem Ergebnis (daher ist mMn der Fehler nicht in der Config des VPN zu suchen, oder??)
Habt ihr noch Ansatzpunkte, wo (m)ein(e) Fehler versteckt sein könnte(n)??
Hier mein Netz/ Routingaufbau:
Port Forwarding Router 1:
Statische Route an Router 1:
Port Forwarding Router 2:
Statische Route an Router 2:
Routing der VPN Teilnehmer (Raspberrys) und Ping / Traceroute Ergebnisse am VPN Server (Netz1):
Hier ist auch ersichtlich, dass der Ping an einen Teilnehmer (.151) nicht zurückkommt..
Routing der VPN Teilnehmer (Raspberrys) und Ping / Traceroute Ergebnisse am VPN Client (Netz2):
Zu allerletzt noch die OpenVPN Config, wobei ich denke, dass das so passt:
Server, am VPNpi1:
dev tun
proto udp4
port 48255
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 192.168.99.0 255.255.255.0
topology subnet
push "topology subnet"
client-to-client
persist-key
persist-tun
verb 4
status /var/log/openvpn-status.log
log /var/log/openvpn.log
push "route 192.168.201.0 255.255.255.0"
route 192.168.202.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/ccd
Client, VPNpi2:
dev tun
proto udp4
client
remote xxx.xxx.xxx.xxx 48255
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/VPNpi2.crt
key /etc/openvpn/client/VPNpi2.key
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
status /var/log/openvpn-status.log
log /var/log/openvpn.log
persist-tun
persist-key
mute-replay-warnings
pull
Basierend auf den Beitrag von Aqui am 28.02.2020 habe ich zwei entfernte Netzwerke via OpenVPN Tunnel, welcher von zwei Raspberry Pi‘s aufgebaut wird, verbunden. Die Config habe ich sozusagen fast 1:1 übernommen und funktioniert mMn auch einwandfrei (TOP!!!).
[=530283&token=984#comment-1430800]
Abgeändert habe ich den verwendeten Port (in der Config und im Port-Forwarding im Router) und die IP-Range des VPN Tunnels.
Da mein (Schrott-) Kabelrouter nur eine einzige statische Route kann, habe ich eine /16er Netzmaske verwendet, damit mit einer Route das Ziel- und das VPN- Netz zum VPN Client/Server geroutet werden.
Klar, ich weiß, hier wäre schon einmal ein besserer Router von Vorteil, nur hat hier mein Kabelanbieter die Hand drauf,… bzw. nur mit erheblichen Mehrkosten gegen einen Anderen, wiederum vom Kabelanbieter festgelegten Router möglich,…
Die Routen sind konfiguriert, das Port Forwarding an den Routern und das IPv4 Forwarding in den Raspberrys ist eingerichtet, die OpenVPN-Configs sind eingespielt und die VPN-Verbindung funktioniert auch perfekt, doch ich kann aus Netz 1 die Teilnehmer aus Netz 2 nicht erreichen!
Konkret kann ich aus Netz 1 den VPN Client mit der VPN-IP und der IP des Netz 2 erreichen. Seltsamerweise kann ich auch den Router (.1) des Netz 2 erreichen, aber alle anderen Teilnehmer in Netz 2 erreiche ich nicht.
Eine Verfolgung mittels traceroute zu den Teilnehmern im Netz 2 ist auch möglich… aber kein Ping…
Umgekehrt funktioniert die Verbindung jedoch tadellos!
Zur Fehlersuche habe ich bereits alle Firewalls deaktiviert – mit gleichem Ergebnis.
Ich habe auch die Rollen des VPN-Client und VPN-Server vertauscht – mit gleichem Ergebnis (daher ist mMn der Fehler nicht in der Config des VPN zu suchen, oder??)
Habt ihr noch Ansatzpunkte, wo (m)ein(e) Fehler versteckt sein könnte(n)??
Hier mein Netz/ Routingaufbau:
Port Forwarding Router 1:
Statische Route an Router 1:
Port Forwarding Router 2:
Statische Route an Router 2:
Routing der VPN Teilnehmer (Raspberrys) und Ping / Traceroute Ergebnisse am VPN Server (Netz1):
Hier ist auch ersichtlich, dass der Ping an einen Teilnehmer (.151) nicht zurückkommt..
Routing der VPN Teilnehmer (Raspberrys) und Ping / Traceroute Ergebnisse am VPN Client (Netz2):
Zu allerletzt noch die OpenVPN Config, wobei ich denke, dass das so passt:
Server, am VPNpi1:
dev tun
proto udp4
port 48255
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
server 192.168.99.0 255.255.255.0
topology subnet
push "topology subnet"
client-to-client
persist-key
persist-tun
verb 4
status /var/log/openvpn-status.log
log /var/log/openvpn.log
push "route 192.168.201.0 255.255.255.0"
route 192.168.202.0 255.255.255.0
keepalive 10 120
explicit-exit-notify 1
client-config-dir /etc/openvpn/ccd
Client, VPNpi2:
dev tun
proto udp4
client
remote xxx.xxx.xxx.xxx 48255
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/VPNpi2.crt
key /etc/openvpn/client/VPNpi2.key
cipher AES-256-CBC
auth SHA256
auth-nocache
tls-client
remote-cert-tls server
user nobody
group nogroup
status /var/log/openvpn-status.log
log /var/log/openvpn.log
persist-tun
persist-key
mute-replay-warnings
pull
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 645586
Url: https://administrator.de/forum/netze-mit-openvpn-raspberrys-verbinden-nur-ein-netz-erreichbar-645586.html
Ausgedruckt am: 02.04.2025 um 00:04 Uhr
17 Kommentare
Neuester Kommentar

Hallo,
Ich frage mal so rum ;)
Diese VPN Verbindung soll ständig bestehen ?
Es ist schonmal richtig das der VPN Server auf der statischen Seite ist, aber wo ist die Route von 192.168.99.xxx zu 192.168.202.xxx ?
Ich frage mal so rum ;)
Diese VPN Verbindung soll ständig bestehen ?
Es ist schonmal richtig das der VPN Server auf der statischen Seite ist, aber wo ist die Route von 192.168.99.xxx zu 192.168.202.xxx ?
Auf den ersten Blick alles richtig gemacht !
Soweit klappt ja auch alles, denn du kannst ja sehen das du auch die lokalen Router IP Interfaces jeweils von remote pingen kannst. Das zeigt ja ganz klar das der Tunnel und das Routing soweit sauber und OK ist.
Das was nicht geht ist ein Ping auf ein Endgerät und das ist sehr wahrscheinlich eine Winblows Kiste, richtig ?
Dort spielt dir jetzt wie immer vermutlich die lokale Winblows Firewall einen Streich !
Ping (ICMP) geht unter Winblows generell nicht aus 2 Gründen
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Achte auch darauf die IP Adressrange freizugeben:
Gleiches gilt für Dienste die du auf Winblows Rechnern freigibst die Datei- und Drucker Sharing etc. Die lässt die FW nur von lokalen IPs zu. Auch das muss man in der Firewall anpassen.
Soweit klappt ja auch alles, denn du kannst ja sehen das du auch die lokalen Router IP Interfaces jeweils von remote pingen kannst. Das zeigt ja ganz klar das der Tunnel und das Routing soweit sauber und OK ist.
Das was nicht geht ist ein Ping auf ein Endgerät und das ist sehr wahrscheinlich eine Winblows Kiste, richtig ?
Dort spielt dir jetzt wie immer vermutlich die lokale Winblows Firewall einen Streich !
Ping (ICMP) geht unter Winblows generell nicht aus 2 Gründen
- weil das per Default in der FW deaktiviert ist. (ICMP Protokoll)
- Es lässt nur Pings aus dem eigenen IP Netz zu (Adress Range)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Achte auch darauf die IP Adressrange freizugeben:
Gleiches gilt für Dienste die du auf Winblows Rechnern freigibst die Datei- und Drucker Sharing etc. Die lässt die FW nur von lokalen IPs zu. Auch das muss man in der Firewall anpassen.
Wenn ich die statischen Routen in den Routern auf die 192.168.201.0 bzw 192.168.202.0 mit Subnet 255.255.255.0 setze
Das ist ja auch logisch, denn wenn du explizite Routen angibst statt einer Summary Route musst du logischerweise auch das interne OVPN IP Netz mit inkludieren. Das wären dann also zwei statischen Routen pro Seite:Router 1 (Arris):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Ziel: 192.168.202.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Router 2 (TP-Link):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
Ziel: 192.168.201.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
Die Summary Route mit dem 16 Bit Prefix zuvor deckt aber alle 192.168.er IP Netze ab und funktioniert also gleich. Es macht Routing technisch keinerlei Unterschied ob man die dedizierten Einzelrouten angibt oder die Summary Route.
Zu 99% ist Routing hier auch nicht das Problem, denn lauf den Screenshots des TO oben kann er ja von beiden OVPN Rechnern die jeweils gegenüberligende LAN IP des OVPN RasPis und auch die des remoten Internet Routers anpingen.
Das zeigt klar das das Routing sauber funktioniert und es hier sehr wahrscheinlich lediglich ein Winblows Firewall Problem ist.
Wie gesagt Fakt ist ja das du die jeweils remoten Internet Router LAN IPs problemlos pingen kannst was ja per se zeigt das Routingtechnisch alles sauber ist.
Die lokalen Geräte die dann nicht pingbar sind haben (wenn man Firewall Dinge da explizit ausschliessen kann !) dann ein falsches oder fehlendes Gateway das Rückpakete nicht ankommen.
Hast du eine Rasberry OS lite Version auf den RasPi geflasht und dann nach apt-update und apt dist-upgrade und reboot dann klassisch mit apt install openvpn das OVPN Package installiert ?
Die lokalen Geräte die dann nicht pingbar sind haben (wenn man Firewall Dinge da explizit ausschliessen kann !) dann ein falsches oder fehlendes Gateway das Rückpakete nicht ankommen.
Hast du eine Rasberry OS lite Version auf den RasPi geflasht und dann nach apt-update und apt dist-upgrade und reboot dann klassisch mit apt install openvpn das OVPN Package installiert ?
Das ist ja auch logisch, denn wenn du explizite Routen angibst statt einer Summary Route musst du logischerweise auch das interne OVPN IP Netz mit inkludieren. Das wären dann also zwei statischen Routen pro Seite:
Router 1 (Arris):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Ziel: 192.168.202.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Router 2 (TP-Link):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
Ziel: 192.168.201.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
@aqui da muss ich nochmal nachfragen.Router 1 (Arris):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Ziel: 192.168.202.0, Maske: 255.255.255.0, Gateway: 192.168.201.2
Router 2 (TP-Link):
Ziel: 192.168.99.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
Ziel: 192.168.201.0, Maske: 255.255.255.0, Gateway: 192.168.202.2
Wenn ein Client aus dem Netz 1 einen Client im Netz 2 erreichen will, wendet er sich im ersten Schritt an seinen Gateway.
Dieser (201.1) weis durch die statische Route mit dem Ziel 202.0, Gateway 201.2, wie er das Netz erreicht.
Den Gateways aus den Netzen 1 und 2 ist doch der Transportweg (VPN) zwischen den Raspis völlig egal, so lange er seine entsprechenden Endpunkte kennt?! Das Routing im VPN machen doch die Raspis unter sich?!
Prima, da scheinst du doch die Antwort gefunden zu haben 
Jetzt musst nur noch die Einstellung finden, die das Problem verursacht ^^
Wenn du diesen TP-Link hast, würde ich dir fast zu, z.B., OpenWrt raten.
https://openwrt.org/toh/tp-link/archer-mr200
Damit kannst auch deinen VPN direkt drauf laufen lassen, brauchst dann auf der einen Seite (2) deinen Raspi nicht mehr.
Hast du mal nach aktueller Firmware geschaut?
Nochmal Edit: Hast du die Möglichkeit, in deiner jetzigen Konfiguration mal den TP-Link als Client da ans Netz zu hängen (mit irgend einer anderen IP, Routen etc raus) und den dann zu pingen?
Jetzt musst nur noch die Einstellung finden, die das Problem verursacht ^^
Wenn du diesen TP-Link hast, würde ich dir fast zu, z.B., OpenWrt raten.
https://openwrt.org/toh/tp-link/archer-mr200
Damit kannst auch deinen VPN direkt drauf laufen lassen, brauchst dann auf der einen Seite (2) deinen Raspi nicht mehr.
Hast du mal nach aktueller Firmware geschaut?
Nochmal Edit: Hast du die Möglichkeit, in deiner jetzigen Konfiguration mal den TP-Link als Client da ans Netz zu hängen (mit irgend einer anderen IP, Routen etc raus) und den dann zu pingen?
Ich habe die aktuelle Raspberry OS mit Desktop geflasht
Wozu die Desktop Version ?? Sinnloser Overhead der sinnlos Performance kostet was du besser ins VPN investiert hättest. Unverständlich...aber nundenn..Da es mir leider an einem passablen Router mangelt
Ein kleiner Mikrotik kostet nicht einmal 20 Euronen und hat das Featureset von Cisco Routern !! https://www.varia-store.com/de/produkt/97209-mikrotik-routerboard-rb941- ...
Dafür sollte dein Taschengeld doch grad noch reichen, oder ??
Mit dem kannst du alles testen OpenVPN kann der natürlich auch !
Clientverbindung OpenVPN Mikrotik
IPsec und L2TP sowieso !
dass der TP Link Router irgendwo meine Pakete frisst.
Chinesenhardware...no comment ! OpenWRT drauf flashen wie Kollege @incisor2k schon sagt. Oder einfach einen "richtigen" Router verwenden. Hat hier villeicht noch jemand eine Idee, was an meinem TP-Link Router (TP-Link Archer MR 200 ) falsch konfiguriert sein könnte.
Dazu müsste man hellsehen können oder per Telepathie in den Router. Dummerweise ist heute auch noch unsere Kristallkugel defekt...son Mist aber auch !