25
OpenVPN auf Windows Server 2012R2 - Verbindung steht, aber kein Zugriff auf andere PCs im Netzwerk des Servers
Hallo,
auf einem 2012-R2-Server habe ich den OpenVPN-Server eingerichtet und die Zertifikate erzeugt. Der Server hängt hinter einem DSL-Router mit Portweiterleitung und wird über das Internet (feste WAN-IP) von meinem Client aus verbunden. Von meinem PC (Windows XP) aus kann ich mich problemlos per VPN verbinden und auf den Server zugreifen (Ping, Freigaben, RDP).
Leider ist kein Zugriff (auch kein Ping) auf die anderen PCs im Netzwerk des Servers möglich.
Ich habe schon stundenlang gelesen und rumprobiert, leider ohne Erfolg. Kann mir jemand helfen?
Server-Netz : 192.168.1.x VPN-Netz: 192.168.10.x
Client-Netz: 192.168.4.x Client-PC: 192.168.4.113
Inhalt der server.ovpn:
Inhalt der client.ovpn:
Status wenn VPN-Verbindung steht:
auf einem 2012-R2-Server habe ich den OpenVPN-Server eingerichtet und die Zertifikate erzeugt. Der Server hängt hinter einem DSL-Router mit Portweiterleitung und wird über das Internet (feste WAN-IP) von meinem Client aus verbunden. Von meinem PC (Windows XP) aus kann ich mich problemlos per VPN verbinden und auf den Server zugreifen (Ping, Freigaben, RDP).
Leider ist kein Zugriff (auch kein Ping) auf die anderen PCs im Netzwerk des Servers möglich.
Ich habe schon stundenlang gelesen und rumprobiert, leider ohne Erfolg. Kann mir jemand helfen?
Server-Netz : 192.168.1.x VPN-Netz: 192.168.10.x
Client-Netz: 192.168.4.x Client-PC: 192.168.4.113
Inhalt der server.ovpn:
Inhalt der client.ovpn:
Status wenn VPN-Verbindung steht:
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: 233932
Url: https://administrator.de/contentid/233932
Printed on: April 18, 2024 at 20:04 o'clock
25 Comments
Latest comment
Hallo,
der Server mit OpenVPN muss selber auch in der Lage sein zu routen. Dafür muss Routing und RAS installiert sein, sonst spielt der Server nicht router.
Die Clients im Netzt müssen wiederum auch eine Route zum VPN-Netz kennen. DH entweder muss deren DefaultGateway die Route ins VPN Netz kennen oder jeder einzelne Client muss die Route mitgeteilt bekommen.
Der Router zwischen Netzt und VPN-Netz muss natürlich der der Server 2012 sein der die OpenVPN Verbindung hält, und dort müssen Routingdienste drauf sein, sonst interessieren ihn die Anfragen nicht.
Gruß
Chonta
der Server mit OpenVPN muss selber auch in der Lage sein zu routen. Dafür muss Routing und RAS installiert sein, sonst spielt der Server nicht router.
Die Clients im Netzt müssen wiederum auch eine Route zum VPN-Netz kennen. DH entweder muss deren DefaultGateway die Route ins VPN Netz kennen oder jeder einzelne Client muss die Route mitgeteilt bekommen.
Der Router zwischen Netzt und VPN-Netz muss natürlich der der Server 2012 sein der die OpenVPN Verbindung hält, und dort müssen Routingdienste drauf sein, sonst interessieren ihn die Anfragen nicht.
Gruß
Chonta
1
Hi,
zu @Chonta´s Ausführungen möchte ich noch folgendes ergänzen.
Du hast unterschiedliche Netze zwischen OpenVPN-Server und Client.
Das ist Ok so, aber dazu solltest Du für den Tunnel das TUN-Devive nutzen und nicht das TAP.
Gruß orcape
zu @Chonta´s Ausführungen möchte ich noch folgendes ergänzen.
Du hast unterschiedliche Netze zwischen OpenVPN-Server und Client.
Das ist Ok so, aber dazu solltest Du für den Tunnel das TUN-Devive nutzen und nicht das TAP.
Gruß orcape
1
Grundlagen erklärt dieses Tutorial:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die Konfiguration ist identisch, denn sie ist bei OVPN immer Hardware unabhängig !
Wichtig im Winblows Umfeld ist immer die lokale Firewall. Das das interne OVPN Tunnelnetz auf einer separaten IP rennt musst du hier die Firewall anpassen, da die sonst alles was von nicht lokalen Absender IP Adressen kommt verwirft ! Beachte das immer !
Das gilt oft auch für ICMP Pakete (Ping, Traceroute etc.)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die Konfiguration ist identisch, denn sie ist bei OVPN immer Hardware unabhängig !
Wichtig im Winblows Umfeld ist immer die lokale Firewall. Das das interne OVPN Tunnelnetz auf einer separaten IP rennt musst du hier die Firewall anpassen, da die sonst alles was von nicht lokalen Absender IP Adressen kommt verwirft ! Beachte das immer !
Das gilt oft auch für ICMP Pakete (Ping, Traceroute etc.)
1
Erstmal danke für die schnellen Antworten.
Also "Routing und RAS" ist am Server installiert, es wurden aber bisher keine manuellen Anpassungen gemacht.
Die Zeile
push "route 192.168.1.0 255.255.255.0"
müsste dem entfernten Client doch eigentlich die richtige Route mitteilen, oder habe ich das falsch verstanden?
Die Rechner im Server-Netzwerk sollen von mir erreicht werden (vorrangig für Fernwartung), müssen aber selbst nicht über den VPN-Tunnel herauskommen.
Im (VPN-)Server-Netzwerk ist bisher der DSL-Router als Gateway in den PCs hinterlegt.
Also "Routing und RAS" ist am Server installiert, es wurden aber bisher keine manuellen Anpassungen gemacht.
Die Zeile
push "route 192.168.1.0 255.255.255.0"
müsste dem entfernten Client doch eigentlich die richtige Route mitteilen, oder habe ich das falsch verstanden?
Die Rechner im Server-Netzwerk sollen von mir erreicht werden (vorrangig für Fernwartung), müssen aber selbst nicht über den VPN-Tunnel herauskommen.
Im (VPN-)Server-Netzwerk ist bisher der DSL-Router als Gateway in den PCs hinterlegt.
Zitat von @orcape:
Das ist Ok so, aber dazu solltest Du für den Tunnel das TUN-Devive nutzen und nicht das TAP.
Das ist Ok so, aber dazu solltest Du für den Tunnel das TUN-Devive nutzen und nicht das TAP.
Kann man das einfach nachträglich in den Config-Dateien auf Server und Client ändern?
Das hatte ich nämlich schon mal umgestellt, dann hat der Verbindungsaufbau aber nicht mehr funktioniert.
Zitat von @aqui:
Wichtig im Winblows Umfeld ist immer die lokale Firewall. Das das interne OVPN Tunnelnetz auf einer separaten IP rennt musst du
hier die Firewall anpassen, da die sonst alles was von nicht lokalen Absender IP Adressen kommt verwirft ! Beachte das immer !
Das gilt oft auch für ICMP Pakete (Ping, Traceroute etc.)
Wichtig im Winblows Umfeld ist immer die lokale Firewall. Das das interne OVPN Tunnelnetz auf einer separaten IP rennt musst du
hier die Firewall anpassen, da die sonst alles was von nicht lokalen Absender IP Adressen kommt verwirft ! Beachte das immer !
Das gilt oft auch für ICMP Pakete (Ping, Traceroute etc.)
Die Windows-Firewall am Server ist deaktiviert.
Kann man das einfach nachträglich in den Config-Dateien auf Server und Client ändern?
..natürlich, warum nicht.Das hatte ich nämlich schon mal umgestellt, dann hat der Verbindungsaufbau aber nicht mehr funktioniert.
Dann hast Du noch einen anderen Fehler in der Config.Gruß orcape
Zitat von @orcape:
> Das hatte ich nämlich schon mal umgestellt, dann hat der Verbindungsaufbau aber nicht mehr funktioniert.
Dann hast Du noch einen anderen Fehler in der Config.
> Das hatte ich nämlich schon mal umgestellt, dann hat der Verbindungsaufbau aber nicht mehr funktioniert.
Dann hast Du noch einen anderen Fehler in der Config.
Ich habe jetzt am Server und am Client "dev tap" in "dev tun" geändert und den Serverdienst neu gestartet.
Die Verbindung (die mit tap funktioniert) wird dann nicht mehr aufgebaut.
In der client.log steht nun trotzdem:
...
WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
danach folgt noch das:
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1574'
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
[FuWOpenVPN] Peer Connection Initiated with [AF_INET]xx.xxx.xxx.xxx:1194 // echte IP-Adresse entfernt
MANAGEMENT: >STATE:1396020658,GET_CONFIG,,,
SENT CONTROL [FuWOpenVPN]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.10.1,ping 10,ping-restart 120,ifconfig 192.168.10.2 255.255.255.0'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route-related options modified
WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.0) that looks more like a netmask. (silence this warning with --ifconfig-nowarn)
do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
MANAGEMENT: >STATE:1396020660,ASSIGN_IP,,192.168.10.2,
MANAGEMENT: Client disconnected
There is a problem in your selection of --ifconfig endpoints [local=192.168.10.2, remote=255.255.255.0]. The local and remote VPN endpoints must exist within the same 255.255.255.252 subnet. This is a limitation of --dev tun when used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets' option for more info.
Exiting due to fatal error
Hier noch die server.log vom VPN-Server
Fri Mar 28 16:23:14 2014 Diffie-Hellman initialized with 1024 bit key
Fri Mar 28 16:23:14 2014 Socket Buffers: R=[65536->65536] S=[65536->65536]
Fri Mar 28 16:23:14 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Mar 28 16:23:14 2014 open_tun, tt->ipv6=0
Fri Mar 28 16:23:14 2014 CreateFile failed on TAP device: \\.\Global\{D7B46AB9-002C-426C-868F-881DA59109DF}.tap
Fri Mar 28 16:23:14 2014 All TAP-Windows adapters on this system are currently in use.
Fri Mar 28 16:23:14 2014 Exiting due to fatal error
Was ist hier gemeint? Den VPN-Netzwerkadapter habe ich auch schon neu aktiviert, ohne Erfolg.
Hallo,
es müssen bei beiden tun oder tap sein.
Und die Werte für mtu müssen auch gleich sein.
Ist das lokale Netz vom Client auch im Netz 192.168.10.0/24 wenn ja dumm gelaufen.
Gruß
Chonta
es müssen bei beiden tun oder tap sein.
Und die Werte für mtu müssen auch gleich sein.
Ist das lokale Netz vom Client auch im Netz 192.168.10.0/24 wenn ja dumm gelaufen.
Gruß
Chonta
Ja, sind sie auch, darum verstehe ich die Fehlermeldung nicht.
Der OpenVPN-Dienst wurde nach jeder Änderung neu gestartet.
Und die Werte für mtu müssen auch gleich sein.
mtu war bis jetzt in den Config-Dateien nicht angegeben, ich habe jetzt mal "mssfix" und "tun-mtu 1500" probiert, die Fehlermeldung bleibt gleich.
Ist das lokale Netz vom Client auch im Netz 192.168.10.0/24 wenn ja dumm gelaufen.
Nein, lokal ist 192.168.4.x fern ist 192.168.1.x.
WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
...ist ja auch eindeutig, der Server hat immer noch das TAP-Device aktiviert.
Hallo,
dann wird irgendwo die falshce config geladen, sonst würde der Fheler nicht kommen.
Gruß
Chonta
dann wird irgendwo die falshce config geladen, sonst würde der Fheler nicht kommen.
Gruß
Chonta
Zitat von @orcape:
> WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
...ist ja auch eindeutig, der Server hat immer noch das TAP-Device aktiviert.
> WARNING: 'dev-type' is used inconsistently, local='dev-type tun', remote='dev-type tap'
...ist ja auch eindeutig, der Server hat immer noch das TAP-Device aktiviert.
Ja, aber warum nur?
In der server.ovpn steht nur "dev tun", der Dienst OpenVPNService wurde nach der Änderung mehrfach neu gestartet.
Muss da an anderer Stelle noch etwas geändert werden?
Scheinbar hat der virt. Netzwerkadapter ja ein Problem (siehe 3 Beiträge weiter oben "...server.log vom VPN-Server").
http://www.online-tutorials.net/security/openvpn-tutorial/tutorials-t-6 ...
Sorry, wenn´s das nicht war, hab mit Windows nicht so die Erfahrung..
Gruß orcape
Versichern Sie sich, das Sie die Option CONFIG_TUN (Device Drivers->Network Device Support>Universal TUN/TAP
Device Driver Support) auf y oder Module gestellt und gegebenenfalls das Modul geladen haben.
...das wird wohl bei Dir auf dem Server noch nicht so eingerichtet sein.Device Driver Support) auf y oder Module gestellt und gegebenenfalls das Modul geladen haben.
Sorry, wenn´s das nicht war, hab mit Windows nicht so die Erfahrung..
Gruß orcape
Ok jetzt hab ich zumindest den einen Fehler gefunden.
Im config-Ordner waren noch andere Sicherungs-Dateien mit der Endung ".ovpn". Der Server scheint irgendeine davon zu verwenden, aber nicht unbedingt die "server.ovpn".
Jetzt kommt schon mal eine andere Ausgabe:
Fri Mar 28 17:21:15 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {2BE42029-5593-4DF6-AB25-8A3787ABB48D} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Fri Mar 28 17:21:15 2014 NOTE: FlushIpNetTable failed on interface [65540] {2BE42029-5593-4DF6-AB25-8A3787ABB48D} (status=259) : Es sind keine Daten mehr verfügbar.
Fri Mar 28 17:21:20 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:20 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:25 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:25 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:27 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:27 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:28 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:28 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:30 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:30 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:31 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:31 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:32 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Ich werde nächste Woche weiter probieren...
Im config-Ordner waren noch andere Sicherungs-Dateien mit der Endung ".ovpn". Der Server scheint irgendeine davon zu verwenden, aber nicht unbedingt die "server.ovpn".
Jetzt kommt schon mal eine andere Ausgabe:
Fri Mar 28 17:21:15 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.10.6/255.255.255.252 on interface {2BE42029-5593-4DF6-AB25-8A3787ABB48D} [DHCP-serv: 192.168.10.5, lease-time: 31536000]
Fri Mar 28 17:21:15 2014 NOTE: FlushIpNetTable failed on interface [65540] {2BE42029-5593-4DF6-AB25-8A3787ABB48D} (status=259) : Es sind keine Daten mehr verfügbar.
Fri Mar 28 17:21:20 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:20 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:25 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:25 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:27 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:27 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:28 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:28 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:30 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:30 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:31 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Fri Mar 28 17:21:31 2014 Route: Waiting for TUN/TAP interface to come up...
Fri Mar 28 17:21:32 2014 TEST ROUTES: 1/2 succeeded len=2 ret=0 a=0 u/d=up
Ich werde nächste Woche weiter probieren...
Ich werde nächste Woche weiter probieren...
...ich mach bei solchen Sachen immer Nachtschichten und Sondereinsätze...Gruß und Schönes WE orcape
Hallo,
also wenn ich Probleme mit OpenVPN hatte, dann lag es immer an meinem Windowsclient. OpenVPN-Serve rist bei mir Linux.
Manchmal konnte OpenVPN bei mir nicht den Arpcache löschen und ohne keine Verbindung.
Da musste Teilweise die aktuellste OpenVPN-Version installiert werden und das System neu gestartet wrden und dannn gleich nach dem Neustart OpenVPN gestartet und verbunden werden damit es klappt.
Gruß
Chonta
also wenn ich Probleme mit OpenVPN hatte, dann lag es immer an meinem Windowsclient. OpenVPN-Serve rist bei mir Linux.
Manchmal konnte OpenVPN bei mir nicht den Arpcache löschen und ohne keine Verbindung.
Da musste Teilweise die aktuellste OpenVPN-Version installiert werden und das System neu gestartet wrden und dannn gleich nach dem Neustart OpenVPN gestartet und verbunden werden damit es klappt.
Gruß
Chonta
Hallo,
in einem WindowsServer >= 2008 sollte man den Firewalldienst nicht deaktivieren, sondern konfigurieren!
Alle drei Profile auf 'durchzug' setzen und später nach Bedarf wieder reglementieren.
Routing- und RAS-Service ist meiner Meinung nach nicht notwendig, aber das interne Routing (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter=1) muss aktiviert sein.
vG
LS
in einem WindowsServer >= 2008 sollte man den Firewalldienst nicht deaktivieren, sondern konfigurieren!
Alle drei Profile auf 'durchzug' setzen und später nach Bedarf wieder reglementieren.
Routing- und RAS-Service ist meiner Meinung nach nicht notwendig, aber das interne Routing (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter=1) muss aktiviert sein.
vG
LS
1
So, der Verbindungsaufbau funktioniert nun auch im TUN-Modus, ich musste nach der Umstellung von TAP beide Netzwerkadapter einmal deaktivieren und wieder aktivieren.
Routing und RAS habe ich am Server wieder deaktiviert
Nachdem ich dann noch (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter=1) eingestellt und den Server neu gestartet habe, kann ich nun auch die IP 192.168.1.5 der echten Netzwerkkarte des OpenVPN-Servers anpingen, das ging vorher nicht.
Die anderen PCs im Netz 192.168.1.x sind vom VPN-Client leider immer noch nicht per Ping erreichbar (vom VPN-Server aus über das lokale Netz aber schon).
VPN-Netz ist weiterhin die 192.168.10.x
Lokales Netz auf Client-Seite ist 192.168.4.x
Die server.ovpn sieht nun so aus:
client-log nach Verbindungsaufbau:
Am VPN-Server ist keine Netzwerkbrücke zwischen dem echten Ethernet- und dem TAP-Adapter eingerichtet. Das Routing sollte doch auch ohne gehen, hoffe ich. Ich kann das nicht einfach testen, da der Server produktiv eingesetzt ist.
Hat noch jemand eine Idee, wie ich auf die anderen Clients komme?
Routing und RAS habe ich am Server wieder deaktiviert
Nachdem ich dann noch (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter=1) eingestellt und den Server neu gestartet habe, kann ich nun auch die IP 192.168.1.5 der echten Netzwerkkarte des OpenVPN-Servers anpingen, das ging vorher nicht.
Die anderen PCs im Netz 192.168.1.x sind vom VPN-Client leider immer noch nicht per Ping erreichbar (vom VPN-Server aus über das lokale Netz aber schon).
VPN-Netz ist weiterhin die 192.168.10.x
Lokales Netz auf Client-Seite ist 192.168.4.x
Die server.ovpn sieht nun so aus:
client-log nach Verbindungsaufbau:
Am VPN-Server ist keine Netzwerkbrücke zwischen dem echten Ethernet- und dem TAP-Adapter eingerichtet. Das Routing sollte doch auch ohne gehen, hoffe ich. Ich kann das nicht einfach testen, da der Server produktiv eingesetzt ist.
Hat noch jemand eine Idee, wie ich auf die anderen Clients komme?
Hallo,
mit push "route 192.168.1.0 255.255.255.0" gibst Du den VPN-Client den Weg in das 192.168.1.0 - Netz mit.
Nun müssen die anderen PCs im Netz 192.168.1.0 auch wissen, wie die Pakete zurück (zum VPN-Client) kommen. Dafür benötigen diese wiederum eine Route für das VPN-Netz (192.168.10.0). Variante 1: auf allen PCs "route -p add 192.168.10.0 mask 255.255.255.0 192.168.1.5"
Variante 2: diese Route auf dem Standardgateway im LAN einstellen.
vG
LS
mit push "route 192.168.1.0 255.255.255.0" gibst Du den VPN-Client den Weg in das 192.168.1.0 - Netz mit.
Nun müssen die anderen PCs im Netz 192.168.1.0 auch wissen, wie die Pakete zurück (zum VPN-Client) kommen. Dafür benötigen diese wiederum eine Route für das VPN-Netz (192.168.10.0). Variante 1: auf allen PCs "route -p add 192.168.10.0 mask 255.255.255.0 192.168.1.5"
Variante 2: diese Route auf dem Standardgateway im LAN einstellen.
vG
LS
1Zitat von @laster:
mit push "route 192.168.1.0 255.255.255.0" gibst Du den VPN-Client den Weg in das 192.168.1.0 - Netz mit.
Nun müssen die anderen PCs im Netz 192.168.1.0 auch wissen, wie die Pakete zurück (zum VPN-Client) kommen. Dafür
benötigen diese wiederum eine Route für das VPN-Netz (192.168.10.0). Variante 1: auf allen PCs "route -p add
192.168.10.0 mask 255.255.255.0 192.168.1.5"
mit push "route 192.168.1.0 255.255.255.0" gibst Du den VPN-Client den Weg in das 192.168.1.0 - Netz mit.
Nun müssen die anderen PCs im Netz 192.168.1.0 auch wissen, wie die Pakete zurück (zum VPN-Client) kommen. Dafür
benötigen diese wiederum eine Route für das VPN-Netz (192.168.10.0). Variante 1: auf allen PCs "route -p add
192.168.10.0 mask 255.255.255.0 192.168.1.5"
Da zu den Clients auch 2 SPS-Steuerungen gehören, muss ich das wohl am Router einstellen. Bei der SPS kann ein Gateway angegeben werden.
Variante 2: diese Route auf dem Standardgateway im LAN einstellen.
Am eingesetzten DSL-Router "Speedport 723V" (ist der Standardgateway der Client-PCs) können leider keine manuelle Routen gesetzt werden, da muss wohl ein anderer Router ran. Wahrscheinlich werde ich einen Lancom-Router bestellen, dann kann notfalls auch der (kostenpflichtige) Lancom-VPN-Client verwendet werden. Diese Konstellation habe ich schon bei anderen Kunden mit SPS-Fernwartung im Einsatz. Der Windows-Server selbst soll nicht als Router verwendet werden.
Aus Zeitgründen habe ich nun erst einmal einen PPTP-Zugang am Server eingerichtet (das Sicherheitsproblem ist mir bekannt). Damit komme ich sofort auf alle Clients. Wirklich schade, dass das mit OpenVPN nicht so einfach funktioniert.
Welche (DSL-)Router unterstützen eigentlich ab Werk OpenVPN?
Ich kenne die Unterstützung nur von meiner privaten Vodafone-Easybox 904x, da hat der Fernzugriff per OpenVPN-Windows-Client (im Bridge-Mode) sofort funktioniert, incl. Zugriff auf alle Geräte hinter der Box.
Bis hierher erst einmal vielen Dank für eure Tipps. Sollte ich per OpenVPN doch noch zum Ziel kommen, werden ich mich nochmal melden.
Hallo mv2014,
die meisten Router/Firewalls können Routen einstellen.
Wir verwenden meistens SonicWALL - z.B. eine TZ100, die kann neben deep packet inspection auch mit dem kostenlosen Global-VPN-Client (IPSec) oder mit min. 2 NetExtender (SSL-VPN), den gibt für jedes OS.
vG und Erfolg
LS
die meisten Router/Firewalls können Routen einstellen.
Wir verwenden meistens SonicWALL - z.B. eine TZ100, die kann neben deep packet inspection auch mit dem kostenlosen Global-VPN-Client (IPSec) oder mit min. 2 NetExtender (SSL-VPN), den gibt für jedes OS.
vG und Erfolg
LS
Hallo,
funktioniert auch mit OpenVPN einfach, sicher, schnell.
Es muss halt wie alles in der IT richtig konfiguriert werden bzw. es muss die richtige Hardware verwendet werden (z.B. ein Router der auch statische Routen kann).
Du könntest dich natürlich auch eifach mit OpenVPN einwählen und dann über den Tunnel eine RDP Sitzung zum Server aufbauen und über diese Sitzung dann auf die Netzwerkresourcen zugreifen.
Oder Du installierst auf deinem Server Routing und RAS und lässt den das Defaultgateway für das Netzwerk sein und das Gateway vom Server bleibt der Speedport.
Gruß
Chonta
funktioniert auch mit OpenVPN einfach, sicher, schnell.
Es muss halt wie alles in der IT richtig konfiguriert werden bzw. es muss die richtige Hardware verwendet werden (z.B. ein Router der auch statische Routen kann).
Du könntest dich natürlich auch eifach mit OpenVPN einwählen und dann über den Tunnel eine RDP Sitzung zum Server aufbauen und über diese Sitzung dann auf die Netzwerkresourcen zugreifen.
Oder Du installierst auf deinem Server Routing und RAS und lässt den das Defaultgateway für das Netzwerk sein und das Gateway vom Server bleibt der Speedport.
Gruß
Chonta
Hi mv2014,
wenn Dir auf Deinem Server keine Firewall in die Suppe spuckt, sollten auch die Clients des 192.168.1.0 255.255.255.0 Netzes erreichbar sein.
Poste doch mal die Routing-Protokolle, allein von Server- bzw. Client-Logs, lässt sich nur ableiten, ob Dein Tunnel funktioniert.
http://dd-wrt.com/site/support/router-database
...und damit sieht das schon wieder besser aus.
Gruß orcape
wenn Dir auf Deinem Server keine Firewall in die Suppe spuckt, sollten auch die Clients des 192.168.1.0 255.255.255.0 Netzes erreichbar sein.
Poste doch mal die Routing-Protokolle, allein von Server- bzw. Client-Logs, lässt sich nur ableiten, ob Dein Tunnel funktioniert.
Welche (DSL-)Router unterstützen eigentlich ab Werk OpenVPN?
..gute Frage ???, aber da hilft....http://dd-wrt.com/site/support/router-database
...und damit sieht das schon wieder besser aus.
Gruß orcape
