Wrześniowe aktualizacje Windows 11 przyniosły administratorom kolejny problem, którego raczej nie chcieli zobaczyć po rozpoczęciu dnia pracy. W części firm przestały prawidłowo działać połączenia Always On VPN, czyli mechanizm odpowiedzialny za automatyczny dostęp pracowników do zasobów firmowej sieci. Microsoft potwierdził usterkę i podał tymczasowe obejście. Na właściwą poprawkę nadal musimy poczekać.
Problem jest dość specyficzny. Jeżeli profil VPN automatycznie wybiera protokół i potrafi przełączać się pomiędzy IKEv2 oraz SSTP, połączenie może zawisnąć na komunikacie „Connecting”. Kolejne próby czasami kończą się błędem informującym, że określony port jest już używany. Dla pracownika oznacza jedno: firmowy laptop działa, internet działa, a intranet, zasoby sieciowe czy aplikacje dostępne przez VPN nagle znajdują się poza zasięgiem.
Problem obejmuje trzy wersje Windows 11
Microsoft wskazuje obecnie trzy wydania systemu. Windows 11 26H1 otrzymał problem wraz z KB5124012, natomiast Windows 11 25H2 oraz 24H2 wraz z KB5124008. Oba pakiety zabezpieczeń zostały wydane 8 września 2026 roku.
W przypadku KB5124012 mowa o kompilacji 28000.2954 dla Windows 11 26H1. KB5124008 podniósł Windows 11 25H2 do kompilacji 26200.9445, a 24H2 do 26100.9445.
Skala potencjalnego znaczenia podobnych usterek rośnie wraz z udziałem Windows 11 na rynku. Według StatCounter w sierpniu 2026 roku Windows 11 odpowiadał już za 68,6 proc. komputerów korzystających z Windows na świecie. Windows 10 miał 30,14 proc., a Windows 7 około 0,96 proc. Nie oznacza oczywiście, że prawie 70 proc. komputerów może stracić dostęp do firmowego VPN. Always On VPN jest rozwiązaniem biznesowym i potrzebuje konkretnej konfiguracji. Liczby dobrze pokazują jednak, jak szeroko Windows 11 jest już wykorzystywany.
Co dokładnie popsuła aktualizacja
Always On VPN może automatycznie zestawiać szyfrowany tunel do firmowej infrastruktury po uzyskaniu dostępu do internetu. Administrator nie potrzebuje prosić pracownika o ręczne uruchamianie klienta VPN przy każdym otwarciu laptopa. System robi sporą część pracy sam, co w środowisku z setkami komputerów ma oczywisty sens.
Microsoft pozwala skonfigurować profil użytkownika w sposób umożliwiający korzystanie z IKEv2 oraz awaryjne przejście na SSTP. Mechanizm przydaje się między innymi wtedy, gdy IKEv2 nie może zestawić połączenia z powodu konfiguracji sieci, zapory lub pośredniczącego proxy.
I właśnie podczas automatycznej zmiany sposobu połączenia pojawia się problem po wrześniowej aktualizacji. Pierwsza próba może zakończyć się niepowodzeniem, klient próbuje skorzystać z drugiego protokołu, a połączenie zatrzymuje się w stanie „Connecting” lub zaczyna wykonywać kolejne próby bez powodzenia. Przy następnej próbie użytkownik może zobaczyć komunikat „The specified port is already in use”.
Administrator dostaje wtedy klasyczny prezent od aktualizacji: system działa, usługa jest skonfigurowana, certyfikaty mogą być poprawne, a użytkownik i tak nie dostanie się tam, gdzie powinien.
Nie każdy Always On VPN jest objęty usterką
Ważny szczegół łatwo zgubić w krótkich komunikatach opisujących awarię. Microsoft wskazuje problem dotyczący konfiguracji z automatycznym wyborem metody połączenia, przykładowo IKEv2 z możliwością przejścia na SSTP.
Dokumentacja Microsoftu rozróżnia przy tym User Tunnel oraz Device Tunnel. Tunel użytkownika może pracować z SSTP i IKEv2. Device Tunnel obsługuje natomiast wyłącznie IKEv2 i nie korzysta z awaryjnego przechodzenia na SSTP.
Jeżeli w firmie używasz wyłącznie Device Tunnel z IKEv2, opisany mechanizm automatycznego przełączania protokołu nie występuje w identycznej postaci. Nie ma zatem podstaw, aby zakładać, że każda instalacja Always On VPN po wrześniowej aktualizacji przestanie działać.
Microsoft proponuje proste obejście
Do czasu wydania poprawki Microsoft zaleca administratorom zmianę profilu Always On VPN z automatycznego wyboru protokołu na jeden konkretny protokół.
Można ustawić wyłącznie IKEv2 albo wyłącznie SSTP. Wybór powinien zależeć od konfiguracji firmowej infrastruktury, zastosowanych zabezpieczeń oraz sposobu wdrożenia VPN. Microsoft nie wskazuje jednego protokołu jako uniwersalnego rozwiązania dla wszystkich organizacji.
Nie jest również narzucone konkretne narzędzie administracyjne. Firma może zmienić profil sposobem używanym już do zarządzania Always On VPN, np. poprzez stosowane rozwiązanie MDM. Administrator powinien jednak najpierw sprawdzić, który protokół jest prawidłowo obsługiwany przez firmową bramę VPN, zapory i pozostałą infrastrukturę.
Dokumentacja Microsoftu potwierdza, że RRAS obsługuje między innymi SSTP oraz IKEv2. Przy nowych wdrożeniach Windows Server 2025 właśnie oba protokoły pozostają standardowo akceptowane, podczas gdy PPTP i L2TP nie są już domyślnie przyjmowane w nowych konfiguracjach RRAS.
Odinstalowanie aktualizacji nie powinno być pierwszym ruchem
W serwisie Microsoft Q&A administratorzy zgłaszali już 9 września, że usunięcie KB5124008 i ponowne uruchomienie komputera przywracało działanie Always On VPN na testowanych urządzeniach. Pojawiły się również zgłoszenia środowisk obejmujących dużą liczbę użytkowników.
Taki rollback może jednak oznaczać usunięcie również poprawek bezpieczeństwa dostarczonych w pakiecie. Microsoft opisuje KB5124008 i KB5124012 jako zbiorcze aktualizacje zabezpieczeń Windows 11. Z punktu widzenia administratora rozsądniejszym rozwiązaniem jest zatem skorzystanie z oficjalnego obejścia, jeżeli infrastruktura pozwala bezpiecznie wymusić jeden protokół.
Odinstalowywanie całego pakietu tylko dlatego, że VPN odmówił współpracy, przypomina naprawę problemu większym problemem. Czasem zadziała, tylko rachunek przychodzi później.
Wrześniowe aktualizacje mają dłuższą listę problemów
Awaria Always On VPN nie jest jedynym kłopotem związanym z wrześniowymi poprawkami Windows 11. Microsoft wcześniej informował między innymi o problemach z Remote Desktop Services, urządzeniami audio USB, udostępnianiem katalogów hosta do części maszyn wirtualnych Linux oraz Historią plików.
Część usterek doczekała się już dodatkowych poprawek. W przypadku Always On VPN na 24 września status pozostaje inny: Microsoft pracuje nad właściwym rozwiązaniem, a administratorzy mają korzystać z obejścia polegającego na rezygnacji z automatycznego przełączania IKEv2/SSTP.
Jeżeli po instalacji wrześniowego pakietu firmowe laptopy nagle zatrzymują się podczas zestawiania Always On VPN, dobrze jest w pierwszej kolejności sprawdzić konfigurację protokołu zamiast przebudowywać certyfikaty, serwer VPN czy reguły dostępu. Przy profilu ustawionym na automatyczny wybór IKEv2/SSTP trop jest już bardzo konkretny. Do czasu wydania poprawki wymuszenie jednego protokołu pozostaje oficjalnym sposobem Microsoftu na przywrócenie połączenia.
Źródła: Microsoft, Notebookcheck.
