Guten Tag,
ich habe an einem Client mit Windows XP festgestellt, das zwar der Tunnel (SSL VPN) aufgebaut wird, aber kein Datenaustausch mit dem lokalen Netz möglich ist.
In dem Log steht z.B.
C:\\WINDOWS\\system32\\route.exe ADD 192.168.250.1 MASK 255.255.255.255 192.168.250.5
Das Problem ist an der Stelle, das der Client aufgrund einer drübergebügelten Installation das Verzeichnis C:\\windows garnicht hat, sondern nur C:\\Windows.0
Wenn man dann die Route händisch hinzufügt, klappt alles wie erwartet.
Das ist soweit kein Problem, es gibt ja die Scripte, die sich z.B. nach dem Verbinden ausführen lassen, wäre aber im Programmcode wahrscheinlich leicht zu beheben.
Securepoint VPN Client setzt keine Route, wenn Windows Verzeichnis nicht = c:\\windows
Moderator: Securepoint
-
- Beiträge: 18
- Registriert: Fr 28.09.2007, 14:16
-
- Securepoint
- Beiträge: 60
- Registriert: So 25.07.2010, 00:25
Hallo,
das geschilderte Problem liegt nicht an dem SpSSLVpn Client, sondern an der openvpn.exe. Diese sucht standardmäßig die route.exe im Verzeichnis: C:\\Windows\\system32.
Wenn das Verzeichnis anders heißt, kann man das der openvpn.exe durch einen Eintrag in der Konfiguration mitteilen.
Der Eintrag heißt: --win-sys
Dort kann als Parameter der Pfad gesetzt werden oder 'env', dann wird die Umgebungsvariable ausgelesen.
Oliver Dehnbostel
das geschilderte Problem liegt nicht an dem SpSSLVpn Client, sondern an der openvpn.exe. Diese sucht standardmäßig die route.exe im Verzeichnis: C:\\Windows\\system32.
Wenn das Verzeichnis anders heißt, kann man das der openvpn.exe durch einen Eintrag in der Konfiguration mitteilen.
Der Eintrag heißt: --win-sys
Dort kann als Parameter der Pfad gesetzt werden oder 'env', dann wird die Umgebungsvariable ausgelesen.
Mit freundlichen Grüßen,http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html hat geschrieben: --win-sys path|'env'
Set the Windows system directory pathname to use when looking for system executables such as route.exe and netsh.exe. By default, if this directive is not specified, the pathname will be set to "C:\\WINDOWS"
The special string 'env' indicates that the pathname should be read from the SystemRoot environmental variable.
Oliver Dehnbostel
-
- Beiträge: 18
- Registriert: Fr 28.09.2007, 14:16
Hey, vielen Dank für die Info.
Ich werd das mal ausprobieren.
Das sollte sich ja sogar per erweiterter Konfiguration -> Vorlagen direkt an die Clients verteilen lassen.
Allerdings sollte man durchaus überlegen
win-sys env mit in die Grundkonfiguration der Securepoint mit aufzunehmen.
Der VPNClientPortable ist ja dafür ausgelegt auf mehreren Rechnern zu laufen. Vom USB-Stick oder als Download.
Und da ist es nicht sehr geschickt, wenn der Endanwender, der sich ja nur wundert, warum er trotz aktiver VPN-Verbindung nicht ins Netz kommt, dann die Konfig anpassen muss.
Ich werd das mal ausprobieren.
Das sollte sich ja sogar per erweiterter Konfiguration -> Vorlagen direkt an die Clients verteilen lassen.
Allerdings sollte man durchaus überlegen
win-sys env mit in die Grundkonfiguration der Securepoint mit aufzunehmen.
Der VPNClientPortable ist ja dafür ausgelegt auf mehreren Rechnern zu laufen. Vom USB-Stick oder als Download.
Und da ist es nicht sehr geschickt, wenn der Endanwender, der sich ja nur wundert, warum er trotz aktiver VPN-Verbindung nicht ins Netz kommt, dann die Konfig anpassen muss.
Alternativ kann der Windows-Pfad auch in der clientseitigen Konfigurationsdatei (xxxx.ovpn) gesetzt werden, z.B.
win-sys d:\\\\windows
Wo, ist ziemlich egal :-)
Andreas
win-sys d:\\\\windows
Wo, ist ziemlich egal :-)
Andreas
Zuletzt geändert von Andreas am Do 03.11.2011, 17:13, insgesamt 1-mal geändert.
Such dir einen Beruf den du liebst und du musst nie wieder arbeiten! (chinesische Weisheit)
Also daran liegt es zumindest bei mir nicht. Was könnte sich den zu Version 10.6 geändert haben, dass ssl-vpn nicht mehr funktioniert? Problem: Der Client verbindet zwar zur Securepoint (zeigt verbunden /grün) aber findet nichts im Remotenetzwerk. Sieht fast so aus als wäre die Option "use gateway on remote network" gesetzt wäre (ist sie aber nicht!).
Bin gerade in der openVPN doku am suchen, falls Jemand eine Idee hat woran das liegen kann, her damit. Wie gesagt der Remote-Login mit Version 10.5 noch einwandfrei
Bin gerade in der openVPN doku am suchen, falls Jemand eine Idee hat woran das liegen kann, her damit. Wie gesagt der Remote-Login mit Version 10.5 noch einwandfrei
Steht beim Verbindungsaufbau was im Log von "comp-lzo is used inconsistently // present in remote-config"? Wenn ja: sowohl auf der Firewall als auch in der Client-Config "LZO-Compression" bzw "comp-lzo" deaktivieren
Zuletzt geändert von Erik am Fr 02.12.2011, 15:15, insgesamt 1-mal geändert.
Nein steht nicht drin und es sieht vom log her auch alles gut aus: keine Fehler, die Routen werden richtig gesetzt...
Habe jetzt das TUN Interface aus dem HTTP proxy rausgenommen (war es vorher nicht), aber auch ohne Erfolg.
Dann nochmal die Aktualisierung angeklickt und die Firewall neu gestartet (neustart hatte ich gestern mindestens 5 mal gemacht) - siehe da die Netzlaufwerke werden wieder angezeigt!
Dachte eigentlich der exclude im Hide-Nat sollte den proxy umgehen, aber wohl nicht mehr mit Version 10.6 oder lag es doch an einem nicht ganz sauberen Update?
Habe jetzt das TUN Interface aus dem HTTP proxy rausgenommen (war es vorher nicht), aber auch ohne Erfolg.
Dann nochmal die Aktualisierung angeklickt und die Firewall neu gestartet (neustart hatte ich gestern mindestens 5 mal gemacht) - siehe da die Netzlaufwerke werden wieder angezeigt!
Dachte eigentlich der exclude im Hide-Nat sollte den proxy umgehen, aber wohl nicht mehr mit Version 10.6 oder lag es doch an einem nicht ganz sauberen Update?
Jetzt geht es wieder nicht.
Komisch das. Wie gesagt war comp-lzo bereits auf "no" im config file
Da steht auch nix von comp-lzo im log.
ROUTE default_gateway=192.168.x.y ist der Router des entfernten Netzwerks, sollte da nicht die Securepoint TUN-IP drin stehen?
Hätte ich mal lieber nicht 10.6 installiert... :roll:
Komisch das. Wie gesagt war comp-lzo bereits auf "no" im config file
Da steht auch nix von comp-lzo im log.
ROUTE default_gateway=192.168.x.y ist der Router des entfernten Netzwerks, sollte da nicht die Securepoint TUN-IP drin stehen?
Code: Alles auswählen
TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Also irgendwie will das mit OVPN nicht mehr, es werden keine Anfragen durch den Tunnel gesendet, alles geht an den lokalen Gateway und nicht an die Securepoint (aus client Sicht). Was mir im log noch aufgefallen ist:
OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
kann es daran liegen?
OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
kann es daran liegen?
Das ist komplett irrelevant, da es dort um... naja benutzerdefinierte Skripte geht, die vor/nach dem Verbindungsaufbau ausgeführt werden.Spencer hat geschrieben: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Dass die Route "plötzlich" von ihrem Client verschwindet, hängt vermutlich nicht mit der 10.6 zusammen. Ich tippe eher darauf, dass da alle Routen neu geschrieben werden (WLAN+DHCP oder sowas) und damit natürlich auch das entfernte Netz wieder über das Default-GW geroutet wird.