Ein Verbindungsversuch läuft in den Timeout, der Status bleibt auf „Connecting“ stehen, und beim nächsten Anlauf kommt die Meldung, der angegebene Port sei bereits in Benutzung. Microsoft hat diese Always-On-VPN-Ausfälle behoben. Sie waren nach den Sicherheitsupdates vom September 2026 unter Windows 11 aufgetreten. Der Fehler saß nicht in eurer Firewall, nicht im Zertifikat und auch nicht in der RADIUS-Konfiguration, sondern darin, wie der Client sein Protokoll auswählt.
Always On VPN ist der Nachfolger von DirectAccess und arbeitet im Hintergrund. Sobald ein Gerät eine Internetverbindung hat, baut der Dienst selbstständig einen verschlüsselten Tunnel zum Unternehmensnetz auf, ohne dass jemand auf „Verbinden“ klicken muss. Das gilt für domänenverbundene Rechner, für Geräte ohne Domänenmitgliedschaft und für Maschinen, die über Microsoft Entra ID angebunden sind, quer über Windows 10, Windows 11 und Windows Server. Weil dieser Tunnel im Hintergrund entsteht, fällt ein Defekt dort oft erst auf, wenn Anwendungen nicht mehr auf interne Systeme zugreifen – und dann sucht man erfahrungsgemäß an den falschen Stellen.
Was die September-Updates mit Always On VPN angestellt haben
Microsoft hat das Problem in der letzten Septemberwoche in einem Service Alert an IT-Administratoren eingeräumt. Auslöser waren die Sicherheitsupdates für Windows 11 vom September 2026, und zwar unter einer recht spezifischen Bedingung: Die automatische Protokollauswahl musste aktiv sein, und es mussten IKEv2 und SSTP als Kandidaten zur Verfügung stehen. In dieser Konstellation konnte eine Verbindung dauerhaft im Status „Connecting“ hängen bleiben oder nach einem ersten Fehlversuch komplett scheitern.
Unangenehm ist der zweite Teil des Fehlerbildes. Bei weiteren Versuchen tauchte mitunter die Meldung auf, der angegebene Port sei bereits in Benutzung – ein Hinweis, der sonst auf lokale Firewall, NAT oder eine parallele VPN-Software deutet. Wer dieser Spur gefolgt ist, hat Zeit in eine Ursache gesteckt, die es nicht gab. Solche Known Issues kosten nicht nur Ausfallzeit, sondern auch die Stunden, in denen Teams am falschen Ende suchen.
Betroffen war nicht ein einzelnes Gerät, sondern jede Umgebung, die nach diesem Muster konfiguriert ist. In gewachsenen Infrastrukturen ist das eher die Regel als die Ausnahme, weil die automatische Auswahl als bequeme Absicherung gilt und selten später wieder angefasst wird. Ein Profil, das seit Jahren unverändert läuft, wird eben nicht neu bewertet, nur weil ein kumulatives Update eingespielt wird.
Zwei Tunnel, ein Disponent: warum der Fallback klemmt
Man kann sich das als zwei Röhren vorstellen, die ins Firmennetz führen: eine für IKEv2, eine für SSTP. Die automatische Protokollauswahl arbeitet wie ein Disponent an der Einfahrt. Er schickt das Fahrzeug zuerst in die eine Röhre, und wenn dort eine Sperre gemeldet wird, leitet er es in die zweite um. Entscheidend ist, dass er die erste Röhre dabei wieder freigibt – sonst steht sie für den nächsten Versuch weiterhin als belegt im System.
Das Fehlerbild aus dem September lässt sich genau so lesen: Der Wechsel auf das zweite Protokoll funktioniert, aber die erste Verbindung wird nicht sauber abgeräumt. Der nächste Anlauf findet den Port deshalb belegt vor und scheitert, obwohl technisch nichts im Weg steht. Microsoft beschreibt das in seiner Mitteilung nüchtern als Zustand, in dem Verbindungen hängen bleiben oder nach einem ersten Fehlversuch nicht mehr zustande kommen. Die Analogie ist keine Diagnose, aber sie erklärt, warum ein Neustart des Rechners das Problem häufig kurzfristig verschwinden lässt – und warum es am nächsten Tag wieder da ist.
Ein Fehler, der durch Neuverbinden oder Reboot kurzzeitig verschwindet, ist kein Netzwerkproblem, sondern ein Zustandsproblem im Client. Wer solche Muster erkennt, spart sich lange Eskalationsrunden. Wer sie dokumentiert, hat beim nächsten Mal schneller eine Antwort.
Der Fix steckt im Preview-Update KB5127936
Bestätigt hat Microsoft die Behebung für alle, die das Preview-Update KB5127936 aus dem Oktober 2026 installiert haben. In der Beschreibung heißt es sinngemäß, das Update behebe ein Problem mit Always-On-VPN-Verbindungen, das nach der Installation des September-Sicherheitsupdates aufgetreten sei. Der Hinweis auf die automatische Protokollauswahl und den Fallback fehlt dort nicht – er ist der Kern der Sache, nicht ein Nebensatz.
Microsoft hatte den Punkt zwischenzeitlich schon als behoben markiert, und zwar in den kumulativen Oktober-Updates. Diese Einschätzung musste das Unternehmen zurücknehmen. Known-Issue-Listen sind Menschenwerk und werden unter Zeitdruck gepflegt. Wer sie als Wahrheit liest statt als Arbeitsstand, plant auf wackliger Grundlage.
Preview-Updates sind optional, deshalb ist der Fix noch nicht flächendeckend. Breit verteilt wird er erst über die kumulativen Updates des folgenden Patchday-Zyklus. Bis dahin existieren beide Zustände parallel: Systeme mit dem Preview-Patch sind sauber, Systeme ohne ihn tragen den Fehler weiter – und sehen identisch aus, wenn man nur auf die Windows-Buildnummer schaut. Genau hier entstehen Missverständnisse zwischen Teams, die unterschiedliche Update-Ringe fahren.
Wer warten will, kann das Profil auf ein Protokoll festnageln
Für Umgebungen, die Preview-Updates grundsätzlich nicht produktiv einsetzen, nennt Microsoft einen Workaround, der ohne Patch funktioniert. Administratoren sollen die Always-On-VPN-Profile von der automatischen Protokollauswahl auf ein einzelnes Protokoll umstellen, also entweder ausschließlich SSTP oder ausschließlich IKEv2. Die Wahl soll sich an Umgebung, Sicherheitsanforderungen und Deployment-Vorgaben orientieren, nicht an Bequemlichkeit.
Das ist ein Kompromiss und sollte bewusst getroffen werden. IKEv2 ist in der Regel die modernere und performantere Variante, nutzt aber UDP-Ports, die in fremden Netzen – Hotels, Konferenzzentren, manche Kundennetze – gern blockiert werden. SSTP läuft über TCP-Port 443 und kommt damit durch fast jede Firewall, hat dafür andere Eigenschaften bei Latenz und Durchsatz. Wer den Fallback abschaltet, gewinnt Stabilität gegen den bekannten Fehler und verliert genau die Flexibilität, für die der Fallback einmal eingebaut wurde.
Sinnvoll ist ein Blick auf die tatsächliche Nutzung: Wie oft hat der Fallback in den letzten Monaten überhaupt gegriffen, und in welchen Netzen? Wenn die Antwort lautet, dass IKEv2 praktisch immer funktioniert, ist die Festlegung darauf ein überschaubares Risiko. Wenn der Fallback regelmäßig einspringt, sollte man die Umstellung terminieren statt sie zu erzwingen – oder den Preview-Patch in einem Testring verifizieren und früher ausrollen.
Ein zweiter Fehler im selben Paket: Remote Desktop für Nicht-Admins
Das Oktober-Preview-Update bringt noch eine zweite Korrektur mit, die im Trubel um das VPN-Thema leicht untergeht. Sie betrifft Fälle, in denen sich Benutzer ohne Administratorrechte nicht per Remote Desktop mit Geräten verbinden konnten. Ausgelöst wurde das durch die Aktivierung der Funktion „Administrator protection“, und zwar nach Installation des nicht sicherheitsrelevanten Preview-Updates von September 2026 oder eines späteren Windows-Updates.
Auch hier das bekannte Muster: Eine Sicherheitsfunktion wird schrittweise ausgerollt, die Interaktion mit bestehenden Rollen- und Rechtekonzepten ist komplex, und ein Nebeneffekt landet in der Fläche. Wer „Administrator protection“ bereits aktiviert hat, sollte die RDP-Szenarien für Standardbenutzer nach dem Patch gezielt nachtesten. Wer noch nicht aktiviert hat, sollte den Rollout sauber planen statt ihn nebenbei mitlaufen zu lassen.
Was das für den Betrieb heißt
Die Lehre steckt weniger im Patch als im Umgang mit solchen Lagen. Ein Known Issue, das einen Monat zwischen „behoben“ und „doch nicht behoben“ pendelt, ist ein Argument für Testringe, in denen genau solche Verbindungsszenarien durchgespielt werden: automatische Protokollauswahl, beide Protokolle erlaubt, Erstverbindung scheitert, zweiter Versuch folgt. Wer das einmal automatisiert, merkt es vor den Anwendern.
Prüfe außerdem, welche Profile überhaupt automatische Auswahl nutzen. Diese Liste ist die Grundlage für jede Entscheidung – für den Workaround, für die Reihenfolge beim Rollout, für die Frage, welche Standorte zuerst dran sind. Ohne diese Übersicht bleibt jede Maßnahme Stückwerk.
Microsoft behebt die VPN-Probleme nach den September-Updates. Der Weg dorthin zeigt aber, wie eng Patchqualität und Betriebsrealität inzwischen verflochten sind. Die Antwort darauf ist keine Skepsis gegenüber Updates, sondern Routine: kleinere Ringe, klare Kriterien für die Freigabe, dokumentierte Fallbacks. Dann bleibt ein Fehler wie dieser eine Notiz im Änderungsprotokoll.
Quelle: bleepingcomputer.com
