10.10.2024

1993

VPN auf 5G Fritzbox ohne IPv6

Hallo Zusammen,

ich habe hier eine Fritzbox 6850 5G über die Telekom am laufen.
Das hier vorhandene Netzwerk soll über einen VPN von außen erreichbar sein.
Die Standard-Vorgehensweise mit Fritzbox und Wireguard SSL VPN funktioniert nicht, da nur IPv4 und eingehende Verbindung über Mobilfunk wohl Grundsätzlich abgelehnt werden.

Gibt es hier noch andere Alternativen / Lösungen um die VPN Verbindung umzusetzen?
Darf Freeware oder auch Bezahldienste sein?

Vielen Dank vorab!
derinderinderin

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 668679

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

Ausgedruckt am: 23.11.2024 um 09:11 Uhr

28 Kommentare

Neuester Kommentar

Moin,

Mit dem aktuellsten FritzOS 7.59 fur die o.g. Fritte sollte das eigentlich auch über ipV6 funktionieren. Welche Fehlermeldungen kommen denn beim Client?

Ansonsten einen günstigen vServer irgendwo mieten und den als Zwischenstation nehmen, Inden Du sowohl von der Fritzbox als auch vom Client eine Verbindung dorthin aufbauen.

lks

Hi,
danke für deine Antwort.
Ich habe jetzt erst festgestellt, das ich IPv6 erst aktivieren musste.
IP zieht er sich nun auch. Allerdings ist jetzt noch die myfritz-Adresse, welche in den WireGuard Configs drin ist noch auf die IPv4 Adresse gemappt. bzw. diese spuckt der bei nem Ping aus.
Wie bekomme ich diese erneuert? oder dauert das einfach eine weile?

Gruß

Zitat von @derinderinderin:

Allerdings ist jetzt noch die myfritz-Adresse, welche in den WireGuard Configs drin ist noch auf die IPv4 Adresse gemappt. bzw. diese spuckt der bei nem Ping aus.

Für die Abendauflösung nimmt man nslookup, nicht Ping. Ping nimmt den Wert aus dem Cache.

Einfach Mal unter myfritz.net im myfritz-Konto schauen, ob beide Adressen Ei getragen sibd.

Wie bekomme ich diese erneuert? oder dauert das einfach eine weile?

Normalerweise sollte das Recht schnell gehen., aber warten hilft manchmal

lks

Gibt es hier noch andere Alternativen / Lösungen um die VPN Verbindung umzusetzen?

Ja, wie immer über einen vServer als sog. Jumphost.

Funktioniert auch mit Wireguard. IKEv2 hat aber den großen Vorteil das man nicht überflüssigerweise mit VPN Client Software rumfrickeln muss sondern immer die so oder so vorhandenen onboard VPN Clients in allen Geräten sinnvoll nutzt.
Das korrekte Kommando was der Kollege @Lochkartenstanzer oben meint ist nslookup oder noch besser host.

Zitat von @aqui:

Das korrekte Kommando was der Kollege @Lochkartenstanzer oben meint ist nslookup oder noch besser host.

Tippfehler korrigiert. Unter Windows funktioniert iirc kein host. Daher habe ich nur nslookup erwähnt. Unter BSD/linux nehme ich vorzugsweise dig.

lks

Danke euch, für eure hinweise.

IP ist eingetragen. Ebenfalls habe ich folgendes mit festen eingetragenen IPv6 Adresse in der Config probiert.

Also ich habe einen Client Laptop mit Internetverbindung (Hotspot). Der Wireguard Client sagt: "Verbindung hergestellt". Er vergibt auch eine IP-Adresse der Fritzbox. (kein Gateway).

Jedoch kann ich keine Netzwerkressource erreichen oder pingen.

Auf der Fritzbox erscheint auch kein Eintrag im Protokoll. Es wird auch keine aktive VPN Verbindung im Dashboard der Fritzbox angezeigt.

Müsste dann nicht der Wireguard Client meckern?

Gruß

Seit wann gibt es feste IPv6 Adressen im Mobilfunknetz?? 🤔
Merkzettel: VPN Installation mit Wireguard
Kapitel IPv6 Client und Fritzbox Besonderheiten.

Ohne das du deine Client Konfig Datei hier einmal (anonymisiert) postest kann man nur Kristallkugeln...

So oder so wird das aber sehr wahrscheinlich immer scheitern, weil Mobilfunk Provider in der Regel bei einfachen Consumer Verträgen keine Verbindung von außen auf ihre Mobilfunknetze erlauben. Egal ob v4 (scheitert schon am CGN) oder v6. Du kommst also um einen Jumphost nicht drumrum oder musst auf einen Business Vertrag wechseln sofern dein Provider sowas überhaupt anbietet.

Seit wann gibt es feste IPv6 Adressen im Mobilfunknetz?? 🤔

Er meinte sicher, daß er die v6-Adresse, die die Fritte erhält "fest" in die Config eingetragen hat. Ist natürlich klar, daß das nur bis zum nächsten Update der IP-Adresse hält.

lks

Für private Zwecke würde ich https://dynv6.com/ verwenden.
Spart man sich Zeit bei dynamischen IP Adressen, kostet nix und funktioniert recht gut mit den Fritten.
Habs seit Jahren zu Hause im Einsatz.

Zitat von @aqui:

Seit wann gibt es feste IPv6 Adressen im Mobilfunknetz?? 🤔
Merkzettel: VPN Installation mit Wireguard
Kapitel IPv6 Client und Fritzbox Besonderheiten.

Ohne das du deine Client Konfig Datei hier einmal (anonymisiert) postest kann man nur Kristallkugeln...

Genau wie Lochkartenstanzer sagt, ich hatte es temporär mal fix in die Config gespeichert, um einen Auflösung der Fritz Adresse mit V4 zu "verhindern".

Aber danke nochmal für die Hinweise, ich denke es wird genau daran liegen. ich werde mich dann mit dem Jumphost beschäftigen.

Vielen Dank an alle für die Antworten. Nach Abschluss werde ich hier nochmal berichten.

schönes Wochenende!

Wir sind gespannt...!

Wenn es das denn nun war bitte deinen Thread dann auch als erledigt markieren!
Wie kann ich einen Beitrag als gelöst markieren?

Hi, ich bin hier noch dran.
Es liegt auf jeden Fall daran, dass die Telekom in dem Vertrag eingehendes VPN nicht durchlässt.
Auch nachdem ich IPV6 Adressen habe.

Die Lösung mit dem Jump-Host ist mal nicht grad umgesetzt. Werde ich mich aber mit beschäftigen.
Ich kann den Thread auch vorerst mal als gelöst markieren.

Vielleicht noch eine Frage hinterher. Gibt es auch Dienstleister oder Services die als JumpHost fungieren? Quasi als fertige Lösung?

Gruß

dass die Telekom in dem Vertrag eingehendes VPN nicht durchlässt. Auch nachdem ich IPV6 Adressen habe.

Das macht, wie oben schon mehrfach gesagt, kein Mobilfunkprovider bei einfachen Consumer Verträgen. Eingehende Verbindungen auf Ziel IP Adressen im Mobilfunknetz werden in der Regel generell geblockt.

Die Lösung mit dem Jump-Host ist mal nicht grad umgesetzt.

Max. eine Stunde, dann ist das Teil online... Wo ist dein wirkliches Problem?!

Die Lösung mit dem Jump-Host ist mal nicht grad umgesetzt.

Max. eine Stunde, dann ist das Teil online... Wo ist dein wirkliches Problem?!

Das eigentliche Problem ist gerade meine Zeit

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

Ich würde einen StrongSwan Server mal aufsetzten. Gibt es Empfehlungen welche vServer (Anbieter) man nimmt, sodass man an alle nötigen Konfigurationen dran kommt? (auch Preis / Leistung )
Könnte man auf dem StrongSwan auch VPN Server für zwei verschiedene Netze erstellen?

Gruß

Gibt es Empfehlungen welche vServer (Anbieter) man nimmt

Nee, ist völlig Wumpe. Das kannst du nach Geschmack und Geldbeutel entscheiden.

Könnte man auf dem StrongSwan auch VPN Server für zwei verschiedene Netze erstellen?

Na klar! Das ist doch genau der Witz der Sache das man da auch mehrere Netze /Router anbinden kann. Auch andere VPN Protokolle. So kannst du dir quasi einen universellen VPN Server stricken der alles mit allem verbinden kann. Also...einfach mal loslegen und machen! 😉

So, Server ist mit geringen eigenen Anpassungen aufgesetzt.
Server hat die Konfigs auch geladen etc.
Jetzt sagt mir nur die WIN 11 VPN Verbindung "Fehler in Richtlinienübereinstimmung".
Woran kann das liegen?

über swanctl -T auf dem Server sieht man nichts eingehen.

edit:
den Registry Eintrag von hier:
https://docs.strongswan.org/docs/5.9/interop/windowsClients.html
habe ich bereits hinzugefügt.

Gruß

Jetzt sagt mir nur die WIN 11 VPN Verbindung "Fehler in Richtlinienübereinstimmung".

Zertifikate hast du für die Server IP und ggf. DNS Hostnamen erstellt und auch entsprechend auf den Win 11 Rechner übertragen?

über swanctl -T auf dem Server sieht man nichts eingehen.

Oha, das darf natürlich nicht sein. Das bedeutet das schon überhaupt gar kein VPN Traffic auf deinem vServer ankommt.

Ist am vServer ggf. noch eine Firewall aktiv die solchen Traffic blockt?!

Hast du dort als Ziel IP des VPN Clients einmal die nackte IP Adresse des Servers eingetragen?
Wenn ja was sagt ein tcpdump port 500 (apt install tcpdump)Kannst du damit eingehende UDP 500 (IKE) Pakete des VPN Clients sehen?

Da du leider keinerlei zielführende Infos hier gepostet hast wird das eine wilde Raterei. Das Allerwichtigste ist erstmal das du hier deine Strongswan Konfig Datei einmal anonymisierst postest. Idealerweise in Code Tags. Das dient dazu zu checken ob du generell ggf. einen Fehler im Setup gemacht hast.
Sehr hilfreich wäre auch der Output von swanctl -q um ggf. Fehlermeldungen dort zu sehen. Auch ob ein Neistart des Strongswan Dienstes mit systemctl restart strongswan fehlerlos durchläuft. systemctl status strongswan sollte den Dienst als Aktiv anzeigen.

den Registry Eintrag von hier:

Das ist Blödsinn und sollte man erstmal NICHT machen!! Es ist völlig unnötig und verkompliziert das Troubleshooting nur. Belasse alles out of the box. Optimieren macht man logischerweise immer nur NACHDEM alles rennt wie es soll und nicht vorher.
Wichtig ist jetzt erstmal herauszubekommen warum swanctl -T oder tcpdump keine eingehenden VPN Daten vom Client anzeigt?!

Also die Konfig sieht so aus:
(id xxx durch IP ersetzt sowie andere Pw)

connections {
  ikev2-mobile-defaults {
     unique = replace
     version = 2
     proposals = aes256-sha512-modp2048,aes256-sha256-ecp256,aes256-sha256-modp>
     send_cert = always
     pools = pool-ipv4
     local_addrs = 192.168.180.1
     remote_addrs = 0.0.0.0/0,::/0
         local {
         auth = pubkey
         certs = server-cert.pem
         id = xxx.xxx.xxx.xxx
         }
         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
       }
     }
  }
}
pools {
  pool-ipv4 {
    addrs = 192.168.180.0/24
    dns = 9.9.9.9
    }
  }
secrets {
 eap-1 {
     id = user
     secret = "meinpw#"  
     }
 eap-2 {
     id = user2
     secret = "meinpw2"  
     }
}

Der Status sagt:

Oct 22 11:21:17 ubuntu swanctl[3246]: loaded private key from '/etc/swanctl/private/server-key.pem'  
Oct 22 11:21:17 ubuntu swanctl[3246]: loaded eap secret 'eap-1'  
Oct 22 11:21:17 ubuntu swanctl[3246]: loaded eap secret 'eap-2'  
Oct 22 11:21:17 ubuntu swanctl[3246]: no authorities found, 0 unloaded
Oct 22 11:21:17 ubuntu swanctl[3246]: loaded pool 'pool-ipv4'  
Oct 22 11:21:17 ubuntu swanctl[3246]: successfully loaded 1 pools, 0 unloaded
Oct 22 11:21:17 ubuntu swanctl[3246]: loaded connection 'ikev2-mobile-defaults'  
Oct 22 11:21:17 ubuntu swanctl[3246]: successfully loaded 1 connections, 0 unloaded
Oct 22 11:21:17 ubuntu systemd[1]: Started strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.

Bei tcpdump port 500 reagiert das Terminal. Also es sind eingehende Pakete zu sehen.

Bei swanclt -T reagiert er gar nicht.

Es kann durchaus sein, dass ich ggf. ein Fehler beim Zertifikat gemacht habe. Importiert habe ich es. Allerdings sehe ich da nirgends die IP des VServers.

Vielen Dank schon mal für deine Mühe und Geduld

Habe die Zertifikate auch nochmal neu erstellt:

Zur Vollständigkeit: 111.111.111.1111 ersetzt durch korrekte IP.

Über die Kommandos:

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/raspica-key.pem

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

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/server-key.pem

pki --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=111.111.111.111" --san 111.111.111.111 --flag serverAuth --flag ikeIntermediate --outform pem > /etc/swanctl/x509/server-cert.pem

raspica-key.pem habe ich dann als Zertifikat importiert.

Fehlermeldung wie bisher.

OK, das sieht soweit schon mal ganz gut aus. Sowas wie ".1111" als Hostadresse gibt es natürlich nicht was du auch selber weisst und wohl die Folge eines nervösen Tippfingers ist?!!

Einige Dinge sind aber auffällig und solltest du unbedingt korrigieren:

Die "Proposals" sind unvollständig und haben am Ende ein falsches ">" was normal zu einem Fehler führt.
local_addrs = 192.168.180.1 ist falsch, denn dort darf natürlich KEINE private RFC1918 IP stehen. Hier muss die öffentliche, externe IP des vServers stehen z.B. 212.1.2.3. (Dein 111.111.111.111) Die ist hier mit "local_addrs" gemeint! Sie darf damit auch keinesfalls eine Adresse aus dem VPN Client IPv4 Pool sein! Dieser gravierende Fehler führt zum Scheitern deiner VPN Verbindung. Achte darauf das das .180.0er VPN Client Pool IP Netz einzigartig bei dir ist! Dieses Netz darf nirgendwo sonst verwendet werden! (Siehe dazu auch hier zum Thema VPN Adressdesign).
Bei der lokalen ID wenn du dort statt eines FQDNs die feste vServer IP angibst (siehe auch oben, entspricht deiner "111.111.111.111") sollte die Syntax korrekt z.B. id = ipv4:212.1.2.3 lauten. (Siehe auch hier zu den Identity types)

So sähe das dann auszugsweise aus wenn es richtig ist:

connections {
  ikev2-mobile-defaults {
     unique = replace
     version = 2
     proposals = aes256-sha512-modp2048,aes256-sha256-ecp256,aes256-sha256-modp2048,aes256-sha256-modp1024
     send_cert = always
     pools = pool-ipv4
     local_addrs = 212.1.2.3
     remote_addrs = 0.0.0.0/0,::/0
         local {
         auth = pubkey
         certs = server-cert.pem
         id = ipv4:212.1.2.3
         } 

Der Rest ist soweit korrekt.
Den Fehler mit der lokalen Adresse und der falschen IP bzw. ID musst du zwingend korrigieren. Deshalb scheitert die Verbindung und das ist auch der Grund weil swanctl -T keinen Output zeigt weil durch die falsche ID der VPN Tunnel sofort abgebrochen wird!!
Wenn ein Fehler im Zertifikat sein sollte würde der -T Trace das auch zeigen. Eine alternative Methode mit OpenSSL findet man u.a. hier.
Hast du alles richtig gemacht sollte der Trace sowas wie das Folgende zeigen:

root@vserver:/home/admin# swanctl -T
06[NET] received packet: from 91.3.4.5[513] to 212.1.2.3[500] (356 bytes)
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
06[IKE] 91.3.4.5 is initiating an IKE_SA
06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
06[IKE] remote host is behind NAT
06[IKE] sending cert request for "CN=internal-ca, C=DE, ST=M, L=M, O=Private, OU=Homevpn"  
... 
15[IKE] assigning virtual IP 192.168.180.2 to peer 'user2'  

Puh also, ich dachte schon mit der IP, das wars... leider immer noch keine Verbindung.
Im Anwendungsprotokoll von Windows erscheint:

CoID={42CFC0C3-2465-0003-132D-DB426524DB01}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "VPN" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 13868.  

Ich habe eine weitere VPN Verbindung über Powershell angelegt.
https://learn.microsoft.com/en-us/powershell/module/vpnclient/set-vpncon ...

gleiches Ergebnis

Wenn du Bock hast, würde ich nochmal alles zusammengefasst mit allen ständen per PN übermitteln. Kann ja wohl nicht mehr viel sein

Ok, jetzt mal alles von Vorne mit allen gegebenheiten.
Zum Anonymisieren habe ich die PublicIP also die IP meines Servers wie folgt hier angegeben:
212.212.212.212

1. Server
ist ein vServer von Strato - Installiert ist Ubuntu mit Plesk
Es gibt hier eine Firewall welche aktiviert wird. Für den Verbindungsaufbau habe ich erstmal eine Whitelist für alles erstellt.

2. Zertifikate
Zertifikate habe ich nach Anleitung erstellt.

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/raspica-key.pem

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

Ausgegebenes Zertifikate liegen unter:

/etc/swanctl/x509ca/ (raspica-cert.pem)

das exportierte Zertifikat sieht dann so aus.

welches hier importiert ist:

Server Zertifikate wie folgt erstellt:

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/server-key.pem

pki --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=212.212.212.212" --san 212.212.212.212 --flag serverAuth --flag ikeIntermediate --outform pem > /etc/swanctl/x509/server-cert.pem    

ausgegebenes Zertifikat liegt unter:

/etc/swanctl/x509 (server-cert.pem)

3 Strongswan

Die Konfig sieht wie folgt aus:

connections {
  ikev2-mobile-defaults {
     unique = replace
     version = 2
     proposals = aes256-sha512-modp2048,aes256-sha256-ecp256,aes256-sha256-modp2048,aes256-sha256-modp1024
     send_cert = always
     pools = pool-ipv4
     local_addrs = 212.212.212.212
     remote_addrs = 0.0.0.0/0,::/0
         local {
         auth = pubkey
         certs = server-cert.pem
         id = ipv4:212.212.212.212
         }
         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
       }
     }
  }
}
pools {
  pool-ipv4 {
    addrs = 192.168.180.0/24
    dns = 9.9.9.9
    }
  }
secrets {
 eap-1 {
     id = user
     secret = "Passwort1"  
     }
 eap-2 {
     id = user2
     secret = "Passwort2"  
     }
}

"swanctl -T" zeigt:

 
strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
     Loaded: loaded (/usr/lib/systemd/system/strongswan.service; enabled; preset: enabled)
     Active: active (running) since Tue 2024-10-22 13:07:26 UTC; 16h ago
    Process: 1983 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
   Main PID: 1959 (charon-systemd)
     Status: "charon-systemd running, strongSwan 5.9.13, Linux 6.8.0-47-generic, x86_64"  
      Tasks: 17 (limit: 4600)
     Memory: 4.7M (peak: 7.7M)
        CPU: 6.168s
     CGroup: /system.slice/strongswan.service
             └─1959 /usr/sbin/charon-systemd

Oct 22 13:07:26 ubuntu swanctl[1983]: loaded private key from '/etc/swanctl/private/raspica-key.pem'  
Oct 22 13:07:26 ubuntu swanctl[1983]: loaded private key from '/etc/swanctl/private/server-key.pem'  
Oct 22 13:07:26 ubuntu swanctl[1983]: loaded eap secret 'eap-1'  
Oct 22 13:07:26 ubuntu swanctl[1983]: loaded eap secret 'eap-2'  
Oct 22 13:07:26 ubuntu swanctl[1983]: no authorities found, 0 unloaded
Oct 22 13:07:26 ubuntu swanctl[1983]: loaded pool 'pool-ipv4'  
Oct 22 13:07:26 ubuntu swanctl[1983]: successfully loaded 1 pools, 0 unloaded
Oct 22 13:07:26 ubuntu swanctl[1983]: loaded connection 'ikev2-mobile-defaults'  
Oct 22 13:07:26 ubuntu swanctl[1983]: successfully loaded 1 connections, 0 unloaded
Oct 22 13:07:26 ubuntu systemd[1]: Started strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon us>

4 VPN Verbindung

VPN Verbindung Windows 11

Beim Verbinden erscheint:

im Windows Log steht:
CoID={42CFC0C3-2465-0003-132D-DB426524DB01}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "VPN" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 13868.

Auf dem Swanserver zeigt nur der "tcpdump port 500" eine Reaktion beim Verbinden.
swanctl -T zeigt keinerlei Anfragen/Pakete

Ich denke immer noch Richtung Zertifikat? die Anfrage scheint bei Strongswan ja nicht anzukommen.

Gruß

Der durch den Fehler zurückgegebene Ursachencode lautet: 13868.

Das weist auf einen IPsec Security Policy Mismatch hin.

Bedeutet das das was der VPN Client an Krypto Policies fordert der Server nicht liefern kann oder vice versa und die automatische Aushandlung der Policies damit scheitert.
https://directaccess.richardhicks.com/2023/02/12/always-on-vpn-error-138 ....
Ist sicher eine Folge deiner Manipulation der Registry.
Müsste man jetzt nochmal genau checken welche Policies die Registry damit dann jetzt auf deinem Client erfordert. Ein Get-VpnServerIPsecConfiguration in der PS würde das klären so das man das auf dem Server im Strongswan Setup ergänzen kann.

"swanctl -T" zeigt:

Nein, das ist leider KEIN Output von swanctl -T sondern eine Kombination von systemctl status strongswan und swanctl -q aber leider keinerlei hilfreicher Output von einem Trace mit swanctl -T
Den erreichst du nur wenn du den Trace mit swanctl -T auf dem Server startest und DANACH einen Verbindungsversuch mit dem VPN Client startest. Dann sollte sowas wie das hier zu sehen sein

root@vserver:/home/admin# swanctl -T
06[NET] received packet: from 91.3.4.5[513] to 212.1.2.3[500] (356 bytes)
06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
06[IKE] 91.3.4.5 is initiating an IKE_SA
06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
06[IKE] remote host is behind NAT
06[IKE] sending cert request for "CN=internal-ca, C=DE, ST=M, L=M, O=Private, OU=Homevpn"    
... 
15[IKE] assigning virtual IP 192.168.180.2 to peer 'user2'    

Real sind die Messages viel mehr und zeigen detailiert was auf dem VPN Server bei einer Client Einwahl passiert.
Mit "selected proposal:" kannst du die o.g. mit dem VPN Client ausgehandelten Krypto Proposals sehen.

Dein weiterer Fehler ist das du einen völlig falschen Usernamen verwendest!!

Du hast oben definiert:

 eap-2 {
     id = user2
     secret = "Passwort2"    
     } 

Also der Username ist laut Konfig dann user2 (user id) und das zum User dazugehörige Passwort Passwort2 (secret)! Stattdessen aber hast du als Usernamen im Client Setup fälschlicherweise die Indexierung der User verwendet.

Das das dann in die Hose geht ist auch klar. Viel zu korrigieren mal wieder...

Ok das mit dem User war natürlich sau blöd. Hatte das aus dem Beispiel falsch verstanden. Ist korrigiert.

Auch die Angabe, was swanctl -T anzeigt war falsch Positioniert. Du hast natürlich recht.
swanctl -T zeigt keine aktivität bei einem Versuch. Nur tcp dump.

Die Änderung an der Registry hatte ich nach deinem Hinweis direkt wieder rückgängig gemacht.
Der DWORD Eintrag ist gelöscht.

Aus dem Artikel habe ich Get-VpnServerIPsecConfiguration versucht, bezieht sich aber auf den Server.

Ich habe testweise 2 VPN Verbindungen. Einmal über die GUI erstellt und einmal über eine Powershell.

Der Befehl für den Client:

Get-VpnConnection -Name "VPN-Jumphost"  | Select-Object -ExpandProperty IPsecCustomPolicy  

Zeigt keine Ergebnisse.
Dazu steht im Artikel:
If this PowerShell command returns no output, the VPN connection is not using a custom IKEv2 IPsec security policy.

Die von der Powershell erstelle VPN Verbindung zeigt.

AuthenticationTransformConstants : None
CipherTransformConstants         : AES256
DHGroup                          : ECP384
IntegrityCheckMethod             : SHA384
PfsGroup                         : None
EncryptionMethod                 : AES256

Beide ergeben den gleichen Fehler.

Ich habe mir die anderen Logeinträge mal angeguckt.

Es kommt:

CoID={55F22E70-2489-0000-B7C4-13568924DB01}: Der Benutzer "SYSTEM" hat eine VPN-Verbindung mit einem per-user-Verbindungsprofil mit dem Namen "VPN-Jumphost" angewählt. Die Verbindungseinstellungen lauten:   
Dial-in User = user
VpnStrategy = IKEv2
DataEncryption = Requested
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = EAP <Microsoft: Gesichertes Kennwort (EAP-MSCHAP v2)>
Ipv4DefaultGateway = Yes
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = 
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No
Mobility enabled for IKEv2 = Yes.

CoID={55F22E70-2489-0000-B7C4-13568924DB01}: Der Benutzer "SYSTEM" versucht, eine Verbindung zum RAS-Server für die Verbindung mit dem Namen "VPN-Jumphost" mit dem folgenden Gerät herzustellen:   
Server address/Phone Number = 212.212.212.212
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN.

CoID={55F22E70-2489-0000-B7C4-13568924DB01}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem RAS-Server hergestellt, verwendet wurde das Gerät: "  
Server address/Phone Number = 212.212.212.212
Device = WAN Miniport (IKEv2)
Port = VPN2-1
MediaType = VPN".  


CoID={55F22E70-2489-0000-B7C4-13568924DB01}: Die Verbindung mit dem RAS-Server wurde von Benutzer "SYSTEM" hergestellt.  

VPN-Jumphost erfordert einen Benutzereingriff.

CoID={55F22E70-2489-0000-B7C4-13568924DB01}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "VPN-Jumphost" gewählt, die Verbindung konnte jedoch nicht hergestellt werden. Der durch den Fehler zurückgegebene Ursachencode lautet: 13868.  

Hilft das vielleicht weiter?

Noch eine Frage hinterher.
Beim vServer ist noch kein SSL Zertifikat hinterlegt. Hat das eine Relevanz?

OK, sha384 und DH Group ecp384 bietet der Server mit der Tutorial Konfig nicht an. Verwunderlich das das ausgegeben wird, denn Win11 verwendet gleiche IKEv2 Proposals wie Win 10. 🤔
Wenn das das Einzige ist was diese (Powershell) Verbindung erfordert musst du die Proposals um den Eintrag aes256-sha384-ecp384 erweitern ansonsten scheitert sofort die Proposal Negotiation.
Denke daran das du bei jeder Änderung der Konfig Datei ein swanctl -q oder systemctl restart strongswan ausführst um diese zu aktivieren!

Interessant wäre wenn du parallel auch einmal eine fritte6850.conf Datei erzeugst mit deiner 6850 Fritzbox Konfig. Dann könntest du parallel mal checken wie sich die FB mit der VPN Connectivity auf dem vServer schlägt.
Die folgende Konfig geht davon aus das du das Loopback Interface des vServers mit

# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet static
address 192.168.181.1
netmask 255.255.255.255 

zusätzlich auf 192.168.181.1 gesetzt hast so das du in den IPsec Phase 2 Settings beide Netze .180.0/24 = VPN Clientnetz und .181.0/24 = Keepalive Netz bzw. IP mit einer /23 Maske (255.255.254.0) per VPN bedienen kannst!

⚠️ Die Wahl des 192.168.180.0/24er Netzes fürs Client VPN war insgesamt wenig intelligent, denn genau dieses Netzwerk wird intern von AVM in den Fritzboxen verwendet und fällt damit in einer Netzwerkkonfiguration wie deiner grundsätzlich aus bzw. ist im Fritzbox Umfeld dann generell Tabu!! Als Fritzbox Knecht sollte man solche Basics eigentlich wissen.

http://help.avm.de/fritzbox.php?oem=1und1&hardware=94&language= ...
Zitat: "Das gesamte IP-Netzwerk 192.168.180.0 ist für interne Zwecke reserviert. Das heißt, die IP-Adressen 192.168.180.1 bis 192.168.180.255 sind nicht verfügbar!"
Deshalb gilt das Folgende hier nur für eine Blaupause und man kann dir nur dringenst raten ein anderes, nicht benutztes IP Netz für VPN Clients und Keepalive zu verwenden wenn du nicht noch mehr Frust erleben willst!!! Der RFC 1918 IP Adressbereich hat ja genug freie Spielwiesen dafür. (Siehe zu der Thematik auch hier!)

connections {
   fritzbox {
      local_addrs = 212.212.212.212
      remote_addrs = 0.0.0.0/0
      local {
          auth = psk
          id = 212.212.212.212
          }
      remote {
          auth = psk
          id = keyid:6850@fritz.box
          }
      children {
          net {
              local_ts = 192.168.180.0/23
              remote_ts = 192.168.178.0/24
              esp_proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha1-modp1024
              }
          }
       version = 1
       proposals = aes256-sha512-modp2048,aes256-sha512-modp1024
   }

secrets {
 ike-1 {
      id = keyid:6850@fritz.box
      secret = "test1234"    
     }
} 

Deine in deine 6850 FB zu importierende Datei sieht dann so aus:

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 = 212.212.212.212;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 192.168.181.1;
			localid {
                        key_id = "6850@fritz.box";    
                        }
                        remoteid {
                        ipaddr = 212.212.212.212;
                        }
                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 = 192.168.180.0;
                                mask = 255.255.254.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";    
                accesslist = "permit ip any 192.168.180.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";    
} 

LAN IP, Loopback Netz und IP des vServers und Passwörter musst du natürlich anpassen auf deine Belange! Obiges scheitert vermutlich eh wegen der falschen .180.0er Wahl für die VPN Client IPs.

Man kann das VPN auch ganz einfach per KlickiBunti über das GUI der Fritzbox konfigurieren allerdings nutzt sie dann den sog. Agressive Mode im Default statt des Main Modes der oben konfiguriert ist (mode = phase1_mode_idp;).
Der Agressive Mode ist im Default Setting des Strongswan Servers deaktiviert. (Siehe zu der Thematik hier) Den Main Mode kann man nur über eine zu importierende VPN Setup Datei wie oben in der Fritte setzen.
Oder eben den Agressive Mode auch im Strongswan erlauben dann klappts auch mit der Fritte im Agressive Mode.

Beim vServer ist noch kein SSL Zertifikat hinterlegt. Hat das eine Relevanz?

Nein! Da SSL hier keinerlei Rolle spielt ist das komplett irrelevant.