Windows 11 verliert L2TP-IPsec Pre-Shared Key
Hallo zusammen,
ich habe heute einen neuen Windows 11 Pro Client installiert, dieser funktioniert soweit auch einwandfrei bis auf das integrierte VPN. Ich habe auch schon die Vermutung gehabt, dass irgendwas bei der Installation fehlgeschlagen ist, deshalb habe ich den auch nochmal neuinstalliert.
Ich möchte mich mit L2TP/IPsec zu einem VPN-Server verbinden, welcher einen Pre-Shared Key vergeben hat. Windows 11 nimmt den Pre-Shared Key an, aber sobald man die Eingabe des VPN mit Ok bestätigt ist der Pre-Shared Key weg. Als wäre da noch nie einer eingetragen gewesen.
Ich habe schon versucht per Powershell den VPN-Tunnel anzulegen nur leider mache ich da die gleiche Erfahrung. Der Pre-Shared Key ist nach der Eingabe wie vom Erdboden verschluckt.
Andere Clients haben dieses Problem nicht und somit schließe ich das Problem am VPN-Gateway aus.
Hat irgendwer eine Idee wie ich das integrierte VPN zum funktionieren bekomme?
Gruß Lukas
ich habe heute einen neuen Windows 11 Pro Client installiert, dieser funktioniert soweit auch einwandfrei bis auf das integrierte VPN. Ich habe auch schon die Vermutung gehabt, dass irgendwas bei der Installation fehlgeschlagen ist, deshalb habe ich den auch nochmal neuinstalliert.
Ich möchte mich mit L2TP/IPsec zu einem VPN-Server verbinden, welcher einen Pre-Shared Key vergeben hat. Windows 11 nimmt den Pre-Shared Key an, aber sobald man die Eingabe des VPN mit Ok bestätigt ist der Pre-Shared Key weg. Als wäre da noch nie einer eingetragen gewesen.
Ich habe schon versucht per Powershell den VPN-Tunnel anzulegen nur leider mache ich da die gleiche Erfahrung. Der Pre-Shared Key ist nach der Eingabe wie vom Erdboden verschluckt.
Andere Clients haben dieses Problem nicht und somit schließe ich das Problem am VPN-Gateway aus.
Hat irgendwer eine Idee wie ich das integrierte VPN zum funktionieren bekomme?
Gruß Lukas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6691285073
Url: https://administrator.de/forum/windows-11-verliert-l2tp-ipsec-pre-shared-key-6691285073.html
Ausgedruckt am: 25.12.2024 um 12:12 Uhr
46 Kommentare
Neuester Kommentar
Hätte erst neulich einen ähnlichen Fall.
Hier war das Profil des Users und der Credential-Store defekt. Neues Profil half bei diesem. Bei einem anderen waren Systemdateien beschädigt, hier half nur ein Refresh des Systems (sfc /scannow half hier leider nicht mehr).
Das aktuellste CU sollte natürlich drauf sein. Gab da ja Anfang 2022 mal ein Problem mit L2TP, aber das ist ja schon länger Geschichte.
Cheers briggs
Hier war das Profil des Users und der Credential-Store defekt. Neues Profil half bei diesem. Bei einem anderen waren Systemdateien beschädigt, hier half nur ein Refresh des Systems (sfc /scannow half hier leider nicht mehr).
Das aktuellste CU sollte natürlich drauf sein. Gab da ja Anfang 2022 mal ein Problem mit L2TP, aber das ist ja schon länger Geschichte.
Cheers briggs
Deaktiviere mal den Defender Credential Guard und Virtualization Based Security, die sind gerne mal für solche Credential Kuriositäten bei VPN Verbindungen verantwortlich.
Legst du die Verbindung auf User- oder Computerebene an?
Legst du die Verbindung auf User- oder Computerebene an?
Auch danach neu gestartet?
Das sollte man schon wissen auch wegen der nötigen UAC für Computerverbindungen 😉.
Gibt es GPOs? Domain-Member?
Legst du die Verbindung auf User- oder Computerebene an?
Ich würde sagen auf Computerebene, da die VPN-Verbindung für alle Benutzer zugänglich sein soll/war.Gibt es GPOs? Domain-Member?
Es muss ein Fehler dieses spezifischen Win 11 PCs sein.
Ein Test mit zwei verschiedenen 22H2 Win 11 Rechnern auf je ein Cisco L2TP und eins auf einer pfSense L2TP lief fehlerlos. Sowohl User Credentials als auch PSK bleibt auch nach Löschen und wieder Anlegen des VPN Profils gespeichert.
Ein Test mit zwei verschiedenen 22H2 Win 11 Rechnern auf je ein Cisco L2TP und eins auf einer pfSense L2TP lief fehlerlos. Sowohl User Credentials als auch PSK bleibt auch nach Löschen und wieder Anlegen des VPN Profils gespeichert.
Zitat von @aqui:
Es muss ein Fehler dieses spezifischen Win 11 PCs sein.
Ein Test mit zwei verschiedenen 22H2 Win 11 Rechnern auf ein Cisco L2TP und eins auf einer pfSense L2TP lief fehlerlos. Sowohl User Credentials als auch PSK bleibt auch nach Löschen und wieder Anlegen des VPN Profils gespeichert.
Dito auch hier bleibt der Key erhalten und übersteht auch einen Neustart problemlos.Es muss ein Fehler dieses spezifischen Win 11 PCs sein.
Ein Test mit zwei verschiedenen 22H2 Win 11 Rechnern auf ein Cisco L2TP und eins auf einer pfSense L2TP lief fehlerlos. Sowohl User Credentials als auch PSK bleibt auch nach Löschen und wieder Anlegen des VPN Profils gespeichert.
Da steht dann wohl ein OS-Refresh an .
Schaden kann es nicht.
Mach mal einen Mitschnitt mit ProcMon und schau was da abgeht während du versuchst zu speichern.
Könnt ihr denn ein neues VPN-Profil anlegen und da einen PSK eintragen? Das ist nämlich mein Problem.
Ja, eins oder mehrere kein Problem, nachträglich ändern ebenso kein Problem.Mach mal einen Mitschnitt mit ProcMon und schau was da abgeht während du versuchst zu speichern.
Könnt ihr denn ein neues VPN-Profil anlegen und da einen PSK eintragen?
Äähh, ja!Wie sollte man denn auch ein L2TP Profil vollständig anlegen OHNE den PSK, das ginge ja gar nicht!
Guckst du HIER für die genauen ToDos.
Du musst ja 2 Dinge im L2TP Client definieren:
- Den vorinstallierten Schlüssel (PSK)
- Die User Credentials mit Usernamen und Passwort. Hier kannst du wählen ob du die User Credentials (nicht den o.a. PSK sprich "vorinstallierten Schlüssel"!) individuell speichern willst (Der PSK wir immer gespeichert) oder ob die Userdaten bei jedem VPN Dialin neu eingegeben werden sollen. (Haken bei speichern). Als Dritte Variante kann man im L2TP Client eintragen ob man gleich automatisch den Windows Login User und Passwort verwenden möchte.
Das ist de facto ein Fehler deiner eigenen lokalen Win Installation! Wie gesagt alle Win 11 Rechner hier und die des Kollegen @6247018886 haben diese Problematik nicht. Auch ein eben schnell mal in einer VM installiertes, nacktes Win 11 von einem aktuellen Creation Tool USB Stick funktioniert völlig ohne irgendwelche Probleme.
Eigentlich können das ja nur Amok laufenden Gruppenregeln oder anderer Kram sein. Bei einem nackten, jungfräulichen Win 11 rennt das fehlerfrei.
Eigentlich können das ja nur Amok laufenden Gruppenregeln oder anderer Kram sein. Bei einem nackten, jungfräulichen Win 11 rennt das fehlerfrei.
Servus @lukas0209,
lass mal folgendes Powershell-Skript laufen (elevated für L2TP AllUsersConnections!) (im Kopf vorher noch den Verbindungsnamen und den Schlüssel anpassen) und poste hier mal welchen Return-Code das Skript zurückliefert.
Wenn
Grüße Uwe
lass mal folgendes Powershell-Skript laufen (elevated für L2TP AllUsersConnections!) (im Kopf vorher noch den Verbindungsnamen und den Schlüssel anpassen) und poste hier mal welchen Return-Code das Skript zurückliefert.
Wenn
0 (ERROR_SUCCESS)
zurückgegeben wird war das Setzen erfolgreich. Andernfalls poste den Code hier, eventuell bekommen wir hierdurch mehr Infos zum Fehler.# Name of connection
$ConnectionName = 'Test-L2TP'
# preshared key to set
$PresharedKey = 'SuperDuperGeheim'
# ------------------------------------------
Add-Type -Namespace ras -Name creds -MemberDefinition '
[StructLayout(LayoutKind.Sequential)]
public struct LPRASCREDENTIALSA
{
public int dwSize;
public int dwMask;
public String szUserName;
public String szPassword;
public String szDomain;
}
[DllImport("Rasapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] public static extern int RasSetCredentials(String paramFullPath, String paramName,LPRASCREDENTIALSA creds,bool clearCreds);
'
$creds = New-Object ras.creds+LPRASCREDENTIALSA
$creds.szPassword = $PresharedKey
$creds.dwMask = 0x10
$creds.dwSize = [System.Runtime.InteropServices.Marshal]::SizeOf($creds)
[ras.creds]::RasSetCredentials('C:\ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk',$ConnectionName,$creds,0)
Dann ist deine Verbindung keine Computer-Connection sondern eine User-Connection! Das Skript oben ist nur für AllUsersConnections zu benutzen. Die Benutzer-VPNs liegen stattdessen unter
%APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk
. Die Datei kannst du in einem Texteditor öffnen und schauen ob da deine Verbindung enthalten ist.Zitat von @lukas0209:
Hallo,
so ich habe nur ein Tippfehler in der VPN-Verbindung gehabt, dass Script ist ohne Fehler durchgelaufen.
Bedeutet welcher Return Code? 0? Den PSK Dialog danach kontrolliert ob dort Sternchen sichtbar sind?Hallo,
so ich habe nur ein Tippfehler in der VPN-Verbindung gehabt, dass Script ist ohne Fehler durchgelaufen.
Ich habe in die Computer-Connection "Datei" reingeschaut, da steht weiterhin nichts beim PSK drinnen!
Dort wird auch niemals ein PSK drin stehen!! Der PreSharedKey wird in einer verschlüsselten Datenstruktur außerhalb der Datei abgelegt und kann auch nur über die spezielle Win32-Funktion RasGetCredentials von einem Windows-Prozess abgefragt werden.Lass dir mal mit rsop.msc auflisten welche GPOs dort gezogen werden. Lege besonderen Wert auf Berechtigungs-Anpassungen und Registry-Werte.
Zitat von @lukas0209:
Ich habe jetzt nur das Problem das er sich trotzdem nicht mit dem VPN verbindet.
Fehler: Der L2TP-Verbindungsversuch ist fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotcomputer aufgetreten ist.
Das ist in der Regel ein Missmatch der Phase1 IPSec Crypto-Settings beider Seiten (Server/Client).Ich habe jetzt nur das Problem das er sich trotzdem nicht mit dem VPN verbindet.
Fehler: Der L2TP-Verbindungsversuch ist fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotcomputer aufgetreten ist.
Also entweder am Client eine Custom IPSec Policy an die Verbindung hängen (PowerShell) die auf die Phase 1 Policy der Server-Seite abgestimmt ist oder NAT-T ist bei dir der Schuldige und der
AssumeUDPEncapsulationContextOnSendRule
müsste helfen, siehehttps://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Grundlagen findest du hier in @aqui 's Anleitungen zu L2TPoIPSec.
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Frohe Ostern.
Grüße Uwe
Der L2TP-Verbindungsversuch ist fehlgeschlagen, da ein Verarbeitungsfehler während der ersten Sicherheitsaushandlung mit dem Remotcomputer aufgetreten ist.
Kollege @colinardo hat es schon gesagt. Dieser Fehler tritt in der Tat bei falschen Krypto Credentials deines VPN Servers auf. Siehe zusätzlich zu den o.a. Tutorials auch hier.Du musst hier aufpassen für die Tunnelsettings des IPsec IKEv1 Tunnels!!! Siehe auch Setup Hinweise in den o.a. L2TP Tutorials.
- In der Phase 1 immer AES 256 und ausschliesslich nur SHA1 Hashing einrichten mit DH Gruppe 2 (modp 1024) und 14 (modp 2048)
- Phase 2 nur AES 128 und SHA1. PFS muss ausgeschaltet sein.
Ich habe auch schon "Einfach" ausprobiert,
Zumindest "Mittel" ist falsch denn die dortigen DH Gruppen sind generell in keinem L2TP Client supportet. Supportet sind nur DH 2 (modp 1024) (Windows) und DH14 (modp 2048) (Apple)Ignore Phase1 SA proposals of DES/3DES/MD5/DH G1 G2/
Welcher Syslog?? Server oder Client? Bedeutet nur das die Phase 1 Proposals DES und 3DES und Hashing mit MD5 ignoriert wurden, was auch völlig normal ist, da L2TP Clients diese nicht verwenden.
Du hast also vermutlich wie oben schon mehrfach vermutet einen Mismatch in den angebotenen Krypto Verfahren des Servers.
Beachte auch das L2TP VPN kein reines IPsec ist, sondern immer eine Kombination aus IKEv1 (RFC 3193) und nativem L2TP. Nur die Produktivdaten werden in einem IPsec IKEv1 Tunnel mit PSK, (vorinstallierter Schlüssel) übertragen die gesamte User Authentisierung wird über MSCHAPv2 oder PAP gemacht.
Nur das du das mit auf dem Radar hast...?!
https://de.wikipedia.org/wiki/Layer_2_Tunneling_Protocol
Deswegen muss im Draytek Setup beides angehakt sein:
DES und 3 DES dürfen nicht aktiv sein!
Username und Passwort entsprechend eingerichtet werden
Der Windows Client ist entsprechend in den Security Settings, wie oben beschrieben, auf MS Chapv2 zu setzen.
AH aktivieren ist falsch!!!
AH kann man generell nicht über NAT (IP Adress Translation) übertragen und supportet zudem kein einziger L2TP Client!! Es muss immer ESP sein. Solche IPsec Banalitäten solltest du aber wissen...
Mit AH scheitert dein Tunnel generell sofort!
AH kann man generell nicht über NAT (IP Adress Translation) übertragen und supportet zudem kein einziger L2TP Client!! Es muss immer ESP sein. Solche IPsec Banalitäten solltest du aber wissen...
Mit AH scheitert dein Tunnel generell sofort!
ich habe schon einen neueren Draytek
OK, aber in der Remote Dialin User Verwaltung muss zwingend "L2TP mit IPsec Policy" angehakt sein und ein User muss eingerichtet sein mit Usernamen und Passwort.
Wie oben schon geschrieben passe halt einfach die IPSec Settings an die des Draytek auf Windows-Seite an wenn der Draytek-Kram sich nicht mehr detailliert konfigurieren lässt, dann lassen sich auch bessere Verfahren als die Crypto-Defaults von Windows nutzen.
Set-VPNConnectionIPSecConfiguration
Also bspw.
Siehe dazu auch
L2TP over IPsec from Windows 10 to Vigor Router
Ganz unten steht auch die Anpassung über die GUI welche aber im Gegensatz zur meiner oben genannten Powershell-Variante global für alle Verbindungen gilt.
Wenn es immer noch hakt, schau in die Anwendungs- und Dienstprotokolle (RAS Logs) im Eventviewer. Dort sollten mehr Informationen aufgelistet werden.
Zusätzlich kannst du das RAS-Logging aktivieren mittels
Dann die Verbindung herstellen und danach mittels
die Logs auf Platte "flushen".
Danach kannst du die Logs hier einsehen:
Set-VPNConnectionIPSecConfiguration
Also bspw.
Set-VpnConnectionIPsecConfiguration -ConnectionName "Draytek_L2TP" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -PfsGroup PFS2048 -DHGroup Group14 -IntegrityCheckMethod SHA256 -Force
Siehe dazu auch
L2TP over IPsec from Windows 10 to Vigor Router
Ganz unten steht auch die Anpassung über die GUI welche aber im Gegensatz zur meiner oben genannten Powershell-Variante global für alle Verbindungen gilt.
Wenn es immer noch hakt, schau in die Anwendungs- und Dienstprotokolle (RAS Logs) im Eventviewer. Dort sollten mehr Informationen aufgelistet werden.
Zusätzlich kannst du das RAS-Logging aktivieren mittels
netsh ras set tracing * enabled
Dann die Verbindung herstellen und danach mittels
netsh ras set tracing * disabled
die Logs auf Platte "flushen".
Danach kannst du die Logs hier einsehen:
C:\Windows\tracing