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

Einleitung

Die Verwendung eines Raspberry Pi's als VPN Server ist hier nur beispielhaft zu sehen. Natürlich funktioniert das Setup auch auf "großer" Hardware, vServern usw. auch mit anderen Distributionen und natürlich auch unter der freien OpenWRT Router Firmware.
Ungenutzt, in der Bastelschublade schlummernden RasPi's, kann man ggf. so wieder neues Leben einhauchen...
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 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 Client VPN Tutorial verzahnt. Auch hier bedient der IPsec Klassiker Strongswan VPN Verbindungen aller onboard VPN Clients.

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 und erhöhen somit die VPN Sicherheit. Damit wird auch das Thema PKI hier etwas gestreift.
Das Tutorial will und kann kein Grundlagentutorial sein, welches umfassend eine PKI und auch das IPsec Protokoll erklärt. Das würde den Rahmen eines einfachen Praxistutorials sprengen.

Ein klein wenig Linux KnowHow um sich auf dem CLI zu bewegen und etwas Grundwissen zum Thema Netzwerk und PKI sollte vorhanden sein.
Ein einfacher Linux Rechner oder vServer mit SSH Zugang (z.B. PuTTY) ist der Ausgangspunkt für den IKEv2 VPN Server.

Das Tutorial nutzt als FQDN Adressen freie DNS Hostnamen mit nip.io DNS Adressen, die auch private RFC 1918 IPs im Heimnetz auflösen. Diese dienen im Tutorial als Ersatz für feste FQDN Hostnamen oder DDNS Hostnamen ohne einen DNS Server oder registrierte Hostnamen zu erzwingen. Man kann so sehr einfach FQDN Hostnamen verwenden, auch im Heimnetz.
Die WAN/Internet Port IP Adresse des Server ist im Beispiel = 10.99.1.135 was dann dem FQDN Hostnamen 10-99-1-135.nip.io entspricht. nip.io Hostnamen können frei für beliebige IP Adresse verwendet werden, nicht nur für RFC1918 IPs.
Wer eigene FQDN Hostnamen oder DDNS Hostnamen verwendet ersetzt natürlich dieses Tutorial Beispiel damit.
Los gehts...!

VPN Server Konfiguration

swanctl unter StrongSwan ist ein neues, portables Command Line Utility um Strongswan ü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 also 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, wie immer, (sudo su) erforderlich:

apt install strongswan strongswan-pki libstrongswan-extra-plugins 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

 # Uncomment the next line to enable packet forwarding for IPv4net.ipv4.ip_forward=1 

das Kommentarzeichen "#" vor der Zeile net.ipv4.ip_forward=1 entfernt und die Datei sichert. Danach rebootet man den Server bzw. RasPi.
Ist das erledigt, geht es mit der Zertifikats Erstellung bzw. Import der Zertifikate und der eigentlichen StrongSwan Konfiguration weiter.

CA und Server Zertifikat mit StrongSwan PKI erstellen

Wie oben bereits erwähnt, prüfen alle onboard IKEv2 VPN Clients ein Server Zertifikat ihres Ziels, sprich des VPN Servers. Es ist daher eine kleine, einfache PKI erforderlich die aber schnell mit den StrongSwan Bordmitteln erstellt ist. Der Einsatz der onboard VPN Clients schafft somit immer eine zusätzliche VPN Sicherheit.
Sofern nicht schon vorhanden, muss eine Zertifizierungstelle (CA) und mit ihr ein Serverzertifikat für den VPN Server erstellt werden. Quasi also die "Meldebehörde" und einen "Server-Ausweis" mit Stempel.
Die "Behörde" (CA) gibt man den Endgeräten jeweils 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 VPN Server untergeschoben hat.
Besteht schon eine CA, weil man z.B. auf einem Windows Server seine Nutzer mit Zertifikaten ausstattet, erstellt man einfach über diese CA ein zusätzliches Server Zertifikat. (Siehe Folgekapitel)
Wer keine "Behörde" (CA) hat, muß diese einrichten um Ausweise (Zertifikate) ausstellen zu können.

( Es macht Sinn die u.a. Kommandos ggf. vorab 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.)

Hierzu sind 2 Kommandos erforderlich. Dateinamen können frei gewählt werden.

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/raspica-key.pempki --self --ca --lifetime 3650 --in /etc/swanctl/private/raspica-key.pem --type rsa --dn "C=DE, CN=RasPi CA" --outform pem > /etc/swanctl/x509ca/raspica-cert.pem 

Letzteres, also die Datei raspica-cert.pem, ist die "Behörde" (CA) die über den Zertifikats Import in die VPN Clients (Windows, Apple, Android etc.) importiert wird.
Details für den Zertifikats Import in Windows und Apple usw. erklärt wieder das hiesige pfSense / OPNsense Firewall VPN Tutorial für mobile Clients.
⚠️ Es ist also sinnvoll diese CA Zertifikatsdatei /etc/swanctl/x509ca/raspica-cert.pem schon jetzt auf einem USB Stick zu sichern oder per WinSCP lokal zu kopieren um sie später auf dem VPN Client importieren zu können.

Wieder sind 2 Kommandos auszuführen.

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/server-key.pempki --pub --in /etc/swanctl/private/server-key.pem --type rsa | pki --issue --lifetime 1825 --cacert /etc/swanctl/x509ca/raspica-cert.pem --cakey /etc/swanctl/private/raspica-key.pem --dn "CN=10-99-1-135.nip.io" --san 10-99-1-135.nip.io --flag serverAuth --flag ikeIntermediate --outform pem > /etc/swanctl/x509/server-cert.pem 

Bestehende CA oder Zertifikats Apps nutzen

Wer schon eine bestehende, zentrale CA hat z.B. auf einem Windows Server oder, wie im folgenden Beispiel, auf einer pfSense oder OPNsense Firewall kann natürlich diese CA nutzen und erstellt mit ihr lediglich nur ein weiteres Server Zertifikat für den VPN Server.
Exemplarisch zeigen die folgenden Screenshots dies am Beispiel im Cert. Manager bzw. Trust (Zertifikats Manager) Menü der pfSense bzw. OPNsense Firewall:
(Menü "CA")
(Exportiertes CA Zertifikat wird nur für die VPN Clients verwendet)

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

Das erstellte 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.
Dieses Zertifikat und Key sind dann in den Strongswan IKEv2 VPN Server zu importieren indem man sie einfach per USB Stick oder SCP (z.B. WinSCP) in die folgenden VPN Server Verzeichnisse kopiert:

• Server Zertifikats Datei in: /etc/swanctl/x509
• Key Datei in: /etc/swanctl/private

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 anderen Tools seiner Wahl erstellen wie z.B. OpenSSL oder dem Klassiker XCA. Letzteren auch in einer portablen Version für den USB Stick wie u.a. hier vorgestellt.
In die VPN Clients muss dem ersten Verbindungsaufbau das CA Zertifikat importiert werden! (Wird später im Client Kapitel im Detail erklärt)

StrongSwan Konfiguration

Die eigentliche StrongSwan VPN Server 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. Diese, mit eigenen Werten anzupassenden Einstellungen, sind wie folgt:

• PSK Passwörter durch Sinnvolle ersetzen !
• Internes VPN Client Netzwerk (pools): 172.25.25.0 /24
• Lokale IP Adresse (local_addrs) eth0 Interface: 10.99.1.135 (DNS Beispiel: 10-99-1-135.nip.io o. 0a630187.nip.io)
• Optional lokale DNS Server IP (dns = ...) die automatisch an die VPN Clients übergeben wird bei Einwahl: 172.16.7.254. (Wenn kein lokaler DNS Server vorhanden weglassen oder globalen DNS wie z.B. 9.9.9.9 einsetzen)
• 2 VPN User (eap-1 u. 2) mit der User/Passwd Kombination user/test123 und user2/user2
• Usernamen/Passwörter sollten doppelt genutzt werden. (Mehrfacheinwahl mit gleichen Zugangsdaten verbietet der Parameter unique = replace. Man kann die Mehrfacheinwahl aber erlauben wenn man diesen Parameter einfach weglässt!)

connections { ikev2-mobile-defaults { unique = replace version = 2 proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha256-modp1024 send_cert = always pools = pool-ipv4 local_addrs = 10.99.1.135 remote_addrs = 0.0.0.0/0,::/0 local { auth = pubkey certs = server-cert.pem id = fqdn:10-99-1-135.nip.io } remote { id = %any auth = eap-mschapv2 eap_id = %any } children { ikev2-mobile { local_ts = 0.0.0.0/0 esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1 start_action = trap } } }}pools { pool-ipv4 { addrs = 172.25.25.0/24 dns = 9.9.9.9 } }secrets { eap-1 { id = user secret = "test123" } eap-2 { id = user2 secret = "user2" }} 

(Die fehlenden "-modpXXXX" DH Proposals der Phase 2 (children, proposals) lösen ein Problem bei instabilen Apple IKEv2 Clients und der Empfehlung PFS zu deaktivieren. Siehe dazu HIER)
⚠️ Wichtig in der o.a. Konfig und um später Frust zu vermeiden sind im Abschnitt "remote_addrs..." unter " local {..." die 2 folgenden Parameter:

• certs = server-cert.pem ==> Dieser zeigt auf den Dateinamen des oben erzeugten Server Zertifikats
• id = fqdn:10-99-1-135.nip.io ==> Muss einem der Common Name/SAN FQDN Namen im Server Zertifikat (--san 10-99-1-135.nip.io) entsprechen! Bzw. zusätzlich der IP Adresse sofern statisch und im SAN definiert. Als Beispiel gilt hier analog dasselbe für das IPKEv2 Server Zertifikat auf einer Firewall (Alternative Names)!

Sind die o.a. StrongSwan Konfiguration und Zertifikate in die entsprechenden Verzeichnisse kopiert, führt man ein
swanctl -q
aus um diese Einstellungen zu laden. (Mit einem Neustart des Daemons systemctl restart strongswan oder einem Reboot passiert das immer automatisch !). Strongswan quittiert dies entsprechend mit einer Erfolgsmeldung (successfully loaded):

root@vpnserver:/home/pi# swanctl -qloaded certificate from '/etc/swanctl/x509/RasPiServer.crt'loaded RSA key from '/etc/swanctl/private/RasPiServer.key'loaded eap secret 'eap-1'loaded eap secret 'eap-2'no authorities found, 0 unloadedloaded pool 'pool-ipv4'successfully loaded 1 pools, 0 unloadedloaded connection 'ikev2-mobile-defaults'successfully loaded 1 connections, 0 unloaded 

Optionales Loopback Interface mit zweiter IP

Optional ist es hilfreich bei einem standalone Server ein lokales LAN (z.B. vServer) eine 2te IP Adresse auf dem Loopback Interface lo im Server einzurichten. So ist man immer in der Lage von den aktiven VPN Clients den Server zu pingen und damit die Funktion der VPN Verbindung zu verifizieren.
Gleichzeitig dient sie optional als Keepalive IP Adresse (z.B. FritzBox) und ist ferner hilfreich für das direkte Forwarding von lokalen Diensten. Dazu später mehr...

Für die 2te local Interface IP wählt man ein freies IP Netz was in Benutzung ist!
Hier eine Adresse aus dem 172.25.24.0 /24 Netz, weil dieses idealerweise später mit einem /23er Prefix (255.255.254.0) zusammen mit dem Client Pool IP Netz über eine VPN Peer Konfig übertragen werden kann (Phase 2 SA) (172.25.24.0 /23 = 172.25.24.1 bis 172.25.25.254)
Mit ip addr add 172.25.1/32 dev lo wird die IP temporär hinzugefügt. (Check mit ip a und Host Subnetzmaske /32 beachten!)
Damit dies später auch einen Reboot überlebt, fügt man diese IP zusätzlich in der Datei /etc/network/interfaces hinzu:

# The loopback network interfaceauto loiface lo inet loopbackiface lo inet staticaddress 172.25.24.1netmask 255.255.255.255 

Troubleshooten kann man die Einwahl der VPN Clients indem man das Log live mit swanctl -T betrachtet. (Stop mit CTRL-C)
Bei Änderung in der Konfiguration muss auch immer ein swanctl -q gemacht werden um diese zu aktivieren !
Falls der IPsec Prozess hängen sollte und die VPN Einwahl scheitert kann man den Daemon mit systemctl restart strongswan neu durchstarten.
Zusätzlich sollte man darauf achten das der Strongswan Daemon beim Booten aktiviert ist (systemctl enable strongswan) was in der Regel aber der Fall ist. (Den aktuellen Status des Daemons zeigt systemctl status strongswan)
Damit ist der VPN Server einsatzklar und weiter geht es mit den VPN onboard Clients...

Konfiguration der Windows und Apple VPN Clients

In der Regel sind bei Windows, Apple und allen Smartphones immer zwei oder auch mehr Protokolle im VPN Client vorhanden. (Linux hat mit StrongSwan immer einen Universalclient an Bord).
Einmal das L2TP VPN Protokoll und das IPsec IKEv2 Protokoll. Um Letzteres geht es in diesem Tutorial.

Der Microsoft Windows VPN Client nutzt als Default schwache Schlüssel Algorithmen. Offensichtlicher Grund ist die Kompatibilität zu älteren Windows Versionen zu erhalten ?!
Wer unter Windows mit den Default Settings arbeitet, Anpassung, muss daher immer sicherstellen das immer und in den Phase 2 Proposals supportet sind in seinem o.a. StrongSwan Setup!
Das Tutorial berücksichtigt diese Default Werte, funktioniert also immer "out of the box"!
Betrachtet man die o.a. StrongSwan Konfiguration (Parameter proposals = ...), erkennt man diese Defaults.
Ebenso in den pfSense / OPNsense Settings beschreibt das hiesige VPN Tutorial (siehe weiterführende Links am Ende) diese 2 Settings um die aktuellen Defaults des Windows VPN Clients abzudecken.

Will man mehr Sicherheit muss entweder ein Eingriff in die Registry her oder Windows muss mit zusätzlichen Powershell Kommandos zu stärkeren Schlüsselverfahren "überredet" werden, die Apple schon seit langem im Default vorgibt. (z.B. AES256,SHA256,DH14). Wie man das bei Bedarf anpassen kann wird weiter unten im Detail erklärt.

❗️Wichtig bei ALLEN VPN Clients ist, daß immer das o.a. erstellte CA Root Zertifikat (Stammzertifikat) in die entsprechenden Endgeräte via Zertifikatsverwaltung importiert wird!
Wie oben bereits erwähnt prüfen die IKEv2 onboard VPN Clients immer das Server Zertifikat um sicherzustellen, daß niemand ihnen einen Fake VPN Server unterjubelt.
Der Zertifikats Import ist oben und im pfSense/OPNsense Tutorial umfassend für Apple erklärt. Dort findet man weitere Details zur Einrichtung aller IKEv2 onboard VPN Clients.

Windows VPN Client

⚠️ Bei 21H2 unbedingt Patch HIER !

Vorab nochmals die Erinnerung die CA Zertifikatsdatei /etc/swanctl/x509ca/raspica-cert.pem in den Windows Client per Doppelklick in den Zertifikatsmanager zu importieren!
Tip:
Zertifikatsdateien mit der Endung .pem starten bei Doppelklick leider den Windows Zertifikatsmamanger (certlm) nicht automatisch. Das machen .crt Dateiendungen. Es gibt 2 einfache Lösungen die .pem Datei zu importieren:

• Startet man die Windows Zert. Verwaltung certlm per Hand und wählt das Verzeichnis "Vertrauenswürdige Stammzertifizierungsstellen" und dann "Aktionen" und "Importieren" kann man auch Dateien mit der Endung .pem importieren.

• Alternativ einfach die Dateiendung .pem in .crt umbenennen

Das Setup des Windows Clients ist über das GUI "Erstellen eines neuen VPN" einfach zu bewerkstelligen:

⚠️ Der Servername hier als FQDN Hostname angegeben werden wenn dieser im o.a. Server Zertifikat (Common Name/SAN) benutzt wurde!
Windows prüft so die Au­then­ti­zi­tät des VPN Servers. (Beispiel: "--dn "CN=10-99-1-135.nip.io" --san 10-99-1-135.nip.io")
Es muss mit dem was unter "id = fqdn:10-99-1-135.nip.io" in der o.a. Strongswan Konfig definiert wurde übereinstimmen!
Der Servername oder IP wird vom Windows VPN Client automatisch als remote ID übergeben!

Wird die IP Adresse verwendet auch diese bei der Zertifikats Generierung zusätzlich angegeben worden sein. Die Integration von IP Adressen ins Zertifikat macht natürlich nur dann Sinn wenn diese auch statische, feste IPs sind und bleiben. Gibt man z.B. die IP an, hat diese aber oben nicht im Zertifikat (SAN) definiert oder nur den DNS Hostnamen, scheitert die IKEv2 VPN Verbindung zumindestens für Windows Clients!

VPN-Typ = IKEv2
Anmeldeinformationstyp = Benutzername u. Kennwort.
Wer die Angabe des Usernamen/Password automatisieren möchte kann dies entsprechend in den Eigenschaften des Clients mit einem Haken aktivieren.

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).

Der Haken Standardgateway bedeutet ein sog. "Gateway Redirect" wobei dann der Client Traffic durch die VPN Verbindung läuft.
Ohne den Haken geht nur für das remote Netz relevante Traffic durch die VPN Verbindung (sog. "Split Tunneling"), alles andere bleibt lokal. Letzteres ist performanter.

Windows Client: VPN Security erhöhen

⚠️ Die folgenden Einstellungen sind und ausschliesslich nur für solche Anwender erforderlich, die eine höhere VPN Sicherheit im Windows Client statt der Default Einstellungen wünschen.
Wer mit den etwas schwächeren aber dennoch sicheren Windows Default Einstellungen leben, kann überspringt dieses Kapitel!!
Das o.a. Strongswan Setup bedient immer sowohl die Windows Default Schlüssel Algorithmen als auch stärkere Algorithmen aller anderer VPN Clients bzw. Angepasste der Windows Registry!

Eine einfache Option ist den bestehenden VPN Client per Powershell anzupassen:

Set-VpnConnectionIPsecConfiguration -ConnectionName "RasPi" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection 

Wichtig ist hier der Parameter -ConnectionName "RasPi" der 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 auf 1 oder 2 setzen

⚠️ Wer die Windows Registry so anpasst, veranlasst Windows diese starken IKE Algorithmen zu nutzen ! Davon werden also immer auch ggf. bestehende VPN Verbindungen beeinflusst, die die zuvor schwächeren Default Einstellung nutzen.
Die o.a. Powershell Anpassung macht dieses aufgrund der Bindung an den VPN Verbindungsnamen und damit die indivuelle VPN Verbindung immer dediziert pro Verbindung. Diese Option ist also flexibler in der Anpassung unterschiedlicher VPN Verbindungen auf andere VPN Zielhardware.
Das sollte man immer auf dem Radar haben wenn man diese Anpassung der Registry oder per GPOs vornimmt ! Im Zweifel immer den Default belassen.

Apple VPN Client

Auch beim MacOS Client muss zuvor das CA Zertifikat in die Schlüsselbundverwaltung importiert werden wie HIER beschrieben.
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. "Entfernte ID" muss der ID unter "local" im Server Setup entsprechen. ("id = fqdn:10-99-1-135.nip.io")
Den Client Usernamen und das Password konfiguriert man im Button "Authentifizierungseinstellungen".

Android 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.

Mobile Endgeräte allgemein

Für alle mobilen iOS Endgeräte von Apple sendet man sich einfach die oben gesicherte CA Zertifikats Datei per Email Attachment oder SMS und 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.

Jumphost VPN Setup mit vServer und FritzBox

Ein interessantes Anwendungsdesign aus der Praxis mit diesem VPN Setup ist die Realisierung eines sog. "Jumphosts" für DS-Lite Internet Anschlüsse.
DS-Lite Anschlüsse können, technisch bedingt, durch CG-NAT beim Provider und wegen der dadurch fehlenden öffentlichen IPv4 Adresse, generell keinen Zugang von außen mit IPv4 realisieren. (Mit IPv6 geht es natürlich !) Das betrifft außer Port Weiterleitung (Port Forwarding) natürlich auch einen VPN Zugang.

Das folgende Beispiel zeigt eine Lösung für IPv4 über einen vServer mit der FritzBox. Es klappt außer mit der FritzBox natürlich auch mit jedem anderen VPN Router oder Firewall die IPsec supportet.
Die zusätzliche Installation weiterer VPN Protokolle (Wireguard etc.) kann z.B. so einen vServer zu einem universellen VPN Access Server für DS-Lite usw. machen.
Ob man einen Provider Anschluss mit DS-Lite und CG-NAT hat, erkennt man im Router Dashboard/Übersicht in der Regel anhand der vom Provider dynamisch zugeteilten WAN/Internet IPv4 Adresse.
Ist diese eine RFC 1918 oder eine RFC 6598 IPv4 Adresse (100.64.0.0 /10) besitzt man einen DS-Lite Anschluss. (Siehe u.a. auch hier).

Als möglichen Workaround für den remoten Zugang mietet man z.B. einen preiswerten vServer bei einem Hoster und lässt die heimische FritzBox ein VPN zu diesem vServer aufbauen um das heimische IPv4 Netzwerk an den VPN vServer zu koppeln.
Auf mobilen Endgeräten, Laptops etc. nutzt man bequem die auf allen Geräten vorhandenen onboard VPN Clients für den remoten IPv4 Zugang auf das Heimnetz. Der Server arbeitet quasi als VPN Relais Station für den remoten Zugang.

Auf diese Weise umgeht man die IPv4 Einschränkungen durch DS-Lite/CGNAT Anschlüsse und kann trotzdem mit mobilen onboard IPv4 VPN Clients bequem das heimisches LAN sicher erreichen.
Ein zusätzliches Kapitel beschreibt wie damit auch lokale Server im Heimnetz via diesem VPN vServer direkt erreichbar sind. Port Forwarding mit IPv4 von außen scheitert genau wie VPN ebenfalls an DS-Lite / CG-NAT Anschlüssen. Ein Jumphost löst diese Problematik auf elegante Art und Weise.
Los gehts...

StrongSwan Jumphost Konfiguration

Als Erstes ist die o.a. StrongSwan Konfiguration auf so ein Design entsprechend anzupassen und für das Router VPN zu erweitern. (Für die FritzBox Konfiguration Dank an @colinardo !)
⚠️ Die folgenden Einstellungen sind ggf. wieder auf eigene IP Adressierungen anzupassen:

• Passwörter 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 (hier Standard Setup FritzBox) verwendet, dies unter "remote_ts = x.y.z.h/maske" anpassen
• Remote ID bzw. Keyid und Passwort (unter "secrets ike-3") müssen mit dem der FritzBox bzw. in der FritzBox VPN Konfig Datei konfigurierten Passwort genau übereinstimmen, ansonsten scheitert der Tunnelaufbau zur FB!

Die gesamte Strongswan Konfig Datei wird, wie schon oben beschrieben, ins Verzeichnis /etc/swanctl/conf.d z.B. mit dem Namen jumphost.conf kopiert und sieht dann so aus:

connections { fritzbox { local_addrs = <vserver_ip_addresse> remote_addrs = 0.0.0.0/0 local { auth = psk id = <vserver_ip_addresse> } remote { auth = psk id = keyid:strongswan@fritz.box } children { net { local_ts = 172.25.24.0/23 remote_ts = 192.168.178.0/24 esp_proposals = aes256-sha512-modp1024,aes256-sha1-modp1024 } } version = 1 proposals = aes256-sha512-modp1024,aes256-sha1-modp1024 } ikev2-mobile-defaults { unique = replace version = 2 proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha256-modp1024 send_cert = always pools = pool-ipv4 local_addrs = <vserver_ip_addresse> remote_addrs = 0.0.0.0/0,::/0 local { auth = pubkey certs = server-cert.pem id = fqdn:<v_server_FQDN> } remote { id = %any auth = eap-mschapv2 eap_id = %any } children { ikev2-mobile { local_ts = 0.0.0.0/0 esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1 start_action = trap } } }}pools { pool-ipv4 { addrs = 172.25.25.0/24 dns = 9.9.9.9,192.168.178.1 }}secrets { eap-1 { id = user secret = "test123" } eap-2 { id = user2 secret = "user2" } ike-3 { id = keyid:strongswan@fritz.box secret = "test1234" }} 

Die beiden "eap" Passwörter sind die bekannten VPN Beispiel Useraccounts mit ihren Passwörtern. Der "ike-3" User/Passwort Eintrag ist der, der den FritzBox VPN Tunnel authentisiert.
Hier können natürlich auch noch weitere VPN Nutzer und auch FritzBox Links hinzugefügt werden.

FritzBox VPN Konfigurations Datei

Die FritzBox VPN Konfigurationsdatei ist eine reine Textdatei die man mit einem einfachen Text Editor wie z.B. Notepad++ erstellt und ggf. anpasst.
Die passende FritzBox VPN Konfigurations Datei, die man über das FritzBox GUI (Internet -> Freigaben -> VPN) einspielt, sieht so aus:

• <server_hoster_ip> durch die vServer IP Adresse oder FQDN ersetzen.
• Lokales IP Netz bei phase2localid und ipnet anpassen. (Muss zur o.a. Strongswan Konfig passen!)
• Passwort unter key auf eigenes ändern. (Muss zur o.a. Strongswan Konfig passen! (ike-3))

vpncfg { connections { enabled = yes; editable = no; conn_type = conntype_lan; name = "StrongSwan"; always_renew = yes; reject_not_encrypted = no; dont_filter_netbios = yes; localip = 0.0.0.0; local_virtualip = 0.0.0.0; remoteip = <v_server_ip_addresse>; remote_virtualip = 0.0.0.0; keepalive_ip = 172.25.24.1;localid { key_id = "strongswan@fritz.box"; } remoteid { ipaddr = <v_server_ip_addresse>; } mode = phase1_mode_idp; phase1ss = "LT8h/all/all/all"; keytype = connkeytype_pre_shared; key = "test1234"; cert_do_server_auth = no; use_nat_t = yes; use_xauth = no; use_cfgmode = no; phase2localid { ipnet { ipaddr = 192.168.178.0; mask = 255.255.255.0; } } phase2remoteid { ipnet { ipaddr = 172.25.24.0; mask = 255.255.254.0; } } phase2ss = "esp-all-all/ah-none/comp-all/pfs"; accesslist = "permit ip any 172.25.24.0 255.255.254.0"; } ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", "udp 0.0.0.0:4500 0.0.0.0:4500"; } 

Mit dem Parameter ipaddr = 172.25.24.0; und der größeren /23 Subnetz Maske werden IP Netze, das Client Poolnetz 172.25.25.0 und auch die local Loopback IP des Servers im Tunnel übertragen. Damit ist sichergestellt das die Keepalive IP der FritzBox den Tunnel zum Jumphost aktiv hält!
(Weitere Detailinfos zu den FritzBox IPsec Krypto Profilen siehe HIER!)

Wie die onboard IKEv2 VPN Clients der Endgeräte einzurichten sind erfährt man u.a. HIER.
Die beiden IKEv2 VPN Client Beispiel Usernamen und Passwörter sind die, die in der Strongswan Konfig mit "eap-1" und "eap-1" definiert wurden.

Auch hier lässt sich der VPN Tunnelaufbau bequem auf dem Jumpserver mitloggen um ggf. vorhandene Fehler sofort zu erkennen.

• swanctl -T = Listet den kompletten Tunnelaufbau
• swanctl -l = Zeigt alle aktiven VPN Tunnel an

Client VPN und NAT

Ist die o.a. VPN Jumphost Konfiguration aktiv, merkt man an einem aktiven VPN Client schnell das außer dem remoten FritzBox Netz, der Server IP 172.25.24.1 und den dortigen Geräten nur noch die anderen VPN Clients erreichbar sind aber kein Internet Zugriff besteht. Ein Internet Zugang des VPN Clients bei aktiver Tunnelverbindung scheitert also. Windows zeigt dann die Weltkugel in der Taskleiste.

Dieses Verhalten ist normal und erwartbar, denn die VPN Clients nutzen VPN intern mit der Pool IP 172.25.25.0/24 ein privates RFC 1918 IP Netz welches im Internet geroutet wird. Datenpakete mit diesen IP Absenderadressen werden bei Providern deshalb sofort verworfen!
Man muss also dafür sorgen das VPN Clients bei ausgehenden Paketen ins Internet immer die öffentliche vServer Adresse als Absender verwenden. Das erledigt man elegant mit NAT/Masquerading in der vServer Firewall.

Da iptables durch das moderne nftables Framework abgelöst wird, ist es sinnvoll diese auch dafür zu verwenden. Moderne Distributionen wie Debian Bullseye und höher u.a. haben im Default statt iptables nur noch an Bord.
Die Anpassung ist schnell gemacht...
Man editiert lediglich mit dem nano Editor die Datei /etc/nftables.conf und fügt am Ende das folgende NAT Statement dort zusätzlich ein:

table ip nat { define VPN_NETS = { 192.168.178.0/24 } # VPN Client NAT/Masquerade ausser unter "VPN_NETS" definierte remote LAN Netzwerke  chain postrouting { type nat hook postrouting priority 100; policy accept; oifname eth0 ip daddr $VPN_NETS accept ip saddr 172.25.25.0/24 oif eth0 masquerade }} 

Wer ein anderes internes VPN Client Netz als das hier verwendete 172.25.25.0/24 konfiguriert hat, passt das entsprechend an.
Ebenso die vServer Netzwerk Schnittstelle mit der öffentlichen Provider IP (hier im Beispiel eth0). Die genaue Bezeichnung der Schnittstelle zeigt ein ip a oder auch das ältere ifconfig.
Sind remote weitere VPN IP LAN Netze vorhanden, dann passt man die Maske unter VPN_NETS entsprechend an oder fügt dort, Komma separiert, weitere Netze hinzu. Die Variable VPN_NETS definiert die lokalen LAN Netze die vom NAT/Masquerading ausgenommen sind.
Mit systemctl restart nftables startet man die vServer Firewall dann neu und schon klappt auch der Internet Zugang mit den VPN Clients, was ein Traceroute (tracert Windows) oder Besuch von http://myexternalip.com dann auch zeigt! (Das aktive Firewall Ruleset zeigt das Kommando nft list ruleset)

Port Forwarding

Ein VPN, wie oben beschrieben, sollte immer die erste Option sein um von außen sicher geschützt auf sein Heimnetz oder dessen Inhalte zuzugreifen.
Dennoch gibt es sinnvolle Anforderungen wo man auch lokale Resourcen von außen direkt VPN zugänglich machen muss oder möchte.
Dies kann z.B. beim Betrieb einer eigenen, privaten Cloud mit Nextcloud der Fall sein oder bei einem einfachen Webserver um Inhalte im Internet offen zugänglich zu machen. Die folgende Abbildung zeigt ein solches Szenario mit dem o.a. Jumphost Setup als Grundlage.

Die blau gestrichelte Seite symbolisiert den direkten Webserver Zugang.
Es gibt 2 Optionen diese technisch auf dem Jumphost umzusetzen:

• Port Forwarding mit Source NAT über die lokale Firewall im vServer
• Zugang mit einem Proxy wie z.B. Nginx

Die erste Variante muss über die lokale Firewall des vServers gelöst werden und ist in der Konfiguration nicht trivial. Sie birgt zudem das Risiko bei Fehlern den vServer in seiner Sicherheit zu gefährden.

Eine Lösung mit einem Proxy ist sicherer und auch für Anfänger leichter umzusetzen und hat damit weniger Risiken.
Der Vorteil das der Nginx Proxy auch andere Ports wie SSH usw. forwarden kann statt nur Webports (TCP 80, 443) spricht ebenfalls für diese Lösung.
Ein apt install nginx installiert dafür die nötigen Komponenten.

Das u.a Konfigurationsbeispiel zeigt eine Portverschleierung um nicht einen Standardport wie TCP 80 zu öffnen den jeder Portscanner abfragt.
Man spricht den vServer von außen mit z.B. TCP 58080 an, der den Traffic dann an den lokalen Webserver mit TCP 80 forwardet. http://<vServer_ip_adresse_hostname>:58080
Wer TCP 80 oder 443 durchreichen will ändert nur die Listen Ports in "80" oder "443" und "proxy_pass http:/ /192.168.188.222:443;" oder "..:80" auf die Adresse des lokalen, freizugebenen Servers.
Die einfache Konfiguration unter /etc/nginx/sites-available/default sieht dann so aus:

# Default server configuration# Reverse proxy any port to other internal hostsserver { listen 58080; listen [::]:58080; location / { proxy_bind 172.25.24.1; proxy_pass http://192.168.178.222:80; include proxy_params; }} 

Danach startet man den Proxy mit systemctl restart nginx neu um die Konfig zu aktivieren
Der Nginx Reverse Proxy hat sehr flexible Konfig Optionen. Alles aufzuzählen würde den Rahmen dieses Tutorials sprengen.

Port Forwarding mit nftables Firewall absichern

Um nur gewollten Forwarding Traffic passieren zu lassen ist es sinnvoll den vServer entsprechend mit seiner Firewall auf dem Eingangsport abzusichern. Auch hier wieder die Realisierung über nftables in der/etc/nftables.conf Datei, die dann vollständig wie folgt aussieht:

table inet filter { chain input { type filter hook input priority 0; policy drop; # akzeptiert jeden Traffic auf localhost Interface iif lo accept # akzeptiert Traffic vom vServer ct state established,related accept # akzeptiert ICMP types (blockt Echo (Ping)) ip protocol icmp icmp type {time-exceeded, parameter-problem, destination-unreachable } accept # akzeptiert eingehenden Traffic für Systemdienste, 22=SSH, 443=HTTPS, 58080=WebProxy tcp dport { 22, 443, 58080 } ct state new accept # akzeptiert IPsec VPN udp dport { isakmp, ipsec-nat-t } accept ip protocol esp accept # erlaubt VPN Tunneltraffic meta ipsec exists accept # akzeptiert IPv6 neighbour discovery, ansonsten keine IPv6 Connectivity ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept # logging und zaehlen von geblocktem Traffic. (nur Troubleshooting, Monitoring) # log prefix "[nftables]Geblockt: " counter drop  # zaehlt geblockten Traffic counter drop } chain forward { type filter hook forward priority 0; } chain output { type filter hook output priority 0; }}table ip nat { define VPN_NETS = { 192.168.178.0/24 } # Masquerade VPN Clients zum Internet ausser VPN tunnel chain postrouting { type nat hook postrouting priority 100; policy accept; oifname ens192 ip daddr $VPN_NETS accept ip saddr 172.25.25.0/28 oif ens192 masquerade }} 

Weiterführende Links

IKEv2 VPN server for Windows and Apple clients on Raspberry Pi

IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Strongswan Zertifikate

https://wiki.strongswan.org/projects/strongswan/wiki/Swanctlconf
PKI Zertifikate Quickstart:
https://docs.strongswan.org/docs/5.9/pki/pkiQuickstart.html
Selbst signiertes Server Zertifikat mit OpenSSL

vServer IKEv2 Setup
Fritzbox VPN Anbindung

Feste IP Adressen für mobile VPN User

Mikrotik VPN Kopplung an Strongswan

https://www.heise.de/ct/ausgabe/2017-19-VPN-und-Remote-Desktop-Verbindun ...

https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconn ...

Fritzbox Wireguard VPN Besonderheiten und ihre Lösung

Strongswan Site-to-Site mit einer NIC

Jumphost VPN (IPSec)
StrongSwan IPsec IKEv2 VPN Pingprobleme

Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP

VPN auf Dedicated Server

S2S-Wireguard: AVM zu Mikrotik

https://support.apple.com/apple-configurator

https://de.wikipedia.org/wiki/IPsec
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen

Netzwerk Management Server mit Raspberry Pi

Routingprobleme über OpenVPN auf Fritzbox

Feste IPs zuhause in pfsense via GRE Tunnel
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
S2S-Wireguard: AVM zu Mikrotik

pfSense/OPNsense:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer

L2TP VPN Server mit Mikrotik

Ubtuntu 20.10 mit UdmPro L2tp VPN Server verbinden bzw. mit GUI HIER.