Securepoint VPN Client setzt keine Route, wenn Windows Verzeichnis nicht = c:\\windows

Moderator: Securepoint

Gesperrt
SchlaWiener
Beiträge: 18
Registriert: Fr 28.09.2007, 14:16

Securepoint VPN Client setzt keine Route, wenn Windows Verzeichnis nicht = c:\\windows

Beitrag von SchlaWiener »

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.

Oliver Dehnbostel
Securepoint
Beiträge: 60
Registriert: So 25.07.2010, 00:25

Beitrag von Oliver Dehnbostel »

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.
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.
Mit freundlichen Grüßen,
Oliver Dehnbostel

SchlaWiener
Beiträge: 18
Registriert: Fr 28.09.2007, 14:16

Beitrag von SchlaWiener »

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.

Andreas
Securepoint
Beiträge: 124
Registriert: Di 18.03.2008, 15:56
Wohnort: Wrestedt
Kontaktdaten:

Beitrag von Andreas »

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
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)

Spencer
Beiträge: 25
Registriert: Do 22.10.2009, 15:25

Beitrag von Spencer »

Seit 10.6 hab ich das gleiche Problem. VPN-Tunnel wird aufgebaut, aber die Anfragen nicht an das remote Netzwerk gesendet. Werde das mit der geänderten Konfiguration auch gleich mal probieren.

Spencer
Beiträge: 25
Registriert: Do 22.10.2009, 15:25

Beitrag von Spencer »

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

Benutzeravatar
Erik
Securepoint
Beiträge: 1479
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

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.

Spencer
Beiträge: 25
Registriert: Do 22.10.2009, 15:25

Beitrag von Spencer »

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?

Spencer
Beiträge: 25
Registriert: Do 22.10.2009, 15:25

Beitrag von Spencer »

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?

Code: Alles auswählen

TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Hätte ich mal lieber nicht 10.6 installiert... :roll:

Spencer
Beiträge: 25
Registriert: Do 22.10.2009, 15:25

Beitrag von Spencer »

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?

Benutzeravatar
Erik
Securepoint
Beiträge: 1479
Registriert: Fr 07.11.2008, 11:50

Beitrag von Erik »

Spencer hat geschrieben: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Das ist komplett irrelevant, da es dort um... naja benutzerdefinierte Skripte geht, die vor/nach dem Verbindungsaufbau ausgeführt werden.
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.

Gesperrt