OpenVPN: Zugriff von Client-Verbindung auf S2S-Verbindung

Hallo zusammen,

ich bräuchte bitte mal eure Hilfe.
Ich habe eine OPNsense auf einem RootServer im Netz. Auf dieser OPNsense laufen zwei OpenVPN-Server.
*OpenVPN-Server1: Site-to-Site-VPN in mein Heimnetzwerk
*OpenVPN-Server2: Client-VPN

Die Site2Site-Verbindung funktioniert und ich kann vom Heimnetzwerk auf die Server hinter der OPNsense zugreifen und auch andersherum.
Die Client-Verbindung funktioniert auch und ich kann über diese Verbindung auf die Server hinter der OPNsense zugreifen.

Was nicht geht: Ich kann nicht über die Client-Verbindung auf einen Server hinter der S2S-Verbindung zugreifen.
Die Firewallregeln habe ich bereits geprüft. Hier sehe ich keine Probleme.

Die jeweiligen IP-Netze sind folgende:
OPNsense: 10.0.10.0/24, 10.0.20.0/24
Heimnetzwerk: 10.0.1.0/24
VPN-Client: 172.16.1.6

Config OVPN-Server für Site2Site:

dev ovpns2
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
ifconfig 172.16.7.1 172.16.7.2
lport 1195
management /var/etc/openvpn/server2.sock unix
push "route 10.0.10.0 255.255.255.0"  
push "route 10.0.20.0 255.255.255.0"  
push "route 10.0.30.0 255.255.255.0"  
push "route 172.16.1.0 255.255.255.0"  
route 10.0.1.0 255.255.255.0
secret /var/etc/openvpn/server2.secret 

Config OVPN-Server für ClientVPN:

dev ovpns1
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
client-disconnect "/usr/local/etc/inc/plugins.inc.d/openvpn/attributes.sh server1"  
tls-server
server 172.16.1.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
username-as-common-name
auth-user-pass-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify user 'Local Database' 'false' 'server1'" via-env  
tls-verify "/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn_auth_verify tls 'OpenVPN' 1"  
lport 1194
management /var/etc/openvpn/server1.sock unix
push "route 10.0.10.0 255.255.255.0"  
push "route 10.0.20.0 255.255.255.0"  
push "route 10.0.1.0 255.255.255.0"  
push "route 10.0.30.0 255.255.255.0"  
client-to-client
ca /var/etc/openvpn/server1.ca 
cert /var/etc/openvpn/server1.cert 
key /var/etc/openvpn/server1.key 
dh /usr/local/etc/dh-parameters.2048.sample
tls-auth /var/etc/openvpn/server1.tls-auth 0
persist-remote-ip
float

Hat jemand von euch noch einen Hinweis, wie ich dieses Problem lösen kann?
Welche Informationen fehlen hier ggf. noch?

Vielen Dank für eure Unterstützung und beste Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 436776

Url: https://administrator.de/forum/openvpn-zugriff-von-client-verbindung-auf-s2s-verbindung-436776.html

Ausgedruckt am: 22.12.2024 um 06:12 Uhr

8 Kommentare

Neuester Kommentar

Moin,

bin kein OpenSense/ OpenVPN-Spezi, aber folgender Ansatz:
Hinweis: Wissen die beiden OpenSense-Server, welche Netze sich hinter dem anderen befinden und routen diese auch die Pakete?
Hast du die Firewall auf deinem Client am OpenVPN-Client dahingehend parametrisiert, dass sie Pakete aus dem Netz hinter der anderen S2S-Strecke (10.0.1.0/24) annimmt?

was sagt denn ein traceroute (in beide Richtungen)?
Dann siehst du ja, wie weit du kommst.

Gruß
em-pie

Hey BirdyB,

hast du dazu eine Lösung gefunden?
Stehe gerade vor dem gleichen Problem.

LG
Simon

Die OpenVPN Konfig oben ist sehr schlecht gemacht und solltest du keinesfalls übernehmen. Es ist vollkommen falsch und aus Performance Sicht sehr kontraproduktiv dafür 2 getrennte OpenVPN Prozesse zu starten. Das ist völlig überflüssig denn ein einziger OpenVPN Server Prozess reicht dafür völlig.

Du solltest bei aktuellen Projekten auch besser nicht mehr das relativ schwache und schlecht skalierende OpenVPN verwenden sondern bessere VPN Protokolle.
Ideal ist eine Lösung die immer die onboard Clients in jedem Betriebssystem und Smartphones supportet was dir dann auch die zusätzliche Frickelei mit (überflüssigen) VPN Clients erspart.
Guckst du hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
und hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Die Site to Site Verbindung bindest du ebenfalls mit IPsec an. Fertisch.
Eine deutlich bessere und effizientere Lösung als die technisch falsche Frickelei mit 2 OVPN Prozessen.

Zitat von @aqui:

Die OpenVPN Konfig oben ist sehr schlecht gemacht und solltest du keinesfalls übernehmen. Es ist vollkommen falsch und aus Performance Sicht sehr kontraproduktiv dafür 2 getrennte OpenVPN Prozesse zu starten. Das ist völlig überflüssig denn ein einziger OpenVPN Server Prozess reicht dafür völlig.

Du solltest bei aktuellen Projekten auch besser nicht mehr das relativ schwache und schlecht skalierende OpenVPN verwenden sondern bessere VPN Protokolle.
Ideal ist eine Lösung die immer die onboard Clients in jedem Betriebssystem und Smartphones supportet was dir dann auch die zusätzliche Frickelei mit (überflüssigen) VPN Clients erspart.
Guckst du hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
und hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Die Site to Site Verbindung bindest du ebenfalls mit IPsec an. Fertisch.
Eine deutlich bessere und effizientere Lösung als die technisch falsche Frickelei mit 2 OVPN Prozessen.

Hey aqui,
ich habe aktuell folgenden Aufbau:
Site A: pfSense FW (OpenVPN Server) -> LAN 10.0.0.0/24 -> dahinter einige Server inkl. Terminalserver, wo von Site B aus per RDP gearbeitet wird
Site B: pfSense FW (OpenVPN Client) -> LAN 192.168.178.0/24 -> dahinter Drucker, Workstations, POS System etc

Site A und Site B sind via SSL OpenVPN miteinander verbunden.
Auf IPsec zwischen Site A und Site B hatte ich bewusst verzichtet, weil ich häufig gelesen habe, dass ich mit OpenVPN performancetechnisch sowie von der Sicherheit besser dran bin.
Ich habe daher natürlich auf Site A auch 2 OVPN Prozesse laufen, da der eine Peer-to-Peer ist und der Andere Remote-Connect.
Wenn das jetzt Sicherheitsmäßig und technisch total falsch ist, sag mir das gerne, dann ändere ich die Konfiguration entsprechend.

Ich möchte jetzt zum Beispiel von Computer 1 per OpenVPN Software in beide Netze (10.0.0.0/24 und 192.168.178.0/24) zugreifen können. Da ich mich von Computer 1 auf die Site A verbinde, komme ich logischerweise in das direkte LAN Subnetz dahinter, aber nicht in das entfernte LAN von Site B.
Er kennt wahrscheinlich die Route dahin nicht und ich frage mich, wie ich ihm diese vorgeben kann.

LG
Simon

dass ich mit OpenVPN performancetechnisch sowie von der Sicherheit besser dran bin.

Oha, da lebst du aber etwas hinter dem Mond! Wo hast du diesen Unsinn her?

VPN Performance eines 1Gig Anschlusses. Muss man noch mehr kommentieren?!

Ich habe daher natürlich auf Site A auch 2 OVPN Prozesse laufen

Gruseliger Quatsch und Performance Fresser, wie oben schon gesagt.

da der eine Peer-to-Peer ist und der Andere Remote-Connect.

Warum machst du/ihr diesen Unsinn? Überflüssig...

Er kennt wahrscheinlich die Route dahin nicht

Warum siehst du dir dazu nicht einmal die Routing Tabelle (unter Diagnostics) an?!

Sicherheitsmäßig und technisch total falsch ist

Das ist es. Stell das auf IPsec um dann hast du alle diese Probleme nicht mehr.
Alternativ alles nur über einen einzigen OVPN Prozess wie es best Practise ist. IPsec wäre aber die intelligentere Option.

Warum machst du/ihr diesen Unsinn? > Überflüssig...

Naja, mein Beitrag ist vier Jahre alt und mittlerweile mache ich es auch anders…
Das Thema mit mehreren Prozessen wurde allerdings damals an mehreren Stellen als Best Practice ausgewiesen…
Dass es das nicht ist haben wir ja nun gelernt…