Always On VPN bleibt bei „Verbindung wird hergestellt“ hängen oder verbindet sich nach einem Abbruch nicht mehr? Wenn das nach einem Windows-Update angefangen hat, lohnt sich ein Blick auf die automatische Protokollauswahl. Daneben gibt es seit dem Oktober-Update eine Änderung bei älteren Anmeldeverfahren. Ähnliches Symptom, unterschiedliche Baustelle.

Stand: 23. Oktober 2026. Die Anleitung richtet sich an den integrierten Windows-VPN-Client in Unternehmensumgebungen. Sie ist keine allgemeine Reparaturanleitung für WireGuard, OpenVPN oder beliebige VPN-Apps. Änderungen an verwalteten Firmenprofilen gehören in die Hände der zuständigen IT.

Kurzlösung

  • Prüfe Windows-Version, Updateverlauf und den Tunneltyp deines VPN-Profils.
  • Steht der Tunneltyp auf Automatic, teste mit der IT ein einzelnes, vom Gateway unterstütztes Protokoll: IKEv2 oder SSTP.
  • Scheitert seit Oktober nur die automatische Anmeldung, prüfe zusätzlich das NTLM-Protokoll auf Ereignis 4025.
  • Der am 13. Oktober zunächst angekündigte VPN-Fix ist keine bestätigte Lösung: Microsoft hat die Angabe am 20. Oktober zurückgezogen.

Direkt zur Profilprüfung und den Befehlen

Warum das Oktober-Update allein nicht genügt

Microsoft beschrieb zunächst eine Korrektur für VPN-Verbindungen, die bei automatischer Protokollauswahl oder beim Wechsel auf ein Ersatzprotokoll hängen bleiben. Die ältere Ankündigung ist im Windows Message Center noch zu finden. Entscheidend ist inzwischen der neuere Änderungsverlauf:

In den Release Notes zu KB5127648 steht unter dem 20. Oktober 2026, dass die Angabe zum Always-On-VPN-Fix entfernt wurde und die Änderung erst in einer künftigen Veröffentlichung enthalten sein soll. Verlass dich deshalb nicht auf ältere Meldungen, die den Fehler bereits als behoben darstellen. Einen verbindlichen Termin nennt dieser Hinweis nicht.

Aktuelle Sicherheitsupdates bleiben sinnvoll. Nur die Schlussfolgerung „Oktober-Patch installiert, also muss VPN wieder funktionieren“ passt hier nicht. Ein installierter Patch ist schließlich noch kein Verbindungstest.

Windows-Stand und VPN-Profil prüfen

Öffne mit Windows-Taste + R den Ausführen-Dialog und gib winver ein. Notiere Version und Betriebssystembuild. Unter Einstellungen → Windows Update → Updateverlauf siehst du, welche Updates wann installiert wurden. Halte auch fest, seit wann das Problem auftritt.

Öffne anschließend Windows PowerShell im Konto des betroffenen Benutzers. Diese Abfrage liest die Benutzerprofile aus:

PowerShell
Get-VpnConnection |
    Select-Object Name, ServerAddress, TunnelType,
        AuthenticationMethod, ConnectionStatus, AllUserConnection |
    Format-List

Für systemweit angelegte Verbindungen verwende zusätzlich eine administrative Windows PowerShell und diese Variante:

PowerShell
Get-VpnConnection -AllUserConnection |
    Select-Object Name, ServerAddress, TunnelType,
        AuthenticationMethod, ConnectionStatus, AllUserConnection |
    Format-List

Achte auf TunnelType und den genauen Profilnamen. Automatic ist ein Ansatzpunkt, aber kein Beweis für den Updatefehler. Die beiden Abfragen lesen unterschiedliche Telefonbücher; ein leeres Ergebnis in der ersten Abfrage bedeutet nicht, dass kein VPN eingerichtet ist. Microsoft dokumentiert das bei Get-VpnConnection.

Hinweis zu verwalteten Profilen

Bei Intune- oder anderweitig zentral bereitgestellten Profilen kann eine lokale Änderung später überschrieben werden. Stimme den Test mit der IT ab und dokumentiere den Ausgangszustand. Ein Gerätetunnel ist außerdem gesondert zu betrachten; die folgenden Benutzerprofil-Beispiele sind dafür keine pauschale Vorlage.

Den Fehler mit Uhrzeit und Ereignisprotokoll eingrenzen

Starte einen Verbindungsversuch und notiere die Uhrzeit sowie die vollständige Meldung. Öffne danach die Ereignisanzeige unter Windows-Protokolle → Anwendung und suche nach der Quelle RasClient. Microsoft empfiehlt diese Einträge für die Always-On-VPN-Fehlersuche; bei Anmeldeproblemen kommen die NPS-Protokolle auf dem Server hinzu.

Mit dieser Abfrage liest du bis zu 20 RasClient-Ereignisse der letzten Stunde aus:

PowerShell
Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    ProviderName = 'RasClient'
    StartTime = (Get-Date).AddHours(-1)
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, Message |
    Format-List

Die Abfrage verändert nichts. „Keine Ereignisse gefunden“ bedeutet nur, dass zum Filter nichts vorliegt. Prüfe dann Zeitraum, verwendeten Client und das Protokoll direkt. Die Filterparameter beschreibt Microsoft bei Get-WinEvent.

Ordne das Ergebnis ein: Hängt der Aufbau? Wird die Anmeldung abgelehnt? Oder steht der Tunnel bereits, während nur interne Dienste fehlen? Diese Unterscheidung entscheidet darüber, ob du am Protokoll, an der Authentifizierung oder an DNS und Routing weiterarbeiten solltest.

Ein unterstütztes VPN-Protokoll gezielt festlegen

Für ein Profil mit automatischer Auswahl kannst du ein bekannt funktionierendes Protokoll gezielt vorgeben. Microsoft nennt das Festlegen des passenden Tunneltyps auch in seiner allgemeinen VPN-Fehlersuche. Voraussetzung: Gateway, Netzwerk und Profil unterstützen dieses Protokoll.

Trenne die Verbindung. Ersetze Firmen-VPN durch den tatsächlichen Namen. Für ein Benutzerprofil mit freigegebenem IKEv2-Zugang:

PowerShell
Set-VpnConnection -Name "Firmen-VPN" -TunnelType Ikev2 -PassThru

Ist stattdessen SSTP vorgesehen, führe nur diese Alternative aus:

PowerShell
Set-VpnConnection -Name "Firmen-VPN" -TunnelType Sstp -PassThru

Bei einem systemweiten Profil benötigst du Administratorrechte und -AllUserConnection, beispielsweise:

PowerShell
Set-VpnConnection -Name "Firmen-VPN" -AllUserConnection -TunnelType Ikev2 -PassThru

War vorher Automatic eingestellt, lässt sich diese einzelne Änderung so zurücknehmen:

PowerShell
Set-VpnConnection -Name "Firmen-VPN" -TunnelType Automatic -PassThru

Für die systemweite Variante beim Zurückstellen ebenfalls -AllUserConnection ergänzen. Andere vorherige Tunneltypen stellst du auf ihren dokumentierten Ausgangswert zurück. Parameter und zulässige Werte stehen bei Set-VpnConnection.

Vor dem Umstellen

Die Umstellung kann deine einzige Verbindung zum Firmennetz unterbrechen. Sorge für einen unabhängigen Supportweg. Sie entfernt außerdem den automatischen Wechsel zwischen Protokollen. Ändere dabei weder Zertifikatsprüfung noch Verschlüsselung oder Authentifizierung.

Anmeldefehler seit Oktober separat untersuchen

Seit dem 13. Oktober 2026 blockiert Windows unter bestimmten Voraussetzungen die Erzeugung von NTLMv1-abgeleiteten SSO-Anmeldedaten. Betroffen sein können MS-CHAPv2-basierte Verbindungen, wenn Credential Guard deaktiviert und BlockNtlmv1SSO nicht gesetzt ist. Das ist eine geplante Sicherheitshärtung und vom Protokollproblem zu unterscheiden.

Prüfe das Protokoll Anwendungs- und Dienstprotokolle → Microsoft → Windows → NTLM → Operational. Diese Abfrage sucht nach Blockierungen der letzten zwei Stunden:

PowerShell
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id = 4025
    StartTime = (Get-Date).AddHours(-2)
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, Message |
    Format-List

Ein zeitlich und zum Ziel passender Eintrag 4025 stützt diese Diagnose. Ereignis 4024 dokumentiert dagegen Audit-Vorgänge. Fehlende Einträge schließen andere Anmeldefehler nicht aus. Laut Microsoft KB5066470 kann eine manuelle Kennworteingabe in diesem konkreten SSO-Szenario weiterhin funktionieren, sofern das Profil sie zulässt.

Die nachhaltige Lösung ist, die Abhängigkeit vom alten Verfahren zu beseitigen; Microsoft empfiehlt im Administratorenhinweis zertifikatbasierte Authentifizierung. Der Wechsel von IKEv2 zu SSTP allein ersetzt das Anmeldeverfahren nicht. Eine Rückkehr in den Auditmodus wäre eine befristete Sicherheitsausnahme, keine Standardreparatur.

Wenn die feste Protokollwahl nicht hilft

Prüfe mit der IT die Erreichbarkeit des Gateways und die zum gewählten Protokoll passenden Firewallregeln. Bei IKEv2 nennt Microsoft insbesondere UDP 500 und 4500. Für SSTP kannst du den TCP-Verbindungsaufbau zum üblichen Port 443 testen. Ersetze den Beispielnamen durch euren VPN-Host:

PowerShell
Test-NetConnection -ComputerName "vpn.example.com" -Port 443 -InformationLevel Detailed

TcpTestSucceeded : True bestätigt nur den TCP-Aufbau. Zertifikat, SSTP-Aushandlung und Anmeldung sind damit nicht geprüft. Auch IKEv2 wird so nicht getestet: -Port prüft TCP, keine UDP-Ports. Die Grenzen des Tests erklärt Test-NetConnection.

Prüfe bei Zertifikatsmeldungen zusätzlich Gültigkeit, Vertrauenskette und Übereinstimmung des Servernamens. Vergleiche bei Authentifizierungsfehlern die Anforderungen von Client und NPS. Microsoft führt diese Ursachen in der VPN-Diagnose einzeln auf. Ein passender Fehlertext ist hilfreicher als das wahllose Zurücksetzen aller Netzwerkadapter.

So prüfst du, ob die Verbindung wieder zuverlässig arbeitet

  • Baue den Tunnel erneut auf und öffne einen tatsächlich benötigten internen Dienst.
  • Trenne und verbinde erneut. Prüfe auch den bisher problematischen Ablauf, etwa Aufwachen aus dem Standby oder einen erlaubten Netzwechsel.
  • Kontrolliere, ob der gleiche RasClient-Fehler zum neuen Testzeitpunkt wieder erscheint.
  • Prüfe bei zentraler Verwaltung nach einer Richtliniensynchronisierung, ob die freigegebene Profileinstellung erhalten bleibt.

Bleibt das Problem, gib der IT Build, Updateverlauf, Profilname, Tunneltyp, genaue Uhrzeit und Meldung mit. Teile Protokolle über den vorgesehenen Supportkanal; sie können Benutzer- und Servernamen enthalten.

Funktioniert VPN, aber die Remotedesktopsitzung bricht weiter ab, geht es dort weiter: Remotedesktop bricht nach Windows-Update ab: RDP-Fehler beheben.

Quellen und Aktualisierungsstand

Die Befehle sind anhand der verlinkten Microsoft-Dokumentation zusammengestellt. Ein eigener Test in deiner Firmenumgebung wird damit nicht behauptet. Der zurückgezogene Fix-Hinweis wurde beim Quellenabgleich am 23. Oktober 2026 berücksichtigt.