von Es gibt nichts schöneres als einen VPN-Tunnel einzurichten, bei dem man anscheinend die erste Person ist, die dabei Tools bzw. Router eines bestimmten Herstellers nutzen muss, zu deren Zusammenspiel man dann keinerlei Hilfestellung finden kann. Bevor ich den Support rufen musste kam ich nach einer Pause selber durch Zufall auf die Lösung. Damit andere Personen, die das Glück haben einen VPN-Tunnel mittels IPSec zwischen einer UTM von Securepoint sowie dem „bintec Secure IPSec Client“, von welchem ich bisher noch nie etwas gehört hatte, realisieren zu müssen, habe ich meine Erfahrung und Lösung im folgenden Artikel zusammengefasst.
Folgendes vorweg:
- die Nutzung von X-Auth war nicht zwingend vorgesehen und hatte bei meinen ersten Versuchen auch nicht funktioniert, weshalb ich diese nicht weiterverfolgt habe und das VPN schlussendlich ohne X-Auth nutzen werde
- die Anleitungen von Securepoint kann man nicht zu 100 % so befolgen, wie sie im Netz zur Verfügung stehen
- als Beispielnetzwerke habe ich im folgenden für das lokale Netzwerk hinter der UTM das Netz 192.168.2.0/24 gewählt und für die Adressen, aus denen für die VPN-Clients gewählt werden kann, das Netz 192.168.22.0/24
Grundkonfiguration auf der Securepoint UTM:
- unter den „Impliziten Regeln“ unter dem Punkt „IPSEC“ das IPSec-Protokoll aktivieren und NAT-T eingeschaltet lassen:
- ebenfalls die entsprechenden Protokolle unter „VPN“ aktivieren:
- eine Extra-Regel unter den Portfiltern wird für den Aufbau der VPN-Verbindung an sich nicht benötigt, lediglich für die Clients die sich über das VPN verbinden benötigt man Regeln – für diese erstellt man eines oder einzelne Netzwerkobjekte aus dem Client-IP-Bereich (192.168.22.0/24) und definiert wohin diese kommunizieren dürfen
Konfiguration des IPSec-VPNs
- eine Roadwarrior-Verbindung für ein Client-To-Site-VPN erstellen:
- die Konfiguration des Verbindungstyps und des PSKs vornehmen:
- das lokale, vom VPN aus zu erreichende, Netzwerk angeben bzw. alle anderen Netzwerke entfernen:
- beim Eingeben des Netzwerkes für die VPN-Clients kommt es dann zu einem Problem, wenn man versucht das Netzwerk einzugeben – man bekommt die Meldung „Dieser Wert ist ungültig“:
Um das Problem zu umgehen gibt man dann einfach eine einzelne IP-Adresse aus dem Bereich an, z. B. 192.168.22.10. Der entsprechende Punkt heißt auch „IP-Adresse(n)“ und nicht „Netzwerke freigeben“ wie im Dialog zuvor. Wirklich Sinn macht es meiner Meinung nach aber nicht, dass man an dieser Stelle kein Netzwerk angeben kann.
- im Nachgang kann man dann die einzelnen Phasen der angelegten VPN-Verbindung bearbeiten:
- hier muss man passende Parameter einstellen, dazu später mehr:
Um die Abweichung von den vorgegebenen Parametern der Phase 1 zu verhindern, sollte man den Modus „Strict“ einschalten.
- unter dem Punkt „Subnetze“ der Phase 2 kann man dann den im Vorfeld angegegeben Client nun auf ein gesamtes Netzwerk umkonfigurieren:
Die Wahl der richtigen Parameter:
Nicht alle Kombinationen an IKE- und IPSec-Parametern funktionieren zwischen diesen beiden Herstellern, auch wenn diese auf beiden Seiten konfigurierbar sind. Letztlich bin ich bei folgenden IKE- und IPSec-Richtlinien angekommen, die bei meinen Tests immer funktionierten:
- IKE-Policy: Pre-Shared-Key, AES 256 Bit, SHA2 512 Bit
- IPSec-Policy: ESP, AES 256 Bit, SHA2 256 Bit
Obwohl der Securepoint und der Bintec-Client beide auch für IPSec 512 Bit unterstützen, war mit diesem Parameter eifnach keine Verbindung herstellbar. Deshalb leider der Rückgriff auf „lediglich“ 256 Bit.
Als Diffie-Hellman-Groups habe ich für die Phase 1 die DH-Gruppe 14 (modp2048) sowie für die Phase 2 als PFS-Gruppe die DH-Gruppe 18 (modp8192) erfolgreich konfigurieren können. Hier habe ich mit mehreren Konstellationen herumprobiert und konnte soweit ich mich erinnern kann mit keiner Gruppe die auf beiden Seiten unterstützt wird Probleme feststellen.
- IKE: DH14 (modp2048)
- IPSec PFS-Group: DH18 (modp8192)
Ganz wichtig ist, dass die UTm von Securepoint keinen „Aggressive Mode“ zulässt, man muss also zwingend den „Main Mode“ im Client einstellen. Im Bintec-Client sieht die Konfiguration wie folgt aus:
Die IKE-Konfiguration:
Die IPSec-Konfiguration:
Die Netzwerkkonfiguration:
Bei der IP-Adresszuweisung gibt man eine IP aus dem im Securepoint definierten Adressbereich für die VPN-Clients (in diesem Fall aus dem Netz 192.168.22.0/24) an:
Unter Split Tunneling muss noch angegeben werden, welcher Traffic (in diesem Fall jeglicher Traffic in das Netz 192.168.2.0) durch das VPN geschleust werden muss:
Das Problem:
Nun kommen wir zu dem Hauptproblem, weshalb lange Zeit keine Verbindung zustande kam. Die lokale Identität auf Seiten des Bintec-Clients. Dort habe ich alles versucht: Die externe IP-Adresse des Securepoint, die 0.0.0.0, die aktuelle externe IP-Adresse des Routers hinter dem sich der Client befand etc.. Das meiste davon machte keinen wirklichen Sinn, aber da 0.0.0.0 nicht funktionierte, was beim Securepoint aber als Remote-Identity angegeben ist, verfiel ich in den Modus aus Verzweiflung einfach mal alles mögliche einzugeben. Die einfache Lösung des Problems: Das verdammte Feld muss einfach leer bleiben! Dementsprechend sieht es dann einfach so aus:
Leider gab es diesbezüglich weder eine brauchbare Fehlermeldung im Log des Securepoints, dort wurde der Tunnel einfach kommentarlos wieder abgebaut, noch im Log des Bintec-Clients. Dieser meldet meistens einfach einen Fehler bei der Internetverbindung oder fehlerhafte Logindaten… Sehr hilfreich.
Danach lief es stabil und im Log des Securepoints wird die Wiese grün 😀
Um im Log des Securepoint den Verbindungsaufbau nachvollziehen zu können, muss man im Live-Log nach „charon“ oder „ipsec“ filtern. Dann bekommt man bei einem erfolgreichen VPN-Aufbau eine Ansicht wie die folgende zu sehen:
