Bereits vor einigen Monaten habe ich einen Artikel über Probleme mit dem Securepoint VPN Client unter Windows 10 geschrieben. Das dortige Problem bzgl. des fehlerhaften Eintrags des TAP-Adapters ließ sich durch eine Anpassung in der Registry lösen. Dieses mal hingegen lässt sich das Problem nicht wirklich in den Griff bekommen. Vielleicht liegt es dieses mal auch daran, dass das Zielbetriebssystem eine „Windows 10 Home“-Version ist.
Sceurepoint-Client setzt die Route falsch
Unter einem „Windows 10 Pro“ hatte ich auch schon Probleme mit der Route, die in gefühlt einem von zehn Starts des Clients nicht richtig gesetzt wird. Dadurch geht dann natürlich trotz korrekt aufgebautem VPN kein Traffic ins gewünschte Netz durch.
Ich vermute, das zumindest unter der „Home“-Version, ein merkwürdiges Problem mit dem TAP-Treiber des Securepoint-Clients bestehen muss, wodurch die Route einfach nicht korrekt gesetzt werden kann. Eventuell ist dieser Adapter für das Betriebssystem einfach nicht vernünftig ansteuerbar. Allerdings hatte die Verbindung ein paar Mal geklappt. Nach ein paar Mal neu starten des Computers wollte das ganze dann einfach gar nicht mehr funktionieren. Zumindest taucht dieses Problem auf, wenn man die VPN-Verbindung trennt und dann wieder aufbaut.
Manuelles Ändern der Routen funktioniert nicht
Unter einem „Windows 10 Pro“ hatte das manuelle Setzen bzw. Ändern der Routen bisher zwar mal funktioniert. Unter der „Home“-Version funktioniert das aber einfach nicht. Es wird immer der falsche Adapter mit der lokalen IP-Adresse des Lan-Adapters als Schnittstelle verwendet:
Der Versuch mit folgendem Befehl die Route in das entfernte Netz (192.168.0.0) über das VPN-Gateway (192.168.10.1) zwingend über Schnittstelle 3 (TAP-Windows-Adapter) festzulegen, geht immer daneben bzw. wird gar nicht ausgeführt:
1 |
route add 192.168.0.0 mask 255.255.255.0 192.168.10.1 metric 1 if 3 |
Durch den Zusatz „if (Interface)“ müsste bei der Schnittstelle die vom VPN-Gateway zugewiesene bzw. in der Config-Datei hinterlegte VPN-Adresse des Clients als Schnittstelle auftauchen, in diesem Beispiel z. B. 192.168.10.20.
Auch der Versuch eine statische Route zu verwenden, die dauerhaft Gültigkeit hätte, funktionierte einfach nicht. Einmal wurde diese per „route print“ angezeigt. Danach ließ sie sich nicht mal mehr als Eintrag blicken, wenn man diese über folgenden Befehl angelegt hat:
1 |
route -p add 192.168.0.0 mask 255.255.255.0 192.168.10.1 metric 1 if 3 |
Lösung
Ob das möglich ist weiß ich nicht, aber ich vermute man könnte es eventuell mit einem alternativen TAP-Adapter hinbekommen, den man selbständig konfiguriert. Hiermit habe ich mich aber nicht weiter beschäftigt, sondern sofort nach einem Alternativ-Programm gesucht.
Als fehlerfrei arbeitende Alternative habe ich den OpenVPN-Client von OpenVPN selber installiert. Dieser funktioniert ohne ein Problem sofort mit einer stabilen Verbindung. Sofern man allerdings verschiedene VPN-Profile verwalten muss, kann man den OpenVPN-Client nicht so sehr gebrauchen. Außer man möchte ständig die Config-Dateien überschreiben. Da in meinem Fall nur ein einziges Profil benötigt wurde, habe ich nach unzähligen Fehlversuchen den Securepoint-Client für Windows 10 nun aufgegeben. Das Problem lässt sich meiner Meinung nach nicht lösen.
Moin !
Ich habe gestern genau dieses Verhalten an meinem W10pro Rechner erlebt – mit dem SP Portable Client. Auf
meinem Notebook hingegen funktioniert es ohne Probleme. Auch W10 Pro mit ESET Internet Security.
Weder ESET noch Windows-Protokolle geben Hinweise auf das Problem
Mit dem OpenVPN-Client geht es ab und zu auch nur nach deaktivieren und aktivieren des Adapters
Gruss
Hallo Rybak,
das ist ärgerlich. Ich habe leider keinen Securepoint-Router mehr vorliegen und nutze derzeit auch kein OpenVPN. Eventuell hat sich da Windows-seitig wieder etwas geändert.
Viele Grüße
Tobias