14
OpenVpn client sieht keine lokalen Shares - route hinzufügen wie?
wie bekomme ich den ics-client dazu die ics-server-shares zu sehen?
Hy!
Ich denke die Lösung ist eine Route zu setzen, aber ich weiss nicht welche/wie diese geht..
folgendes am win 7 computer:
Nic1 (ics Client 192.168.1.137) | tap0 (10.0.0.2, ics-server) | Nic2 (192.168.0.18 - hängt am inet-router)
|
|
|
client (192.168.1.137)
Also Nic1 ist der ics-client von tap0 (ics-server). tap0 bildet den vpn-tunnel zum internet (push "redirect-gateway def1 vom vpn-server). client hängt am ics-client nic und geht somit über tap0 ins internet. auch win 7 computer bezieht seine inet connection über den tunnel (der tunnel wird über nic2 hinaus gebildet, da nic2 am inet hängt) funktioniert fein. (nic 2 hat direktes internet, aber client soll nicht über dieses ins inet, passst soweit). aber die shares gehen nicht über nic1.
am win 7 computer sind smb-shares freigegeben, diese sieht client aber nicht. wohl deshalb weil der vpn server 'push "redirect-gateway def1 ' ausgibt und nic1 daher nur über tap0 rausgeht. soll ja auch so sein.
aber client soll auch shares am win 7 pc sehen können. warum er das nicht tut ist mir ein rätsel, ich hab ja nirgends festgelegt, dass shares nur an nic2 gebunden sind, also müssten die shares auch über nic1 erreichbar sein.. an allen nics ist datei-und druckerfreigabe aktiviert.
meine idee ist jetzt zusätzlich zur gateway route zu tap0 eine route zu setzen "192.168.1.137 -> 192.168.0.18", damit client auf die shares zugreifen kann aber weiterhin über tap0 ins inet geht.
hab folgendes probiert aber ohne erfolg:
win 7 computer cmd:
route add 192.168.1.137 192.168.0.18
und auch
route add 192.168.0.18 192.168.1.137
wo liegt der hund begraben??
thx!
Hy!
Ich denke die Lösung ist eine Route zu setzen, aber ich weiss nicht welche/wie diese geht..
folgendes am win 7 computer:
Nic1 (ics Client 192.168.1.137) | tap0 (10.0.0.2, ics-server) | Nic2 (192.168.0.18 - hängt am inet-router)
|
|
|
client (192.168.1.137)
Also Nic1 ist der ics-client von tap0 (ics-server). tap0 bildet den vpn-tunnel zum internet (push "redirect-gateway def1 vom vpn-server). client hängt am ics-client nic und geht somit über tap0 ins internet. auch win 7 computer bezieht seine inet connection über den tunnel (der tunnel wird über nic2 hinaus gebildet, da nic2 am inet hängt) funktioniert fein. (nic 2 hat direktes internet, aber client soll nicht über dieses ins inet, passst soweit). aber die shares gehen nicht über nic1.
am win 7 computer sind smb-shares freigegeben, diese sieht client aber nicht. wohl deshalb weil der vpn server 'push "redirect-gateway def1 ' ausgibt und nic1 daher nur über tap0 rausgeht. soll ja auch so sein.
aber client soll auch shares am win 7 pc sehen können. warum er das nicht tut ist mir ein rätsel, ich hab ja nirgends festgelegt, dass shares nur an nic2 gebunden sind, also müssten die shares auch über nic1 erreichbar sein.. an allen nics ist datei-und druckerfreigabe aktiviert.
meine idee ist jetzt zusätzlich zur gateway route zu tap0 eine route zu setzen "192.168.1.137 -> 192.168.0.18", damit client auf die shares zugreifen kann aber weiterhin über tap0 ins inet geht.
hab folgendes probiert aber ohne erfolg:
win 7 computer cmd:
route add 192.168.1.137 192.168.0.18
und auch
route add 192.168.0.18 192.168.1.137
wo liegt der hund begraben??
thx!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177089
Url: https://administrator.de/contentid/177089
Ausgedruckt am: 23.11.2024 um 02:11 Uhr
14 Kommentare
Neuester Kommentar
Naja ..
falsche Syntax halt.
route -p add <ip adresse> mask <netmaske> <gateway>
nicht
route add <ipadresse1> <ipadresse2>
Beispiel :
Gehe über Gateway 47.11.08.15 ins Netz 192.168.0.x mit der Netzmaske 255.255.255.128 würde man so machen...
route -p add 192.168.0.0 mask 255.255.255.128 47.11.08.15
Dabei steht das -p für persistent, ich gehe mal davon aus du möchtest das nicht nach jedem Rechnereboot wieder machen
falsche Syntax halt.
route -p add <ip adresse> mask <netmaske> <gateway>
nicht
route add <ipadresse1> <ipadresse2>
Beispiel :
Gehe über Gateway 47.11.08.15 ins Netz 192.168.0.x mit der Netzmaske 255.255.255.128 würde man so machen...
route -p add 192.168.0.0 mask 255.255.255.128 47.11.08.15
Dabei steht das -p für persistent, ich gehe mal davon aus du möchtest das nicht nach jedem Rechnereboot wieder machen
Wenn ich mir deinen Post noch mal durchlese vermute ich (über meine große mächtige Glaskugel) das du außerdem eine
rückroute brauchst, damit der weiß das er über das vpn netz in dein privates netz zurück kommt.
Selbst dann ist aber noch nicht gesagt das dein client die shares sieht.
Da spielen noch so sachen eine Rolle, wie die windows firewalls (port 445 und 139) oder meist wird der openvpn server ja auch eine firewallappliance installiert -
die muss natürlich auch erlauben das du in dein netz darfst.
Schlussendlich ist CIFS halt auch noch ###e, auch kein zu unterschätzender Punkt...
rückroute brauchst, damit der weiß das er über das vpn netz in dein privates netz zurück kommt.
Selbst dann ist aber noch nicht gesagt das dein client die shares sieht.
Da spielen noch so sachen eine Rolle, wie die windows firewalls (port 445 und 139) oder meist wird der openvpn server ja auch eine firewallappliance installiert -
die muss natürlich auch erlauben das du in dein netz darfst.
Schlussendlich ist CIFS halt auch noch ###e, auch kein zu unterschätzender Punkt...
@peter9999
Nein, die statischen Routen sind generell überflüssig und sinnlos auf dem Client. Man kann (und sollte) sie gleich automatisch mit dem Client Login setzen lassen !
Das geht mit dem push route... Kommando in der Server Konfig Datei und ist der sinnvollste Weg !
Dieses Tutorial erklärt die alle Schritte im Detail: (Die Suchfunktion lässt grüßen !)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW Plattform spielt dabei keinerlei Rolle, denn die Open VPN Konfig und ToDos ist überall immer gleich !!
Damit sollte es dann auf Anhieb klappen ! Du kannst die richtigen Routen auch immer mit dem route print Kommando überprüfen !! Vergiss also diesen Unsinn mit statischen Routen oben !
Nochwas: Wenn du mit "Shares sehen" die Netzwerkumgebung meinst, das klappt nicht, denn ohne einen DNS bzw. AD basiert dieser Prozess auf UDP Broadcasts. (Naming Service)
UDP Broadcasts werden aber wie jeder Netzwerk weiss per se nicht über geroutete Verbindungen übertragen. Scheinbar ist dir diese Umstand wohl nciht bekannt und du rätst dann etwas planlos in der Routing Sackgasse rum, was damit gar nix zu tun hat. Ein simpler Ping zwischen Client und Ziel hätte dir das auch gezeigt.
Du musst dann also beim Verbinden auf Shares immer deren IP Adressen verwenden ala Start -> Ausführen \\<ip_address>\share oder im Datei Explorer.
Alternativ kannst du bei den remoten Clients den Namen des Share Servers statisch in die hosts Datei eintragen und dann auch wieder den namen verwenden.
Wie das geht steht hier:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Alternativ bietet OpenVPN eine UDP Helper Funktion (Proxy) um ggf. diese Naming Broadcasts zu forwarden. Das o.a. Tutorial geht auf dieses Detail auch ein.
Für den ersten Schritt ist es aber erstmal einfacher die IPs zu verwenden oder mit statischen Namen zu arbeiten !
P.S.: Deine Shift Taste ist defekt !!
Nein, die statischen Routen sind generell überflüssig und sinnlos auf dem Client. Man kann (und sollte) sie gleich automatisch mit dem Client Login setzen lassen !
Das geht mit dem push route... Kommando in der Server Konfig Datei und ist der sinnvollste Weg !
Dieses Tutorial erklärt die alle Schritte im Detail: (Die Suchfunktion lässt grüßen !)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW Plattform spielt dabei keinerlei Rolle, denn die Open VPN Konfig und ToDos ist überall immer gleich !!
Damit sollte es dann auf Anhieb klappen ! Du kannst die richtigen Routen auch immer mit dem route print Kommando überprüfen !! Vergiss also diesen Unsinn mit statischen Routen oben !
Nochwas: Wenn du mit "Shares sehen" die Netzwerkumgebung meinst, das klappt nicht, denn ohne einen DNS bzw. AD basiert dieser Prozess auf UDP Broadcasts. (Naming Service)
UDP Broadcasts werden aber wie jeder Netzwerk weiss per se nicht über geroutete Verbindungen übertragen. Scheinbar ist dir diese Umstand wohl nciht bekannt und du rätst dann etwas planlos in der Routing Sackgasse rum, was damit gar nix zu tun hat. Ein simpler Ping zwischen Client und Ziel hätte dir das auch gezeigt.
Du musst dann also beim Verbinden auf Shares immer deren IP Adressen verwenden ala Start -> Ausführen \\<ip_address>\share oder im Datei Explorer.
Alternativ kannst du bei den remoten Clients den Namen des Share Servers statisch in die hosts Datei eintragen und dann auch wieder den namen verwenden.
Wie das geht steht hier:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Alternativ bietet OpenVPN eine UDP Helper Funktion (Proxy) um ggf. diese Naming Broadcasts zu forwarden. Das o.a. Tutorial geht auf dieses Detail auch ein.
Für den ersten Schritt ist es aber erstmal einfacher die IPs zu verwenden oder mit statischen Namen zu arbeiten !
P.S.: Deine Shift Taste ist defekt !!
Zitat von @aqui:
@peter9999
Nein, die statischen Routen sind generell überflüssig und sinnlos auf dem Client. Man kann (und sollte) sie gleich
automatisch mit dem Client Login setzen lassen !
Das geht mit dem push route... Kommando in der Server Konfig Datei und ist der sinnvollste Weg !
Dieses Tutorial erklärt die alle Schritte im Detail: (Die Suchfunktion lässt grüßen !)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW Plattform spielt dabei keinerlei Rolle, denn die Open VPN Konfig und ToDos ist überall immer gleich !!
Damit sollte es dann auf Anhieb klappen ! Du kannst die richtigen Routen auch immer mit dem route print Kommando
überprüfen !! Vergiss also diesen Unsinn mit statischen Routen oben !
Nochwas: Wenn du mit "Shares sehen" die Netzwerkumgebung meinst, das klappt nicht, denn ohne einen DNS bzw. AD basiert
dieser Prozess auf UDP Broadcasts. (Naming Service)
UDP Broadcasts werden aber wie jeder Netzwerk weiss per se nicht über geroutete Verbindungen übertragen. Scheinbar ist
dir diese Umstand wohl nciht bekannt und du rätst dann etwas planlos in der Routing Sackgasse rum, was damit gar nix zu
tun hat. Ein simpler Ping zwischen Client und Ziel hätte dir das auch gezeigt.
Du musst dann also beim Verbinden auf Shares immer deren IP Adressen verwenden ala Start -> Ausführen
\\<ip_address>\share oder im Datei Explorer.
Alternativ kannst du bei den remoten Clients den Namen des Share Servers statisch in die hosts Datei eintragen und dann auch
wieder den namen verwenden.
Wie das geht steht hier:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Alternativ bietet OpenVPN eine UDP Helper Funktion (Proxy) um ggf. diese Naming Broadcasts zu forwarden. Das o.a. Tutorial geht
auf dieses Detail auch ein.
Für den ersten Schritt ist es aber erstmal einfacher die IPs zu verwenden oder mit statischen Namen zu arbeiten !
P.S.: Deine Shift Taste ist defekt !!
@peter9999
Nein, die statischen Routen sind generell überflüssig und sinnlos auf dem Client. Man kann (und sollte) sie gleich
automatisch mit dem Client Login setzen lassen !
Das geht mit dem push route... Kommando in der Server Konfig Datei und ist der sinnvollste Weg !
Dieses Tutorial erklärt die alle Schritte im Detail: (Die Suchfunktion lässt grüßen !)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Die HW Plattform spielt dabei keinerlei Rolle, denn die Open VPN Konfig und ToDos ist überall immer gleich !!
Damit sollte es dann auf Anhieb klappen ! Du kannst die richtigen Routen auch immer mit dem route print Kommando
überprüfen !! Vergiss also diesen Unsinn mit statischen Routen oben !
Nochwas: Wenn du mit "Shares sehen" die Netzwerkumgebung meinst, das klappt nicht, denn ohne einen DNS bzw. AD basiert
dieser Prozess auf UDP Broadcasts. (Naming Service)
UDP Broadcasts werden aber wie jeder Netzwerk weiss per se nicht über geroutete Verbindungen übertragen. Scheinbar ist
dir diese Umstand wohl nciht bekannt und du rätst dann etwas planlos in der Routing Sackgasse rum, was damit gar nix zu
tun hat. Ein simpler Ping zwischen Client und Ziel hätte dir das auch gezeigt.
Du musst dann also beim Verbinden auf Shares immer deren IP Adressen verwenden ala Start -> Ausführen
\\<ip_address>\share oder im Datei Explorer.
Alternativ kannst du bei den remoten Clients den Namen des Share Servers statisch in die hosts Datei eintragen und dann auch
wieder den namen verwenden.
Wie das geht steht hier:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Alternativ bietet OpenVPN eine UDP Helper Funktion (Proxy) um ggf. diese Naming Broadcasts zu forwarden. Das o.a. Tutorial geht
auf dieses Detail auch ein.
Für den ersten Schritt ist es aber erstmal einfacher die IPs zu verwenden oder mit statischen Namen zu arbeiten !
P.S.: Deine Shift Taste ist defekt !!
Beim ersten teil hat aqui absolut recht.
Das Du es dir da irgendwie unnötig schwer machst, habe ich irgendwie verpeilt noch mit da hin zu schreiben.
Trotzdem ist die Syntax deiner Routen grundsätzlich falsch.
Beim zweiten Teil bin ich noch ein bisschen hin und her gerissen.
Ich habe zu Hause gerade ein ähnliches Problem.
Ich habe auf er einen seite eine AD und auf der anderen einen Client der aus einer Workgroup in der AD Shares mappen möchte.
Ich habe meine Routen per push in der Config richtig gesetzt und trotzdem bringt mir \\ipadresse\share keinen Erfolg, ping und RDP gehen hingegen.
Es muss dort noch einen anderen Haken geben außer Firewall und Routen, an dem es sich entscheidet ob ein Rechner aus einem privaten Fremdnetz ein Share über openVPn aus einem anderen privaten netz sehen darf.
Was heisst "keinen Erfolg" ?? Was ist der Fehler bzw. Fehlermeldung ?? Vermutlich das du keine Rechte hast.
Das ist auch ganz normal, denn in der obigen Konstallation ist es einzig und allein ein Rechte Problem unter Windows. (sofern du Firewall bzw. Firewall Profil bei Win7 sicher ausschliessen kannst. Bedenek das Win 7 auf dem VPN Adapter ein privates oder Arbeitsplatz FW Profil haben muss !) Die Zugriffsberechtigungen aufs Share sind falsch.
Mit dem Netzwerk an sich und dem VPN hat das rein gar nichts zu tun, denn das ist nur einzig für die Wegefindung (IP Adressierung) zuständig !
Ein Router, und dazu gehört auch der OpenVPN Router, kümmert sich lediglich um das Forwarding der IP Adressen...mehr nicht. In die Anwendungen (Layer 4 und höher) sieht er nicht.
Was in den Paketen transportiert wird ob Winblows, Apple, Linux und welche Dienste oder was auch immer ist ihm völlig egal !
Konzentrier dich also auf die Winblows User Berechtigungen...
Das ist auch ganz normal, denn in der obigen Konstallation ist es einzig und allein ein Rechte Problem unter Windows. (sofern du Firewall bzw. Firewall Profil bei Win7 sicher ausschliessen kannst. Bedenek das Win 7 auf dem VPN Adapter ein privates oder Arbeitsplatz FW Profil haben muss !) Die Zugriffsberechtigungen aufs Share sind falsch.
Mit dem Netzwerk an sich und dem VPN hat das rein gar nichts zu tun, denn das ist nur einzig für die Wegefindung (IP Adressierung) zuständig !
Ein Router, und dazu gehört auch der OpenVPN Router, kümmert sich lediglich um das Forwarding der IP Adressen...mehr nicht. In die Anwendungen (Layer 4 und höher) sieht er nicht.
Was in den Paketen transportiert wird ob Winblows, Apple, Linux und welche Dienste oder was auch immer ist ihm völlig egal !
Konzentrier dich also auf die Winblows User Berechtigungen...
Wäre ja toll wenn es nur die Rechte wären, aber ich glaube es halt nicht weil noch nicht mal nach Login Daten fragt.
Ist ja klar das hier ein anderer User berechtigt werden muss als in der Workgroup aber so weit kommt er nicht.
er sagt immer "Netzwerkpfad nicht gefunden " Fehler 53"
Ist ja klar das hier ein anderer User berechtigt werden muss als in der Workgroup aber so weit kommt er nicht.
er sagt immer "Netzwerkpfad nicht gefunden " Fehler 53"
Kannst du beidseitig die Teilnehmer anpingen oder mit Traceroute oder Pathping sehen ??
Bedenke die Firewall Profile bei Win 7. Ggf. erstmal zum testen die lokale FW deaktivieren um nicht in weitere Fallen zu tappen !!
Bedenke die Firewall Profile bei Win 7. Ggf. erstmal zum testen die lokale FW deaktivieren um nicht in weitere Fallen zu tappen !!
Also vom Client aus der Workgroup geht traceroute und pathping problemlos.
Aus der Domäne in die Workgroup geht das wiederum nicht .
Die Firewall habe ich zum fehlertesten natürlich komplett deaktiviert auf den Clients.
Aus der Domäne in die Workgroup geht das wiederum nicht .
Die Firewall habe ich zum fehlertesten natürlich komplett deaktiviert auf den Clients.
hy!
Danke erstmal, Ich werde mal die Routen versuchen, ich kann die Routen nur am Win7-Rechner setzen, am Client geht gar nix, weil der keine Konsole hat, sondern nur Einstellungen für IP, DNS u. Gateway.
Zur klarstellung: firewall ist nicht das problem, die hab ich überall auf durchgang geschaltet, werd ich aber nochmal checken, login ist auch nicht das problem, da es gar nicht soweit kommt - der client bekommt gleich gar keine Antwort vom Win7-Netzwerk. Ich will auf Shares am Win7-Host zugreifen, nicht auf Shares am Vpn-Server, daher dachte ich ist push-route nicht geeignet, da das für Roten am VPN-Server gilt, oder?
Danke erstmal, Ich werde mal die Routen versuchen, ich kann die Routen nur am Win7-Rechner setzen, am Client geht gar nix, weil der keine Konsole hat, sondern nur Einstellungen für IP, DNS u. Gateway.
Zur klarstellung: firewall ist nicht das problem, die hab ich überall auf durchgang geschaltet, werd ich aber nochmal checken, login ist auch nicht das problem, da es gar nicht soweit kommt - der client bekommt gleich gar keine Antwort vom Win7-Netzwerk. Ich will auf Shares am Win7-Host zugreifen, nicht auf Shares am Vpn-Server, daher dachte ich ist push-route nicht geeignet, da das für Roten am VPN-Server gilt, oder?
Das war auch so gemeint, wir meinten keine Shares am VPN Server (wenn es sowas geben sollte ...)
Irgendwie verstehe ich nicht mehr so wirklich was du machen willst glaube ich ...
Es geht doch um einen RoadWarrior oder nicht?
Das Push Route macht genau das selbe wie das route add, nur eben in der Config deines OpenVPN Clients und danach räumt er wieder auf, wenn Du die Verbindung beendest.
Irgendwie verstehe ich nicht mehr so wirklich was du machen willst glaube ich ...
Es geht doch um einen RoadWarrior oder nicht?
Das Push Route macht genau das selbe wie das route add, nur eben in der Config deines OpenVPN Clients und danach räumt er wieder auf, wenn Du die Verbindung beendest.
RoadWarrior stimmt im Prinzip, der Client soll über das Vpn ins Inet gehen aber auch die Shares am Vpn-Client sehen.
Hintergrund ist der: Ich hatte einen DD-WRT (wert54g) Router, der sich mit dem VPN-Server verband und alle Clients, die am Router hingen benutzten den Tunnel für die Internetanfragen, sahen sich aber auch gegenseitig (das sind dann die Shares die ich braucht). Der Router ist aber zu langsam (nur 1,5mbit über den Tunnel), also hab ich statt dem Router die Win7-Maschine genommen, die locker 15mbit bring. Der Client geht jetzt über win7-vpn ins inet, aber die Win7 Maschine blockt den Zugang auf ihre Shares.
Hintergrund ist der: Ich hatte einen DD-WRT (wert54g) Router, der sich mit dem VPN-Server verband und alle Clients, die am Router hingen benutzten den Tunnel für die Internetanfragen, sahen sich aber auch gegenseitig (das sind dann die Shares die ich braucht). Der Router ist aber zu langsam (nur 1,5mbit über den Tunnel), also hab ich statt dem Router die Win7-Maschine genommen, die locker 15mbit bring. Der Client geht jetzt über win7-vpn ins inet, aber die Win7 Maschine blockt den Zugang auf ihre Shares.
Eigentlich völliger Overkill für sowas einen PC zu nehmen. Eine alternative, kleine und preiswerte Router/Firewall die auch OpenVPN kann mit der Performance und einem Bruchteil des Preises wäre erheblich sinnvoller gewesen:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Aber nun gut...wenn du dir ein Verschleiss behaftetes Gerät was nicht Ausfall sicher ist und auch noch sehr viel Strom übers Jahr kostet dahinstellen willst ist das deine Entscheidung.
Achte aber auf folgendes: Wenn es aus der vor sich hinglühenden OpenVPN Kiste noch einen DSL Router im Netz gibt beachte das das VPN Netz immer von dem OpenVPN Rechner gehalten wird !
Der ist also der Router bzw. Gateway für das remote Netzwerk ! Wenn nun die anderen Clients im Netz aber den DSL Router als Gateway eingetragen haben muss auf diesem Router eine statische Route für die OpenVPN Netze auf die IP des OpenVPN Servers eingestellt sein !
Es sei denn du hast ein kaskadiertes Szenario wie hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das solltest du noch beachten.
Wie bereits gesagt: all das wäre völlig überflüssig wenn du die "richtige" Hardware statt einen kompletten PCs mit Win Lizenz verwendet hättest !!
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Aber nun gut...wenn du dir ein Verschleiss behaftetes Gerät was nicht Ausfall sicher ist und auch noch sehr viel Strom übers Jahr kostet dahinstellen willst ist das deine Entscheidung.
Achte aber auf folgendes: Wenn es aus der vor sich hinglühenden OpenVPN Kiste noch einen DSL Router im Netz gibt beachte das das VPN Netz immer von dem OpenVPN Rechner gehalten wird !
Der ist also der Router bzw. Gateway für das remote Netzwerk ! Wenn nun die anderen Clients im Netz aber den DSL Router als Gateway eingetragen haben muss auf diesem Router eine statische Route für die OpenVPN Netze auf die IP des OpenVPN Servers eingestellt sein !
Es sei denn du hast ein kaskadiertes Szenario wie hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Das solltest du noch beachten.
Wie bereits gesagt: all das wäre völlig überflüssig wenn du die "richtige" Hardware statt einen kompletten PCs mit Win Lizenz verwendet hättest !!
danke, nein kein overkill, der vpnserver ist meine arbeitsmaschine und läuft nur bei bedarf
also das problem ist definitv das ics, sobald ich am tap-device das ics abschalte, sieht der client die shares; zuvor nutzen alle routen nix.
ich vermute mal, dass ics allen trafic der bei nic1 ankommt an das tap device weiterleitet und nix in lokale netz, komisch.
ich vermute mal, dass ics allen trafic der bei nic1 ankommt an das tap device weiterleitet und nix in lokale netz, komisch.
