In den ersten Teilen dieser Beitragsserie ging es zunächst um pfSense als OpenVPN-Client für den vServer mit der öffentlichen IPv4-Adresse, der den OpenVPN-Server stellt. Nun folgt die Variante mit einer Securepoint UTM als OpenVPN-Client.
Zur Info: OpenVPN wird bei Securepoint SSL-VPN genannt.
Im Laufe der Jahre hat sich schon die eine oder andere Erfahrung mit der Kombi aus pfSense und Securepoint UTM in Sachen OpenVPN ergeben, diese + die zuletzt genannten Beiträge fließen nun in die nachfolgenden Zeilen ein. Neu hinzugekommen, da es während der Entwurfsphase dieses Beitrags erstmal nicht klappte, ist der Erfahrungswert aus dem Beitrag
Securepoint UTM: Site-to-Site (SSL-VPN) mit Debian als Server/Gegenstelle
denn es hat sich zunächst als schwierig erwiesen die bereits bekannten Konfigurationen anzupassen. Letztlich wurde ermittelt, was die UTM auf der OpenVPN-Site-to-Site-Server-Seite erwartet und entsprechend adaptiert.
Die Grundeinrichtung des vServer, in diesem Beispiel bei KAMP, des OpenVPN-Daemons unter Debian 10 Buster und weiteres kann im ersten Beitrag nachgelesen werden. Das Erstellen der PKI, CA und der Server-/Client-Zertifikate kann dem letzten Beitrag entnommen werden. Der TLS-Key wird nicht benötigt, da dieser seitens der Securepoint UTM nicht unterstützt wird.
OpenVPN-Server konfigurieren
Im Gegensatz zu den vorigen Beiträgen folgt nun eine vollständige Konfigurationsdatei, also keine Änderungen gegenüber der Beispielkonfiguration!
/etc/openvpn/server.conf:
dev tun mode server tls-server proto udp tun-mtu 1500 ca ca.crt cert OpenVPN-Server.crt key OpenVPN-Server.key server 10.8.0.0 255.255.255.0 topology subnet port 1195 dh dh2048.pem keepalive 10 120 cipher AES-256-CBC comp-noadapt persist-key persist-tun status /var/log/openvpn/openvpn-status.log log /var/log/openvpn/openvpn.log verb 3 explicit-exit-notify 1 auth SHA256 route 192.168.1.0 255.255.255.0 client-config-dir /etc/openvpn/csc/server
/etc/openvpn/csc/server/OpenVPN-Client:
iroute 192.168.1.0 255.255.255.0 ifconfig-push 10.8.0.2 255.255.255.0
Anschließend einmal den Daemon durchstarten:
systemctl restart openvpn@server
Die Securepoint UTM als Site-to-Site-Client auf Basis von OpenVPN-/SSL-VPN-Client konfigurieren
Bevor man den eigentlichen OpenVPN-Site-to-Site-Client auf der Securepoint UTM einrichten kann, ist es notwendig das CA-Zertifikat (ohne privaten Schlüssel) und das Client-Zertifikat (mit privatem Schlüssel) die man auf dem vServer erzeugt hat zu importieren.
Basieriend auf der vServer-PKI muss eine neue Text-Datei, z.B. mit Notepad, erstellt werden und aus den Dateien “OpenVPN-Client.crt” und “OpenVPN-Client.key” der Inhalt zusammenkopiert werden. Aus der erstgenannten Datei reicht der Teil ab “—–BEGIN CERTIFICATE—–“.
Zertifikate importieren
- Auf “Authentifizierung – Zertifikate” klicken.
- Auf der Registerkarte “CA” auf “CA importieren” klicken.
- Die CA-Zertifikatsdatei, z.B. “ca.crt”, auswählen und hochladen.
- Zur Registerkarte “Zertifikate” wechseln und “Zertifikat importieren” anklicken.
- Die zuvor erstellte Datei, die das Client-Zertifikat samt privatem Schlüssel enthält, auswählen und hochladen.
SSL-VPN konfigurieren
- Auf “VPN – SSL-VPN” klicken.
- Auf “+ SSL-VPN Verbindung hinzufügen” klicken.
- “SITE-TO-SITE CLIENT” auswählen.
- Bei “Schritt 3” einen Namen eintragen und das zuvor importierte OpenVPN-Client-Zertifikat auswählen.
- Bei “Schritt 5 (Gegenstelle)” die IPv4-Adresse (ggf. mit Port) des vServers eintragen.
- Anschließend die Einstellungen bearbeiten und folgendes ändern:
Cipher für Datenverbindung: AES-256-CBC
Hash für Datenverbindung: SHA256 - Auf “Neustarten” klicken.
Die Verbindung sollte nahezu sofort aufgebaut werden. Sobald die Netzwerkobjekte angelegt und die Portfilter-Regeln konfiguriert ist sollte alles klappen.
Persönliche Bemerkung
Die Securepoint UTM hat mir persönlich für dieses Vorhaben die Sache vergleichsweise schwer gemacht eine funktionierende Kombi zu ermitteln, was nun nicht bedeutet, das Securepoint Schuld wäre oder schlecht ist!
Das lag zum einen daran, das die bisher bekannten Konfigurationen nicht funktioniert hatten, man via root und ssh die unter der Haube befindliche OpenVPN-Konfiguration erst ermitteln und schlussendlich noch eigene Fehler ausräumen musste.
Hinzu kommt das in der Verwaltungsoberfläche in manchen Feldern schlicht von “Default” die Rede ist, ohne das man genau weiß, was damit nun gemeint ist bzw. sich dahinter verbirgt. Beispiele dafür wären “Cipher für Datenverbindung” und “Hash für Datenverbindung”. Wobei sich das Default vmtl. auf die Vorgabe von OpenVPN bezieht.
Im Wiki wird beispielsweise unter
SSL-VPN Site-to-Site – Verschlüsselung
angegeben das AES128-CBC (Cipher) und SHA256 (Auth) als Standard verwendet werden, das scheint allerdings nicht unbedingt zu stimmen. Beim Test-Aufbau mit einer frisch installierten aktuellen UTM funktionierte auch nach wie vor BF-CBC und SHA1, was beides mittlerweile als schwach und damit als unsicher gilt. Woher nun diese Differenz stammt wurde nicht abschließend geklärt. Wer sicher sein möchte, stellt per Hand aktuelle als sicher geltende Werte ein.
Auch wenn es erstmal ärgerlich war, das es nicht funktionierte und viel Kopfzerbrechen bereitet hat, so ist letztlich alles gut geworden. Ein paar Verbesserungen und etwas Kosmetik sowie Praxiserfahrung steht noch an, also wird vermutlich das eine oder andere Update folgen.
Update 02.07.2020
Wie angekündigt ein wenig Kosmetik bzw. eine Verbesserung:
Debian, OpenVPN und nftables: Regeln nach Verbindungsaufbau neu laden
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Schreibe einen Kommentar