OpenVPN / Sophos SSL VPN Client: Windows Rechner als Softwarerouter verwenden

OpenVPN / Sophos SSL VPN Client: Windows Rechner als Softwarerouter verwenden

Achtung: Seit dem 23.1.2019 habe ich auch einen Artikel der erklärt, wie man einen Raspberry Pi verwenden kann. Diese Lösung wäre zu bevorzugen!

Dieser Tip funktioniert zwar grundsätzlich, ist aber weit entfernt davon als stabil zu gelten – womöglich kann er dazu dienen eine kurze Zeit als Notlösung zu fungieren.

Stellen Sie auf dem Rechner im BIOS/UEFI ein, das der Rechner immer an bleibt und nach einem Stromausfall wieder hochfährt.

Stellen Sie im Windows in den Energieoptionen ein, das der Rechner nicht ausschaltet (Festplatte und Monitor können jedoch ausgehen). Es muss niemand am Rechner angemeldet sein, nachdem alles eingerichtet wurde! Es reicht wenn er hochfährt.

Melden Sie sich an Windows mit Adminrechten an und geben Sie dem Rechner eine Feste IP, sowie alle benötigten weiteren Parameter wie DNS und Gateway.

Installieren Sie den aktuellsten Open VPN oder Sophos VPN Client und richten Sie die SSL Verbindung ein (am besten mit rechter Maustaste und „Als Administrator ausführen“) und testen Sie die Verbindung.

Sollte diese funktionieren, gehen Sie bitte in das Config Verzeichnis des VPN Clients (z.B. C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\config) und erstellen sie eine Datei mit dem Namen password.txt, tragen sie in der ersten Zeile den Benutzernamen und in der zweiten Zeile das Kennwort ein.

Öffnen Sie die entsprechende Config-Datei und tragen Sie nach auth-user-pass ein Leerzeichen und dann password.txt ein:

auth-user-pass password.txt

Prüfen Sie nun ob Sie die Verbindung ohne Zugangsdaten aufbauen können.

Klicken Sie nun auf Start und tippen Sie services.msc und machen ein Doppelklick auf OpenVPN Service und stellen Sie die Startart auf Automatisch.

Wenn Sie den Rechner neustarten und sich anmelden, sollten sie nach ein paar Sekunden Adressen aus dem entfernten VPN anpingen können (ohne das der VPN Client eine Verbindung anzeigt). Es sollte jedoch die Netzwerkschnittstelle des VPN Clients im Netzwerk- und Freigabecenter aktiv sein (kein rotes X).

Sollte nun soweit alles funktionieren, gehen Sie bitte mit der rechten Maustaste auf die Verbindung in die Eigenschaften auf dem Tab Freigabe (sollte der nicht vorhanden sein, deinstallieren Sie bitte den alten VPN Client und installieren eine aktuelle Version mit Adminrechten).

Windows wird nun eine Meldung ausgeben, das von der Netzwerkschnittstelle die IP Adresse verändert wird auf 192.168.137.1 – stellen Sie die Netzwerkeinstellungen wieder zurück auf die richtigen Werte. Nach ein paar Sekunden sollten wieder entferne Ressourcen anzupingen sein.

Damit nun die anderen Rechner auch das entsprechende Netz finden, müssen Sie eine Route erstellen auf das entfernte Netz, damit sie das nicht an jedem Rechner machen müssen, machen Sie das am besten auf den vorhandenen Router, der die Internetverbindung herstellt – z.B. bei einer Fritzbox unter Heimnetz > Netzwerk > Netzwerkeinstellungen > IPv4 Routen:

Bekannte Probleme:

Nach einem Neustart funktioniert die Verbindung zwar an dem Rechner wo das VPN Installiert ist, jedoch nicht mehr bei den anderen Geräten im Netzwerk:

Hier muss einmal wieder der Hacken bei „Internetverbindung freigeben“ bei der VPN Netzwerkschnittstelle entfernt werden – da dabei Windows auch die IP bei der LAN Verbindung zurücksetzt auf 192.168.137.1, muss hier wieder alles die zuvor konfigurierte Adresse zurückgesetzt werden. Nach ein paar Sekunden ist die Verbindung durch den VPN Dienst wieder neugestartet und sollte wieder funktionieren.

Alle Geräte im Netzwerk können auf das Remotenetzwerk zugreifen, jedoch das Remotenetzwerk nicht auf die lokalen Geräte:

Dies wird auch leider nicht funktionieren, da alle Geräte hinter der Adresse des einzelnen VPN Rechners per NAT (Network Adress Translation) versteckt sind und nicht erreichbar sind. Hier würde eine Lösung benötigt, die das gesamte Netz anbindet (z.B. ein Hardwarerouter auf Raspi-Basis). Evtl. kommt hierzu noch ein entsprechender Beitrag.


Exchange: TLS Testen

Ein Exchangeserver verwendet wenn möglich TLS (muss auf dem Sende- und Empfangsconnector eingerichtet sein).

Möchte man gerne die Verbindungen kontrollieren, dann kann man OpenSSL installieren und mit dem folgenden Befehl die Verbindung kontrollieren:

openssl s_client -connect remote.leibling.de:25 -starttls smtp

ESXI 6.5 (Free) mit öffentlichen Zertifikat ausstatten

Da der ESXI nun mit einem Webinterface ausgestattet ist, welches mittlerweile gut unter OSX funktioniert, möchte ich gerne komfortabler und sicherer auf das Webinterface zugreifen.

Dazu möchte ich gerne den Server mit einem gültigen öffentlichen 3 Jahres Zertifikat von Comodo ausstatten, welches ich auf meinem Exchange Server verwende. Dieses habe ich für ca. 15€ für insgesamt 3 Jahre über https://www.ssls.com bezogen.

Das ganze gestaltete sich jedoch schwieriger als ich dachte und ich war froh darüber, das ich Support vom VMWare-Forum bekommen hatte – hier besonderen Dank an ~thc, irix und mbreidenbach.

Vorbereitend benutzte ich einen Windowsrechner, wo ich OpenSSL 32 Bit installierte und mir dort einen Key und ein CSR erstellte, welches ich zertifizieren ließ und anschließend auf dem ESXI Host an die entsprechende Stelle brachte.

Dazu ging ich wie folgt auf dem Windowsrechner vor:

  • In das Verzeichnis C:\OpenSSL\bin wechseln
  • Die openssl.cfg weg sichern und den Inhalt ersetzen wie hier (Rot durch eigene Werte ersetzen):
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:esxi, IP:192.168.99.1, DNS:esxi.leibling.de

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Northrhine-Westfalia
localityName = Koeln
0.organizationName = Familie Leibling
organizationalUnitName = EDV
commonName = esxi.leibling.de
  • Den folgenden Befehl starten: openssl req -nodes -new -newkey rsa:4096 -sha512 -keyout rui.key -out rui.csr -config openssl.cfg
  • Die rui.key benötigen wir später, aus dem rui.csr erstellen wir beim Zertifizieren einen Zertifikatsantrag.
  • Wenig später sollte das fertige Zertifikat per Email zugesendet werden.
  • Die Zipdatei Entpacken wir und wechseln auf der Befehlszeile in das Verzeichnis und geben dort folgenden Befehl ein (alles in einer Zeile, sollte euer Browser hier mehrere Zeilen erstellen, bitte diese zusammenführen): cat esxi_domain_de.crt COMODORSADomainValidationSecureServerCA.crt
    COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > combined.crt
  • Bei mir war nun das Problem, das dieses Zertifikat im PKCS7-Format war und nicht wie benötigt im pem-Format (konnte man in der ersten Zeile erkennen wenn man die Datei in einem Texteditor öffnete) – die Lösung hier sollte sein, das man die combined.crt in das Verzeichnis C:\OpenSSL\bin kopiert und den folgenden Befehl eingibt – sollte die Datei schon im pem-Format gewesen sein, muss sie nur noch in rui.crt umbenannt werden. Der Befehl für die Konvertierung lautet: openssl pkcs7 -in combined.crt -print_certs -out rui.crt
  • Nun schalten Sie auf dem ESXI SSH ein und erstellen Sie in einem Datastore einen Ordner ZERTIFIKATE. Laden Sie nun die Datei rui.crt und rui.key in den Ordner.
  • Gehen Sie mit SSH auf den ESXI (z.B. unter Windows mit Putty oder unter OSX direkt im Terminal mit ssh ipadresse -lroot und verbinden sich zum ESXI.
  • Gehen Sie in das Verzeichnis /etc/vmware/ssl und benennen Sie die Datei rui.crt und key.key um (z.B. mv rui.crt rui.crt.save und mv rui.key rui.key.save).
  • Kopieren sie nun die neuen Dateien an den Ort (cp /vmfs/Volumes/datastorename/ZERTIFIKATE/rui.* ./ – beachten Sie bitte, das Linux Groß- und Kleinschreibung unterscheidet).
  • Starten Sie den Webdienst neu (/etc/init.d/rhttpproxy restart).

Achtung: Sollten Sie eine Fehlermeldung erhalten, welche anzeigt das die Seite nicht geöffnet werden kann – sollten Sie unbedingt wieder die neuen Dateien umbenennen in z.B. rui.crt.new bzw. rui.key.new und die gesicherten *.save Dateien wieder zurück nennen und starten Sie den Dienst neu.

Ich hatte dies im ersten Durchgang nicht so getan und musste dummerweise den gesamten ESXI auf Werkseinstellungen zurücksetzen – zwar bleiben die VM’s dabei erhalten, jedoch war einer der Datastore der unter ESXI 6.0 erstellt war nicht mehr im Zugriff (diesen konnte ich auch nicht mit der Webgui wieder bekannt machen, sondern musste auf den VMWare Client zurückgreifen) und alle andern Informationen wie Netze, Autostartkonfigurationen, Lizenzen usw. waren weg. Zusätzlich waren keine VMs mehr registriert.

Übrigen läßt sich mit einem iPad wunderbar die Webgui bedienen – inklusive der VMs 😉 :

Links: