IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi

aqui
Goto Top
article-picture


back-to-topEinleitung


Das folgende Tutorial erhebt keinen Anspruch auf Vollständigkeit und ist ein einfaches Framework das die Funktion eines IPsec IKEv2 VPN Servers im groben Rahmen aufzeigt. Es beschränkt sich bewusst auf IPsec IKEv2 Clients, weil diese in allen Betriebssystemen und Endgeräten immer onboard integriert sind.
Vorteil ist, daß damit KEINE Installation und Anpassung zusätzlicher VPN Client Software auf den Endgeräten erforderlich ist, wie dies z.B. bei Wireguard oder OpenVPN der Fall ist.
Es ist daher sehr eng mit dem hiesigen pfSense / OPNsense Firewall VPN Tutorial verzahnt. Auch hier bedient der charon Daemon IPsec Verbindungen der onboard VPN Clients. Jeder unixoide Unterbau nutzt für IPsec basierte VPNs in der Regel die StrongSwan Architektur mit dem charon IPsec Daemon.
strongswanvpn
Der Einsatz der IKEv2 onboard VPN Clients bei Windows und Apple erfordert immer auch ein Server Zertifikat. IKEv2 VPN Clients prüfen auf diese Weise das ihnen kein Fake VPN Server untergejubelt wird. So wird auch das Thema PKI hier etwas gestreift.
Das Tutorial will und kann aber kein Grundlagentutorial sein, welches erklärt was eine PKI ist und auch das IPsec Protokoll vollumfänglich erklärt. Das würde den Rahmen eines einfachen Praxistutorials sprengen.
Die Verwendung eines kleinen Raspberry Pi's als VPN Server ist hier nur beispielhaft zu sehen. Natürlich funktioniert das Setup auch auf "großer" Hardware, vServern usw. mit anderen Distributionen und natürlich auch unter der populären, freien OpenWRT Router Firmware. Ungenutzt, in der Bastelschublade schlummernden RasPi's, kann man ggf. so wieder neues Leben einhauchen...
Ein klein wenig Linux KnowHow um sich auf dem CLI zu bewegen und etwas Grundwissen zum Thema Netzwerk und PKI sollte bei Nachahmern vorhanden sein.
Ein Raspberry Pi mit installierter OS-Lite Version und SSH Zugang (z.B. PuTTY) ist der Ausgangspunkt.
(Das Tutorial nutzt zum Teil freie DNS Hostnamen mit nip.io Adressen, die auch private RFC 1918 IPs im Heimnetz auflösen. Diese können natürlich ggf. mit eigenen Hostnamen ersetzt werden wenn ein eigener, lokaler DNS Server im Einsatz ist.)
Los gehts...!


back-to-topVPN Server Konfiguration


swanctl unter StrongSwan ist ein neues, portables Command Line Utility um den IKE Daemon charon über ein vici Interface zu konfigurieren und auch zu monitoren. Es ist seit StrongSwan 5.2.0. enthalten und wird langfristig die alte Starter Syntax über die ipsec.conf Datei ersetzen. Ein guter Grund diese aktuelle Konfig Syntax zu nutzen.
Damit Linux respektive der Raspberry Pi generell IPsec fähig wird, müssen als Allererstes die folgenden Pakete über die APT Paketverwaltung installiert werden. Dazu sind root Rechte (sudo su) erforderlich:
apt install strongswan strongswan-pki charon-systemd libcharon-extra-plugins
Zusätzlich muss auf dem Server das Routing (IPv4 Forwarding) aktiviert werden. Dies geschieht indem man die Datei /etc/sysctl.conf editiert und dort
das Kommentarzeichen "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und die Datei sichert. Danach rebootet man den RasPi.
Ist das erledigt, geht es mit der Zertifikats Erstellung bzw. Import der Zertifikate und der eigentlichen StrongSwan Konfiguration weiter.

back-to-topCA und Server Zertifikat mit StrongSwan PKI erstellen


Wie oben schon erwähnt prüfen die onboard VPN Clients ein Server Zertifikat ihres Ziels. Es ist daher eine kleine PKI erforderlich. Der Einsatz der onboard Clients schafft somit eine zusätzliche VPN Sicherheit.
Sofern nicht schon vorhanden, muss eine Zertifizierungstelle (CA) und ein Serverzertifikat für den VPN Server erstellt werden. Quasi die "Meldebehörde" und einen Server "Ausweis" mit Stempel.
Die "Behörde" macht man den Endgeräten mit dem Import der CA in die Endgeräte (Stammzertifizierungsstellen) bekannt. So kann das Endgerät den "Ausweis" des Servers überprüfen ob er gültig ist und ihm niemand einen fremden Server untergeschoben hat.
Besteht eine CA, weil man z.B. auf einem Windows Server seine Nutzer mit Zertifikaten ausstattet, erstellt man über diese einfach ein zusätzliches Server Zertifikat. Wer keine "Behörde" (CA) hat, muß erst eine einrichten um Ausweise ausstellen zu können.
CA einrichten:
Letzteres, also die Datei raspica-cert.pem, ist die "Behörde" die über den Zertifikats Import in die Endgeräte importiert wird. Details dazu für Windows und Apple erklärt wieder das hiesige pfSense / OPNsense Firewall VPN Tutorial.
Server Zertifikat erstellen:
(Tip: Es macht Sinn die o.a. Kommandos mit einem Texteditor zu bearbeiten und sie ggf. auf eigene Belange anzupassen (z.B. Dateinamen, Gültigkeitszeiträume usw.) und dann per Cut and Paste auszuführen.)

back-to-topBestehende CA nutzen


Wer eine bestehende CA hat z.B. auf einem Windows Server, pfSense oder OPNsense kann diese CA nutzen und erstellt mit ihr lediglich ein weiteres Server Zertifikat für den VPN Server.
Exemplarisch zeigen die folgenden Screenshots dies am Beispiel im Cert. Manager (Zertifikats Manager) Menü der pfSense Firewall:
CA Zertifikat und Key exportieren: (Menü "CA")

ca-export
Server Zertifikat und Key exportieren: (Menü "Certificates")
Nach Erstellung des Server Zertifikats exportiert man dieses (Mouseover "Sonnensymbol") und den dazugehörigen Key (Mouseover "Schlüsselsymbol")

srvzert_neu.
Das RasPi Server Zertifikat kann man dann wieder von der Firewall löschen sofern man Zertifikat und Key z.B. auf einem USB Stick exportiert und gesichert hat.
Diese Zertifikate und Keys sind dann in den RasPi VPN Server zu importieren indem man sie einfach per USB Stick oder SCP (z.B. WinSCP) in die folgenden VPN Server Verzeichnisse kopiert:
  • Alle Key Dateien in: /etc/swanctl/private
  • CA Zertifikat in: /etc/swanctl/x509ca
  • Server Zertifikat in: /etc/swanctl/x509
Erstellt man die Zertifikate und Keys lokal mit der o.a. Strongswan PKI, kann man an den obigen Kommandos diese Zielverzeichnisse auch entsprechend erkennen.
Natürlich kann man diese Zertifikate und Keys auch mit OpenSSL oder dem Klassiker XCA oder anderen Tools seiner Wahl erstellen.
In die Endgeräte muss vor dem ersten Verbindungsaufbau nur das CA Zertifikat importiert werden.

back-to-topStrongSwan Konfiguration


Die eigentliche StrongSwan Konfiguration liegt im Verzeichnis /etc/swanctl/conf.d und wird dort in einer Konfig Datei mit der Endung .conf abgelegt. Z.B. vpn-server.conf.
Das erledigt man mit einem einfachen Texteditor wie z.B. nano. Mit nano /etc/swanctl/conf.d/vpn-server.conf fügt man die u.a. Konfig per Cut and Paste ein und sichert mit <ctrl o> und <ctrl x> .
Die Beispiel Konfig nutzt einige IP Adress Einstellungen die man ggf. mit dem Editor an die eigenen Belange anpassen muss:
  • PSKs durch Sinnvolle ersetzen !
  • Internes VPN Client Netzwerk: 172.25.25.0 /24
  • Lokale IP Adresse eth0 Interface: 10.99.1.135 (DNS Beispiel: 0a630187.nip.io)
  • DNS Server IPs die automatisch an die Clients übergeben werden bei Einwahl: 172.16.7.254 und 10.99.1.254
  • 2 VPN User mit der User/Passwd Kombination user/test123 und user2/user2
  • Usernamen/Passwörter dürfen nicht doppelt genutzt werden. (Mehrfacheinwahl mit gleichen Zugangsdaten, Parameter unique = replace). Kann man aber erlauben wenn man diesen Parameter einfach weglässt.
Sind die o.a. StrongSwan Konfiguration und Zertifikate in die entsprechenden Verzeichnisse kopiert führt man ein
swanctl -q
aus um diese Einstellungen in den Daemon zu laden. (Mit einem Reboot passiert das immer automatisch !). Der Daemon quittiert dies entsprechend mit
Ggf. Troubleshooten kann man die Einwahl der VPN Clients indem man das Log live mit swanctl -T betrachtet. (Stop mit <ctrl c>)
Bei jeder Änderung in der Konfiguration muss auch immer ein swanctl -q gemacht werden um die Änderungen zu aktivieren !
Damit ist der VPN Server dann einsatzklar und weiter geht es mit den VPN Clients...


back-to-topKonfiguration der Windows und Apple VPN Clients


In der Regel sind bei Windows, Apple und allen Smartphones immer zwei onboard VPN Clients vorhanden. (Linux hat mit StrongSwan immer einen Universalclient an Bord).
Ein Client für das L2TP Protokoll und einer für native IPsec im Tunnel Mode mit IKEv2. Um Letzteren geht es in diesem Tutorial.
Es ist unverständlich warum Microsoft im VPN Client als Default unsichere Verfahren nutzt. Vermutlich um weiter kompatibel zu veralteten Schlüssel Algorithmen zu sein ?!
Will man mehr Sicherheit muss entweder ein Eingriff in die Registry her oder Windows muss mit zusätzlichen Powershell Kommandos zu sichereren Verfahren "überredet" werden, die Apple schon seit langem im Default vorgibt. (z.B. AES256,SHA256,DH14). Wie man das anpassen kann wird weiter unten erklärt.
Wer unter Windows mit den Default Settings arbeitet, ohne Anpassung, muss daher immer sicherstellen das auch SHA1 Hashing und DH Group 2 supportet sind.
Betrachtet man die o.a. StrongSwan Konfiguration (proposals = ...) erkennt man diese Defaults. Ebenso in den pfSense / OPNsense Settings beschreibt das hiesige Tutorial (siehe unten) diese 2 Settings um die out of the Box Defaults des Windows VPN Clients abzudecken.

Wichtig bei ALLEN Clients ist, daß man immer vorher das erstellte CA Root Zertifikat (Stammzertifikat) in die entsprechenden Endgeräte importiert. Wie oben bereits erwähnt prüfen die IKEv2 onboard Clients das Server Zertifikat um sicherzustellen, daß niemand ihnen einen Fake VPN Server unterjubelt.
Der Zertifikats Import ist oben und im pfSense/OPNsense Tutorial umfassend erklärt für Windows und auch für Apple.

back-to-topWindows VPN Client

Achtung !: Unbedingt Patch KB5010793 einspielen ! Siehe dazu auch HIER !

Das Setup des Windows Clients ist über das GUI "Erstellen eines neuen VPN" einfach zu bewerkstelligen:
raspi-w10-vpn
Typ IKEv2, Benutzername/Kennwort. Die Eingabe des Nutzernamen und Kennworts. Wer die Angabe des Usernamen/Password automatisieren möchte kann dies entsprechend in den Eigenschaften des Clients mit einem Haken aktivieren.
wineigenst
Dort stellt man auch ein ob man bei aktivem VPN Client alles in den Tunnel routet (Gateway Redirect) oder nur das was ins remote Netzwerk soll (Split Tunneling).
wingateway
Der Haken Standardgateway bedeutet ein sog. "Gateway Redirect" wobei dann der gesamte Client Traffic durch die VPN Verbindung läuft.
Ohne den Haken geht nur für das remote Netz relevanter Traffic durch die VPN Verbindung (sog. "Split Tunneling") alles andere bleibt lokal.

back-to-topWindows Client: VPN Security erhöhen

Die folgenden Einstellungen sind nur erforderlich für Anwender, die eine höhere VPN Sicherheit im Windows Client statt der Default Einstellungen wünschen. Wer mit den etwas schwächeren Windows Default Einstellungen leben, kann überspringt diesen Punkt !

Eine einfache Option ist den bestehenden VPN Client per Powershell anzupassen:
Wichtig ist hier der Parameter -ConnectionName "RasPi" der genau mit dem Verbindungsnamen (Schreibweise) des bestehenden VPN Eintrages übereinstimmen muss ! (Das u.a. pfSense/OPNsense VPN Tutorial hat alle Details zum Customizen per Powershell).

Eine weitere Alternative eine höhere VPN Sicherheit zu erzwingen führt über die Anpassung der Windows Registry:
  • 1.) Registry editieren (regedit) oder GPO erstellen: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
  • 2.) Neuen DWORD Wert anlegen: NegotiateDH2048_AES256
  • 3.) DWORD Wert setzen auf 1 oder 2
win10reg
Tabelle der DWORD Variablen Werte:
regvals
ACHTUNG:
Wer die Windows Registry so anpasst, veranlasst Windows immer diese starken IKE Algorithmen zu nutzen ! Davon werden also auch ggf. bestehende VPN Verbindungen beeinflusst, die ggf. die zuvor schwächeren Default Einstellung nutzen.
Die o.a. Powershell Anpassung macht dieses aufgrund der Bindung an den VPN Verbindungsnamen immer individuell für die jeweilige VPN Verbindung. Sie ist also flexibler in der Anpassung unterschiedlicher VPN Verbindungen auf andere VPN Zielhardware.
Das sollte man also immer auf dem Radar haben wenn man diese Anpassung der Registry oder per GPOs vornimmt !

back-to-topApple VPN Client

Der Apple Client arbeitet generell mit hoher Sicherheit im Default so das dort lediglich nur die Zugangsdaten im Setup einzugeben sind. Es muss nichts weiteres eingestellt werden.
raspi-mac-vpn

back-to-topAndroid VPN Client

Für mobile Endgeräte mit Android Betriebssystem gilt was schon im o.a. VPN Tutorial zur Android VPN Client Einrichtung gesagt wurde und kann so übernommen werden.

back-to-topMobile Endgeräte allgemein

Für alle mobilen iOS Endgeräte von Apple sendet man sich einfach die CA Datei per Email Attachment oder SMS, importiert sie mit einem Doppelklick.
Das gleiche gilt für alle Androiden. Auch hier gibt das hiesige pfSense / OPNsense Firewall VPN Tutorial wieder entspr. Hilfestellung.
Richtet man eine größere Anzahl Apple Mobilgeräte ein, hilft der Apple Configurator 2 mit einem leichten Setup über ein Template.


back-to-topJumphost VPN Setup mit vServer


Ein interessantes Anwendungsdesign aus der Praxis ist die Realisierung eines sog. "Jumphosts" für DS-Lite Internet Anschlüsse. DS Lite Anschlüsse können, technisch bedingt durch CGNAT beim Provider, keinen VPN Zugang mit IPv4 realisieren können. (Mit IPv6 geht es natürlich !)
Ob man einen DS-Lite Anschluss hat erkennt man im Router Dashboard/Übersicht anhand seiner WAN/Internet IP Adresse. Ist diese eine RFC 1918 oder eine RFC 6598 IP Adresse besitzt man einen DS-Lite Anschluss. (Siehe u.a. auch hier.

Als möglichen Workaround mietet man Z.B. einen preiswerten vServer bei einem Hoster und lässt die heimische FritzBox von der einen Seite ein VPN aufbauen um das lokale IPv4 LAN an den VPN vServer zu koppeln und nutzt von der anderen Seite die Standard onboard VPN Clients für den remoten Zugang. Der Server arbeitet quasi als VPN Relais Station.
jump_neu.
Auf diese Weise umgeht man die IPv4 Einschränkungen durch CGN Anschlüsse und kann trotzdem mit mobilen IPv4 VPN Clients sein heimisches LAN erreichen.
Das Forum beschreibt so ein Jumphost Design in alternativen Tutorials auch mit anderen VPN Protokollen.

back-to-topStrongSwan Jumphost Konfiguration

Dazu ist die o.a. StrongSwan Konfiguration auf so ein Design entsprechend anzupassen. (Für die FritzBox Konfiguration besonderer Dank an @colinardo !)
  • PSKs durch sinnvolle ersetzen !
  • vServer IP <server_hoster_ip> und FQDN <server_FQDN> durch entsprechend eigene IP und FQDN ersetzen
  • Wenn die eigene FritzBox ein anderes lokales IP Netz als 192.168.178.0/24 (Standard Setup FritzBox) verwendet, dies unter "remote_ts = x.y.z.h" anpassen

back-to-topFritzBox VPN Konfigurations Datei

Eine dazu passende FritzBox VPN Konfigurations Datei die man über das FritzBox GUI einspielt sieht z.B. so aus:
  • <server_hoster_ip> durch die vServer IP oder FQDN ersetzen.


back-to-topWeiterführende Links


Tutorial in 🇺🇸🇬🇧:
https://administrator.pro/contentid/2145635754

Grundlagen Raspberry Pi Setup:
https://administrator.de/contentid/191718

pfSense/OPNsense Zertifikats gesichertes IKEv2 VPN für mobile Benutzer mit bordeigener VPN Software:
https://administrator.de/contentid/337198

StrongSwan Kommando Doku:
https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf

Windows 10: Schneller VPN Aufbau mit einem Mausklick:
https://www.heise.de/ct/ausgabe/2017-19-VPN-und-Remote-Desktop-Verbindun ...

Microsoft Power Shell VPN Command Syntax:
https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconn ...

Ubuntu Server mit StrongSwan IPsec anbinden:
https://administrator.de/forum/strongswan-site-to-site-mit-einer-nic-237 ...

Apple iOS Configurator 2:
https://support.apple.com/apple-configurator

IPsec Protokoll Grundlagen:
https://de.wikipedia.org/wiki/IPsec
https://administrator.de/contentid/73117

OT: Alternative L2TP VPN:
pfSense/OPNsense:
https://administrator.de/contentid/585307
Mikrotik:
https://administrator.de/contentid/562927#comment-1440162
Linux StrongSwan:
https://administrator.de/contentid/665167#comment-1531285 bzw. mit GUI HIER.

Content-Key: 1754377434

Url: https://administrator.de/contentid/1754377434

Ausgedruckt am: 18.05.2022 um 09:05 Uhr

Mitglied: commodity
commodity 27.01.2022 um 13:03:30 Uhr
Goto Top
Mal wieder ein dickes Danke! Jedes Mal, wenn ich eines Deiner Tutorials lese denke ich, wann macht der daraus ein Buch? ;-) face-wink

Ich mag es, wie Du schreibst, wie Du den Background erklärst und die guten Verweise auf Parallelen/Ergänzungen. Das ist perfekt, auch für den (interessierten, des Lesens mächtigen) Laien gut umsetzbar und für den (interessierten) Profi (der nicht täglich Netze macht) inspirierend und befruchtend. Community and Open Source at it's best!

Kommt im konkreten Fall auch wie gerufen. Bin gerade aus Performancegründen am Testen von Alternativen zu OVPN.

Viele Grüße, commodity