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

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 KEINE Installation und Anpassung zusätzlicher VPN Client Software o. Protokolle 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.
Die parallele Erweiterung auf Wireguard oder OpenVPN Support quasi als universalen VPN Server ist problemlos möglich.



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.
❗️Alle Setup Kommandos sollten mit Root Rechten (sudo su) ausgeführt werden.
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 jede 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, root Rechte (sudo su) erforderlich:


⚠️ 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 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.

CA einrichten:
(Tip: 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.
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.

Server Zertifikat erstellen:
Wieder sind 2 Kommandos auszuführen.
👉🏽 Beispiele zur Zertifikatserstellung mit dem bordeigenen OpenSSL sind u.a. HIER ausführlich beschrieben.

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:
CA Zertifikat exportieren: (Menü "CA")
(Exportiertes CA Zertifikat wird nur für die VPN Clients verwendet)
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")

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
• Server Key Datei in: /etc/swanctl/private
• CA Zertifikats Datei in: /etc/swanctl/x509ca
• CA 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 vor dem ersten Verbindungsaufbau nur 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 Beispielpasswörter durch sinnvolle, eigene Passwörter ersetzen!
• Internes VPN Client IP Netzwerk (pools): 172.25.25.0 /24 ggf. auf eigene Adressierung anpassen.
• Lokale IP Adresse (local_addrs) eth0 Interface: 10.99.1.135 (DNS Beispiel statt IP: 10-99-1-135.nip.io o. 0a630187.nip.io)
• Optional lokale DNS Server IP (dns = ... im Abschnitt pools {...) die automatisch an die VPN Clients übergeben wird bei Einwahl: 172.16.7.254. (Wenn kein lokaler DNS Server vorhanden weglassen oder den DNS Server des Hosting Providers 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 mit weiteren Usern ggf. erweitern
• Usernamen/Passwörter sollten nicht 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 wie im hiesigen Beispiel!)

(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 ==> Der FQDN muss einem der Common Name/SAN FQDN Namen im Server Zertifikat entsprechen! FQDN auf eigenen anpassen! Z.B. (--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)!
• Wer hier statt eines FQDN Hostnamens die nackte IPv4 Adresse des Servers als ID verwenden will trägt id = ipv4:212.1.2.3 ein sofern die externe, öffentliche IP des Servers z.B. 212.1.2.3 lautet. (Siehe auch hier zu den Identity types)

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

Optionales Loopback Interface mit zweiter IP

Optional ist es hilfreich bei einem standalone Server ohne 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 nicht 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.24.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:
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 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, Apple und Linux VPN Clients

In der Regel sind bei Windows, Apple und allen Smartphones immer zwei oder auch mehr onboard Client VPN Apps 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, ohne Anpassung, muss in seinem o.a. Setup daher immer sicherstellen das SHA1 Hashing und DH Group 2 in den Phase 2 Proposals supportet sind!
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.
Das IKEv2 Tutorial für die pfSense / OPNsense Firewall zeigt diese 2 Settings ebenfalls um die aktuellen Defaults des Windows VPN onboard 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. Wie man das bei Bedarf anpassen kann wird weiter unten im Detail erklärt.
Apple gibt diese Parameter seit langem als Default vor. (z.B. AES256,SHA256,DH14)

❗️Wichtig bei ALLEN VPN Clients ist, daß immer vorher 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. Dieses Verfahren erhöht die Zugangssicherheit deutlich.
Der Zertifikats Import ist oben und im pfSense/OPNsense Tutorial umfassend für alle Clients und Betriebssysteme 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 via 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 VPN Clients ist über das GUI "Erstellen eines neuen VPN" einfach zu bewerkstelligen:

⚠️ Der Servername muss 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 muss 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 gesamte 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 optional 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:
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 auf 1 oder 2 setzen

Tabelle der DWORD Variablen Werte:
⚠️ Wer die Windows Registry so anpasst, veranlasst Windows immer 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. Alternativ klappt auch das Importieren über einen USB Stick.
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, praxisbezogenes Anwendungsbeispiel für dieses VPN Setup ist die Realisierung eines sog. "Jumphosts" für DS-Lite / CGNAT Internet Anschlüsse und auch Mobilfunkanschlüsse. Auf diese Netze unterbinden die Netzprovider üblicherweise den IPv4 Zugang aus externen Netzen.
DS-Lite Anschlüsse können, technisch bedingt, durch CG-NAT (v4 Adress Translation) 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 einer FritzBox. Es klappt außer mit der FritzBox natürlich auch mit jeden anderen VPN Routern oder Firewall die IPsec oder andere VPN Protokolle supporten.
Die zusätzliche Installation zusätzlicher VPN Protokolle (Wireguard, OVPN etc.) kann so einen vServer z.B. zu einem universellen VPN Access Server für DS-Lite / CGNAT Netze machen.
Ob man einen Provider Anschluss mit DS-Lite und CG-NAT hat, erkennt man am heimischen 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 VPN Zugang mietet man z.B. einen preiswerten vServer bei einem Hoster und lässt die heimische FritzBox aktiv ein VPN zu diesem vServer aufbauen um das heimische IPv4 Netzwerk so an den vServer per VPN 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 zum Heimnetz.

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

👉🏽 Tip:
Wer mehrere Fritzboxen bzw. andere VPN Router / Firewalls so anbindet kann der Übersicht halber die o.a. kombinierte, einzelne Konfig Datei in 2 separate Konfig Dateien trennen. Z.B. einmal client-vpn-server.conf und einmal fritzboxen.conf.
Damit hat man dann 2 separate Konfig Dateien die, je nach Geschmack, einfacher und deutlich übersichtlicher zu managen sind als eine große .conf Datei die alles macht.
Strongswan lädt beim Start automatisch alle einzelnen Konfig Dateien die sich im Verzeichnis ../conf.d/ befinden.

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

Mit dem Parameter ipaddr = 172.25.24.0; und der größeren /23 Subnetz Maske werden beide 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!
⚠️ AVM Firmware 8.0 supportet SHA512 nicht mehr mit DH Group2 sondern nur noch mit DH Group14 (2048). Tutorial ist darauf angepasst und supportet alle Firmware Versionen.)

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 nicht 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 nftables 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:
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 ohne 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:
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:

Weiterführende Links

Tutorial in 🇺🇸🇬🇧:
IKEv2 VPN server for Windows and Apple clients on Raspberry Pi

pfSense/OPNsense Zertifikats gesichertes IKEv2 VPN für mobile Benutzer mit bordeigener VPN Software:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Zertifikatserstellung mit Lets encrypt:
Strongswan Zertifikate

StrongSwan Kommando Doku:
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

Anfängerfehler beim IKEv2 Server Setup vermeiden:
vServer IKEv2 Setup
Fritzbox VPN Anbindung

Feste IP Adressen an mobile VPN User per Radius vergeben:
Feste IP Adressen für mobile VPN User

Mikrotik Router an Jumphost anbinden:
Mikrotik VPN Kopplung an Strongswan

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

Fallstricke und Tücken bei einer Jumphost Lösung mit Fritzbox Wireguard Anbindung beachten:
Fritzbox Wireguard VPN Besonderheiten und ihre Lösung

Ubuntu Server mit StrongSwan IPsec anbinden:
Strongswan Site-to-Site mit einer NIC

Troubleshooting Jumphost mit DS-Lite FritzBox:
Jumphost VPN (IPSec)
StrongSwan IPsec IKEv2 VPN Pingprobleme

Achtung bei Jumphost Tücken mit NAT und remotem Port Forwarding in den VPN Tunnel!
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP

FritzBox mit alter Strongswan Kommando Syntax verbinden:
VPN auf Dedicated Server

FritzBox mit Wireguard Server o. Router verbinden:
S2S-Wireguard: AVM zu Mikrotik

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

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

Grundlagen Raspberry Pi Setup:
Netzwerk Management Server mit Raspberry Pi

Einfaches LAN zu LAN VPN Setup mit FritzBox, Firewall und DDNS Adressen:
Routingprobleme über OpenVPN auf Fritzbox

Alternative Jumphost Lösungen im Forum:
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

OffTopic: Alternative bordeigenes L2TP VPN:
pfSense/OPNsense:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Mikrotik:
L2TP VPN Server mit Mikrotik
Linux StrongSwan:
Ubtuntu 20.10 mit UdmPro L2tp VPN Server verbinden bzw. mit GUI HIER.

      remote -> { <-
          auth = psk
          id = keyid:strongswan@fritz.box
          }

#!/usr/sbin/nft -f

flush ruleset

define pub_iface = "eth0"  

table inet drop-bad-ct-states {
	chain prerouting {
		type filter hook prerouting priority -150; policy accept;
		# Drop packets in "invalid" connection-tracking state 
		ct state invalid drop
		# Drop tcp packets for new connections that aren't SYN packets 
		tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
		# Drop XMAS packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
		# Drop NULL packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
		# Drop new connections over rate limit
		ct state new limit rate over 1/second burst 20 packets drop
		}
}

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		# Accept any localhost traffic
		iif lo accept

		# Accept traffic originated from us
		ct state established,related accept

		# Accepted ICMP types
		ip protocol icmp icmp type {time-exceeded, parameter-problem, destination-unreachable } accept

		# Accept common local TCP services on public interface
		iif $pub_iface tcp dport { ssh } ct state new accept

		# Accepted UDP ports on public interface 
		iif $pub_iface udp dport { isakmp, ipsec-nat-t  } accept 
		iif $pub_iface ip protocol esp accept 

		# Allow IPsec VPN networks
		meta ipsec exists accept

		# Accept IPv6 neighbour discovery otherwise IPv6 connectivity breaks.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

		# Count dropped traffic
		counter drop
	}
	chain forward {
		type filter hook forward priority 0;
	}
	chain output {
		type filter hook output priority 0;
	}
}

table ip nat {
        # Except VPN S2S router networks from NAT
        define VPN_NETS = {
        192.168.178.0/24, 192.168.11.0/24
        }
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
		oifname $pub_iface ip daddr $VPN_NETS accept
                ip saddr 172.25.25.0/28 oifname $pub_iface masquerade
        }
} 

 local {
         auth = pubkey
         certs = vServer.crt   <------ hier
         id = fqdn:<v_server_FQDN>
      }

TPM 2.0 - could not load "libtss2-tcti-tabrmd.so.0"  
plugin 'tpm': failed to load - tpm_plugin_create returned NULL  

sudo apt install libtss2-tcti-tabrmd0