3
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
Mach ich nun von einem beliebigen Rechner im LAN einen Ping auf einen VPN-Client so erhalte ich folgende Rückmeldung
Vom VPN Server:
Konfiguration OpenVPN sieht wie folgt aus
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 geminiMach 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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 585342
Url: https://administrator.de/contentid/585342
Printed on: April 19, 2024 at 22:04 o'clock
3 Comments
Latest comment
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.
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.
👍
Kleine Ursache...große Wirkung !
Kleine Ursache...große Wirkung !
