Zugriff aus dem Intranet auf VPN Server

Hallo,

ich habe gerade ein Problem mit einem OpenVPN Server der auf einem kleinen Linux Mint Rechner läuft.
Die VPN Verbindungen zu den Client funktioneren. Jedoch nur, wenn ich diese vom OpenVPN Server aus aufrufe.

Habe ich nun einen beliebigen Rechner im Intranet und will darauf zugreifen, erhalte ich den Zugriff nicht.

VPN-Netzwerk: 10.10.0.0/24
Intranet: 192.168.99.0/24

IP-Adresse	Netzmaske	Tag	Schaltzustand	Router	Distanz	Mask.	Kommentar
10.10.0.0	255.255.255.0	0	An, sticky für RIP	192.168.99.103	0	Aus	vpn gemini

Mach ich nun von einem beliebigen Rechner im LAN einen Ping auf einen VPN-Client so erhalte ich folgende Rückmeldung

xy@xy-zbox ~ $ ping 10.10.0.105
PING 10.10.0.105 (10.10.0.105) 56(84) bytes of data.
From 192.168.99.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.99.103)
From 192.168.99.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.99.103)

Vom VPN Server:

ab@ab-zbox ~ $ ping 10.10.0.105
PING 10.10.0.105 (10.10.0.105) 56(84) bytes of data.
From 192.168.99.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.99.103)
From 192.168.99.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.99.103)

Konfiguration OpenVPN sieht wie folgt aus

port 1194
proto udp
dev tun

ca gemini/ca.crt
cert gemini/server.crt
key gemini/server.key
dh gemini/dh2048.pem

ifconfig-pool-persist gemini/ipp.txt
push "topology subnet"  
topology subnet

server 10.10.0.0 255.255.255.0 # clients
#route 192.168.99.0 255.255.255.0

client-config-dir gemini/ccd
client-to-client

keepalive 10 120
comp-lzo

user openvpn
group openvpn

persist-key
persist-tun

status gemini/status.txt
log gemini/log.txt

verb 3

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

Content-ID: 585342

Url: https://administrator.de/forum/zugriff-aus-dem-intranet-auf-vpn-server-585342.html

Ausgedruckt am: 23.12.2024 um 22:12 Uhr

3 Kommentare

Neuester Kommentar

Habe ich nun einen beliebigen Rechner im Intranet und will darauf zugreifen

2 wichtige Dinge dazu:
1.)
Sind das Windows Rechner ?
Wenn ja musst du ggf. die lokale Firewall anpassen damit sie IP Pakete aus fremden IP Netzen passieren lässt. Normal blockt die Windows Firewall alles was nicht aus dem lokalen Netzsegment kommt und damit natürlich auch IP Adressen die als Absender dein internes OVPN IP Netz haben.
Hier am Beispiel von ICMP (Ping) zu sehen:
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
2.)
Alle deine lokalen Client Rechner haben den Internet Router als Default Gateway eingetragen !
Für die Rückroute ins Client OVPN IP Netz fragen sie also diesen Router. Wenn dort eine statische Route in interne OpenVPN Netz fehlt via OpenVPN Server LAN IP, dann gehen diese Pakete ins Nirvana und du siehst exakt dein Verhalten !
Diese Skizze veranschaulicht dir wie sich das genau verhält:

Ein schwerer Kardinalsfehler fällt sofort auf !! Unverständlich wie du den übersehen konntest... ?!
Du hast in der Server Konfig vergessen das lokale LAN IP Segment an die Clients bzw. deren Routing Tabelle zu senden !
Das hätte dir auch sofort selber auffallen müssen auch ohne einen Admininstrator Foren Thread wenn du dort mal ein route print (Windows) eingegeben hättest. Die Route in dein lokales Server Lan 192.168.99.0 /24 ,gemäß der Daten oben, sollte durch diesen Kommando Fehler dort dann fehlen !!
Der Grund ist das fehlende
push "route 192.168.99.0 255.255.255.0"
Kommando in der Server Konfig !
Ohne das ist eine LAN Client Ereichbarkeit technisch unmöglich. Logisch, denn das IP Routing im VPN Client funktioniert so niemals da das 192.168.99.0er Netz dort dann unbekannt bleibt.

Eins oder beide Dinge hast du vermutlich, wie leider so häufig, falsch gemacht oder vergessen zu konfigurieren !
Alle weiteren Details dazu findest du, wie immer, hier im OpenVPN Tutorial oder seinen weiterführenden Links:
Merkzettel: VPN Installation mit OpenVPN
Lesen und verstehen...!

Danke,

der Befehl "push ..." ist irgendwann unbemerkt aus der Konfiguration geflogen, in einer älteren stand dieser noch drin. Nun funktioniert das Routing. Also Einstellungen Lancom waren soweit korrekt.