Windows VPN nem csatlakozik 2026: Hibakódok és hibaelhárítás IT helpdesknek

Frissítve: 2026. május 30.

Windows VPN nem csatlakozik a leggyakrabban három okból: a kliens nem éri el a VPN átjárót a 443-as, 500-as vagy 4500-as porton, a felhasználói hitelesítő adatok lejártak vagy zárolva vannak az Active Directoryban, vagy az IKEv2/L2TP gépi tanúsítvány hiányzik. A megoldás minden esetben a hibakód (809, 691, 720, 800, 868) azonosításával kezdődik, mert a kód önmagában megmondja, hogy a hálózat, a hitelesítés vagy a protokoll a probléma forrása. Ebben a runbookban a négy leggyakoribb kódhoz mutatok lépésről lépésre kezelhető megoldást, amelyet a saját helpdeskemen évek óta használunk.

• A 809 hibakód majdnem mindig hálózati blokkolás: a UDP 500/4500 vagy a TCP 443 port nem nyitott a tűzfalon vagy a NAT-eszközön.
• A 691 hibakód a felhasználói hitelesítés hibája, ellenőrizd az AD-fiók státuszát, a jelszó lejáratát és az MFA-állapotot, mielőtt a VPN-konfigurációhoz nyúlnál.
• A 720 és 868 hibák gyakran DNS- vagy tanúsítványproblémára vezethetők vissza; az IKEv2 kapcsolatoknál a gép-tanúsítvány lejárta a leggyakoribb gyökér-ok.
• A Get-VpnConnection és Get-EventLog -LogName Application -Source RasClient PowerShell parancsok 30 másodperc alatt megmondják, mit lát a kliens.
• Always On VPN esetén külön kell ellenőrizni a felhasználói és az eszközalagutat, a két alagút eltérő hitelesítési útvonalat használ.
• A ticket-lezárás előtt mindig dokumentáld a hibakódot és a tényleges javítást, a következő ügynöknek ez 20 percet spórol.

Windows VPN hibakódok 2026: gyors hivatkozás

Mielőtt bármit megpiszkálnál a kliens gépén, kérd el a hibakódot a felhasználótól. A Windows 10 és Windows 11 kliensek számkódot adnak vissza minden VPN-hibára, és ezek a kódok rendkívül beszédesek, sokkal hasznosabbak, mint a felhasználó által adott "nem működik" leírás. Az elmúlt évben a csapatom több mint 1200 VPN-tikettet zárt le, és ezek közül körülbelül 85 százalék öt kód valamelyikéhez tartozott. Ezt a táblázatot kinyomtatva tartjuk minden ügynök monitorán.

Hibakód	Mit jelent	Gyakori ok	Első lépés
809	NAT/tűzfal blokkolja a forgalmat	UDP 500/4500 vagy TCP 443 zárva	Telnet/Test-NetConnection a VPN átjáró felé
691	Sikertelen hitelesítés	Rossz jelszó, lejárt fiók, MFA-blokkolás	AD-fiók állapot ellenőrzése
720	PPP egyeztetési hiba	Sérült TCP/IP verem, ütköző protokoll	WAN Miniport adapterek újratelepítése
800	Nem érhető el a távoli kiszolgáló	Rossz szerver-FQDN, helyi tűzfal	DNS- és tűzfalellenőrzés
868	A távoli kiszolgáló neve nem oldható fel	DNS hibás vagy belső név külső kliensen	nslookup futtatása a VPN FQDN-re
13801/13806	IKE hitelesítési hiba (IKEv2)	Lejárt vagy hiányzó gép-tanúsítvány	certlm.msc megnyitása, tanúsítvány lánc

Miért nem csatlakozik a Windows VPN?

Tizenöt év szervízpult-vezetés után megtanultam, hogy a VPN-problémák nem műszaki problémák, hanem felhasználói élményproblémák, amelyeknek műszaki gyökerük van. A felhasználó nem azt mondja, hogy "az IKEv2 SA fázis 2-es egyeztetése sikertelen", azt mondja, hogy "nem tudok hazafelé dolgozni". A mi dolgunk lefordítani a kettő közötti távolságot. A gyakorlatban a Windows VPN négy ok miatt nem csatlakozik: hálózati elérés, hitelesítés, protokoll-egyeztetés vagy névfeloldás.

A hálózati elérés azt jelenti, hogy a kliens egyáltalán el tudja-e érni a VPN átjárót, vendég Wi-Fi-n, mobil hotspoton vagy hotelhálózaton sokszor szándékosan blokkolják az IPsec portokat. A hitelesítés azt jelenti, hogy a felhasználó vagy a gép igazolni tudja-e magát: jelszó, MFA, tanúsítvány. A protokoll-egyeztetés arra utal, hogy a kliens és a szerver meg tud-e egyezni egy közös titkosító készletben, ami a TLS 1.3 általánossá válása óta meglepően sokszor megakad olyan régi szervereken, amelyek még csak SHA1 titkosítást támogatnak. A névfeloldás pedig azt jelenti, hogy a kliens megtalálja-e egyáltalán a szerver IP-címét.

Az IT csapatok 2026-ban egyre inkább Always On VPN vagy Microsoft Entra Private Access megoldásokra migrálnak a hagyományos PPTP/L2TP-ről, ami új hibakategóriákat hoz be (tanúsítvány-rotáció, eszközmegfelelés, feltételes hozzáférés). Ha a régi MFA-problémák ismerősek, érdemes átolvasni a Microsoft 365 MFA kizárás hibaelhárítás útmutatómat is, mert a VPN- és az MFA-blokkolás gyakran ugyanannál a felhasználónál csap össze.

809 hibakód: NAT és tűzfal hibaelhárítás

A 809 hibakód üzenete: "A hálózati kapcsolat nem hozható létre, mert a távoli szerver nem válaszol". Ez a leggyakoribb kód, amit látunk, különösen otthoni hálózatokról vagy szállodai Wi-Fi-ről bejelentkezőktől. A kód majdnem mindig azt jelenti, hogy a kliens elindította a kérést, de a NAT-eszköz vagy egy közbeiktatott tűzfal eldobta a forgalmat, mielőtt elérte volna a VPN átjárót.

Először Test-NetConnection paranccsal ellenőrizd a portokat. Az IKEv2 az UDP 500-as és 4500-as portot használja, az SSTP a TCP 443-at, az L2TP/IPsec szintén UDP 500/4500-at, de IP 50-es protokollt (ESP) is. Egy egyszerű otthoni router NAT-jén az IPsec passthrough nélkül az UDP 500/4500 átengedi a csomagokat, de az ESP-t nem, ezért javasolja sok cég az SSTP-t vagy IKEv2-t, ami minden NAT-on átmegy.

# Ellenőrizd az SSTP elérhetőséget (TCP 443)
Test-NetConnection -ComputerName vpn.ceg.hu -Port 443

# Ellenőrizd az IKEv2 portokat (UDP, Test-NetConnection nem támogatja UDP-t,
# ezért a PortQry eszközt használjuk a Microsofttól)
portqry.exe -n vpn.ceg.hu -p UDP -e 500
portqry.exe -n vpn.ceg.hu -p UDP -e 4500

# Aktuális kliens-konfiguráció
Get-VpnConnection -Name "CegVPN" | Format-List *

Ha a Test-NetConnection a 443-as porton TcpTestSucceeded: False eredményt ad, a probléma a kliens és a szerver között van, nem a klienssel. Ilyenkor kérdezd meg a felhasználót, hogy a saját otthoni hálózatáról vagy nyilvános Wi-Fi-ről próbálkozik. A nyilvános hálózatok, különösen szállodákban és reptereken, gyakran tiltják a VPN-portokat. A megoldás ilyenkor mobiladat (hotspot) használata, vagy ha lehetséges, SSTP-re vagy Microsoft Entra Internet Access átállás, mert a 443-as port szinte mindig nyitva van.

691 hibakód: hitelesítés és AD-fiók ellenőrzése

A 691 üzenete: "A kapcsolat megtagadva, mert a megadott felhasználónév vagy jelszó nem felel meg". A felhasználók ezt a hibát gyakran úgy értelmezik, hogy "elromlott a VPN", pedig kilencvenöt százalékban az ő hitelesítő adataikról van szó. A tipikus okok: lejárt jelszó, AD-fiók zárolva, az MFA-prompt nem érkezett meg, vagy a felhasználó tévedésből egy régi (cache-elt) jelszót próbál.

Az első dolog, amit ellenőrzök, az AD-fiók állapota PowerShell-lel a tartományvezérlőn vagy az RSAT-tal felszerelt admin gépen:

# AD fiók állapotának ellenőrzése
Get-ADUser -Identity kovacs.eva -Properties LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate |
    Select-Object SamAccountName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, AccountExpirationDate

# Ha zárolt, oldjuk fel
Unlock-ADAccount -Identity kovacs.eva

# A zárolás forrásának megtalálása (melyik DC zárolta?)
Get-ADUser kovacs.eva -Properties msDS-LastFailedInteractiveLogonTime, LastBadPasswordAttempt

Ha a fiók nem zárolt és a jelszó nem járt le, a következő gyanú az MFA. A modern VPN-kapuk (Entra ID-val integrálva vagy NPS-Extension-nel) MFA-prompt küldenek a felhasználó telefonjára. Ha a telefon offline van, vagy a Microsoft Authenticator alkalmazás nem szinkronizál, a hitelesítés sikertelen lesz, és a Windows kliens 691-et fog mutatni, pedig a probléma valójában nem rossz jelszó, hanem nem fogadott MFA-jóváhagyás. A felhasználónak ezt általában nem mondja meg semmi a képernyőn, ezért nekünk kell visszakérdeznünk: "kaptál push értesítést a telefonodon, amikor megpróbáltál csatlakozni?"

Egy konkrét eset a múlt hónapból: egy kollégánk hétfő reggel 691 hibát kapott. A jelszava nem járt le, a fiókja nem volt zárolva. Kiderült, hogy az NPS-Extension MFA naplója szerint a kérés ment, de a felhasználó telefonja egy hetes nyaralás után 100 órás időeltolódással futott, a TOTP push nem érvényesült. Időszinkronizáció utána azonnal működött.

720 és 800 hibakódok: protokoll és kapcsolat

A 720 hibakód a PPP egyeztetés sikertelenségére utal, és a leggyakoribb oka egy sérült TCP/IP verem vagy WAN Miniport adapter. Ezt a hibát általában akkor látom, amikor a felhasználó néhány hete megpróbált egy harmadik féltől származó VPN klienst (NordVPN, ExpressVPN, OpenVPN) is telepíteni, és az ottani driver maradványai zavarják a beépített Windows klienst.

A 800 hibakód üzenete: "Nem hozható létre a távoli kapcsolat, mert a próbált VPN alagutak meghiúsultak". Ez tágabb kategória, jelentheti a hibás FQDN-t, a kliens helyi tűzfalát vagy egy ütköző VPN-szoftvert. A két kód javítási lépései részben fedik egymást, ezért egy menetben oldom meg:

# 1. TCP/IP verem visszaállítása (admin PowerShell)
netsh int ip reset
netsh winsock reset
ipconfig /flushdns

# 2. WAN Miniport adapterek listázása
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*WAN Miniport*"} |
    Select-Object Name, Status, InterfaceDescription

# 3. Konfliktusos VPN szolgáltatások keresése
Get-Service | Where-Object {$_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*OpenVPN*"} |
    Select-Object Name, Status, StartType

# 4. Újraindítás után ellenőrzés
Restart-Service -Name "RasMan", "PolicyAgent" -Force

Ha ez nem segít, az utolsó lépés a problémás WAN Miniport adapter eltávolítása Device Manager-ben (devmgmt.msc → View → Show hidden devices → Network adapters → WAN Miniport (IKEv2/SSTP/L2TP) → Uninstall device), majd egy "Scan for hardware changes". A Windows újraépíti a virtuális adaptereket a következő rendszerindításkor. Ezt a manővert havonta legalább háromszor használjuk olyan klienseken, ahol valaki kísérletezett harmadik féltől származó VPN-kliensekkel.

868 hibakód: DNS feloldási problémák

A 868 hibakód üzenete: "A távoli kapcsolat nem hozható létre, mert a távoli hozzáférési szerver neve nem oldható fel". Ez tisztán DNS-probléma, a kliens nem találja meg a szerver IP-címét. Két fő forrása van: a kliens DNS-szervere nem érhető el, vagy a VPN szerver FQDN-jét csak belső DNS oldaná fel, és a kliens még nem ért rá belső hálózatra.

Ez utóbbi klasszikus hiba olyan cégeknél, ahol a VPN átjárót nem publikus DNS-en, csak belső "ad.ceg.hu" tartományban regisztrálták. Ilyenkor a felhasználó otthonról soha nem fog tudni csatlakozni, mert előbb kellene VPN, hogy elérje a DNS-t, ami a VPN szerver nevét feloldaná. A megoldás a publikus DNS-rekord létrehozása (pl. "vpn.ceg.hu") vagy a "hosts" fájl módosítása vészhelyzetre.

# Diagnózis a felhasználó gépén
nslookup vpn.ceg.hu
nslookup vpn.ceg.hu 8.8.8.8

# Ha a publikus DNS sem oldja fel:
# - A rekord hiányzik a publikus DNS-ből (vegye fel a hálózati csapat)
# - A kliens DNS-e fertőzött vagy elavult

# Ideiglenes javítás: hosts fájl
# C:\Windows\System32\drivers\etc\hosts
# 203.0.113.42  vpn.ceg.hu

A hosts-fájl megoldás csak vészhelyzeti gyorssegély, soha ne hagyd otthon a felhasználónál tartósan, mert ha a VPN szerver IP-címe változik, a felhasználó ismét hívni fog. Az alapprobléma majdnem mindig egy hiányzó publikus DNS-rekord. Az új DDR (Discovery of Designated Resolvers, RFC 9462) támogatás Windows 11 24H2-ben tovább bonyolíthatja a képet, mert a kliensek titkosított DNS-re (DoH/DoT) válthatnak automatikusan, megkerülve a vállalati DNS-t.

PowerShell diagnosztika és RRAS-naplók

Ha a hibakód nem ad egyértelmű választ, a következő lépés a részletes naplók kinyerése. A Windows VPN-kliens három helyre ír: az Eseménynapló Alkalmazás és Rendszer logjába, a Microsoft-Windows-RasClient/Operational csatornába, és, ha bekapcsoltad, a CMTrace-kompatibilis szöveges nyomkövetési naplókba.

# Utolsó 20 VPN-eseménykép kinyerése
Get-WinEvent -LogName "Application" -MaxEvents 100 |
    Where-Object {$_.ProviderName -like "*RasClient*"} |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

# Részletes RAS nyomkövetés bekapcsolása (admin)
netsh ras set tracing * enabled

# Reprodukáld a hibát, majd a naplók itt találhatók:
# C:\Windows	racing\RASTLS.LOG
# C:\Windows	racing\RASCHAP.LOG
# C:\Windows	racing\IKEEXT.LOG

# Nyomkövetés kikapcsolása (mindig kapcsold ki, mert sok lemezt eszik)
netsh ras set tracing * disabled

A szerveroldali RRAS-naplók (Routing and Remote Access Service) ugyanezeket az eseményeket gyakran részletesebben rögzítik. Az RRAS Eseménynaplójában a Microsoft-Windows-RemoteAccess csatorna mutatja a beérkezett kérelmeket, az elutasítás okát, és a használt EAP-módszert. Ha az NPS (Network Policy Server) is részt vesz a hitelesítésben, például MFA bővítménnyel, akkor a Microsoft-Windows-NPS-Operational csatornát is meg kell nézni.

Egy praktikus tipp az adatgyűjtésre: ha a felhasználó távoli helyszínen van és nem tudjuk őt vezetni a parancsok kiadásán, küldj neki egy aláírt PowerShell szkriptet, amely automatikusan kigyűjti a fenti adatokat egy ZIP-be és feltölti az SFTP-re. A mi szkriptünk 30 másodperc alatt összerakja a teljes diagnosztikai csomagot, és a felhasználónak csak duplán kell rákattintania.

Always On VPN-specifikus hibák

Az Always On VPN (AOVPN) jelentősen gyakoribb 2026-ban, mert a Windows 11 24H2 frissítés bevezette a továbbfejlesztett ProfileXML sablonokat, és a Microsoft egyre erőteljesebben tolja az Intune-vezérelt profilok használatát. Az AOVPN két alagutat kezel: egy eszközalagutat (Device Tunnel), amely a felhasználó bejelentkezése előtt épül fel és gép-tanúsítvánnyal hitelesít, és egy felhasználói alagutat (User Tunnel), amely a bejelentkezés után indul. A két alagút eltérő ok miatt eshet össze.

A leggyakoribb AOVPN hiba 2026-ban a gép-tanúsítvány lejárta. A Microsoft Cloud PKI és más vállalati PKI-megoldások általában 1 vagy 2 éves élettartamú tanúsítványokat adnak ki, és ha az automatikus megújítás megakad, az eszközalagút némán leáll. A felhasználó észre sem veszi, csak hetekkel később, amikor egy belső erőforrás hirtelen elérhetetlen.

# Eszközalagút állapotának ellenőrzése (admin)
Get-VpnConnection -AllUserConnection | Format-List Name, ConnectionStatus, ServerAddress

# Gép-tanúsítvány lejáratának ellenőrzése
Get-ChildItem -Path Cert:\LocalMachine\My |
    Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"} |
    Select-Object Subject, NotAfter, Thumbprint

# AOVPN profil részleteinek megtekintése
Get-VpnConnection -AllUserConnection -Name "AOVPN-Device" | Format-List *

# Eszközalagút kézi újraindítása
rasdial "AOVPN-Device" /disconnect
rasdial "AOVPN-Device"

Hogyan állítsam vissza a VPN ügyfelet?

Amikor minden hibakód-specifikus megoldást kipróbáltunk, és semmi sem segít, a "nukleáris opció" a teljes VPN kliens visszaállítása. Ez nem egy gombnyomás Windowsban, több lépésből áll, és Windows 11 24H2 alatt kicsit megváltozott. Ezt a sorrendet használjuk:

1. Töröld a meglévő VPN-profilt PowerShellből: Remove-VpnConnection -Name "CegVPN" -Force -PassThru
2. Reseteld a WAN Miniport adaptereket Eszközkezelőben (eltávolítás + hardver-újraellenőrzés).
3. Reseteld a TCP/IP vermet: netsh int ip reset és netsh winsock reset.
4. Indítsd újra a gépet.
5. Add hozzá újra a VPN profilt, lehetőleg PowerShell-szkripttel vagy Intune profillal, ne kézzel a Settings alkalmazásban, mert a GUI több beállítást eltakar.
6. Próbáld újra a csatlakozást és ellenőrizd a hibakódot.

A PowerShell-szkriptes profilkészítés azért is fontos, mert a kézi Settings → VPN → Add VPN ablak Windows 11-ben nem támogatja az összes EAP-konfigurációt, például a TLS-tanúsítvánnyal történő hitelesítést sokkal megbízhatóbban lehet Add-VpnConnection és Set-VpnConnectionIPsecConfiguration parancsokkal beállítani. Ha rendszeresen hozol létre VPN-profilokat, a saját runbookomban egy mintaszkriptet tartok, amely paramétereket fogad (felhasználónév, szerver, EAP-típus) és bemásolható.

Helpdesk tikettkezelési minta

A műszaki megoldás csak fele a munkának, a másik fele, hogy a tiketten dokumentáltan, megismételhetően, és a felhasználó számára érthetően zárod le. A csapatomban ezt a sablont használjuk minden VPN-tikethez, anonimizált példával:

TIKETT #HD-2026-04812
Felhasználó: K.É. (értékesítés, otthoni iroda)
Bejelentés időpontja: 2026-05-12 08:14
Bejelentés módja: telefon (HD vonal)

PANASZ (felhasználó szavaival):
"Reggel óta nem tudom elérni a CRM-et. Tegnap még működött.
A VPN ikon azt mondja, hogy hibakód 691."

DIAGNÓZIS:
1. Hibakód 691 = hitelesítési hiba
2. AD-fiók ellenőrzés: nem zárolt, jelszó 2026-05-11-én lejárt
3. Felhasználó megerősítette: nem cserélt jelszót

JAVÍTÁS:
- Jelszó-csere remediation portálon keresztül
- VPN csatlakozási teszt sikeres 08:31-kor
- Felhasználó visszaigazolta: CRM elérhető

TANULSÁG:
- A jelszó-lejárati értesítés a felhasználó SPAM-mappájába került
- Javaslat: a 14 napos figyelmeztetést push-notifikációba is rakni

LEZÁRÁS:
Megoldva, 17 perc, kategorizálva: VPN/Hitelesítés/Jelszó-lejárat

A "Tanulság" mező az, amit a legtöbb csapat kihagy, pedig ez teszi a tikettből tudást. Ha minden hónap végén a vezetők átolvassák a tanulság-szakaszokat, gyorsan kiderül, mely rendszerszintű problémák ismétlődnek, és melyeket lehet végleg megszüntetni. Az általunk látott legjelentősebb csökkenés (40 százalékos VPN-hívásszám-esés) abból jött, hogy a jelszó-lejárati e-mail rendszerét Teams-értesítésekre cseréltük, mert a SPAM-mappás ügyek megszűntek. Egyetlen hangzatos KPI sem hozott ennyi értéket, mint a "tanulságok" rendszeres újraolvasása.

Ha még nem osztályozod a tiketteket világos kategóriákba, mindenképp olvasd el a Windows 11 frissítési hibák útmutatónkat is, a kategóriastruktúra ott bemutatott logikája VPN-tikettekre is alkalmazható.

Gyakran ismételt kérdések

Miért nem csatlakozik a VPN Windows 11-en?

Windows 11-en a VPN leggyakrabban hálózati blokkolás (UDP 500/4500 vagy TCP 443 zárva), lejárt felhasználói hitelesítő adat, vagy hiányzó/lejárt gép-tanúsítvány miatt nem csatlakozik. Mindig a hibakóddal kezdj, a kód önmagában szétválasztja a három fő ok-csoportot.

Hogyan oldhatom meg a 809 VPN hibát?

A 809 hibakód NAT- vagy tűzfal-blokkolást jelez. Ellenőrizd Test-NetConnection paranccsal, hogy a kliens eléri-e a VPN átjárót a megfelelő porton (443 SSTP-hez, UDP 500/4500 IKEv2-höz). Ha nem, váltsd át a kliens hálózatát (mobilhotspot tesztre), vagy kérd a hálózati csapatot a port megnyitására.

Mit jelent a 691 hibakód a VPN-nél?

A 691 hitelesítési hiba: a megadott felhasználónév vagy jelszó nem felel meg. Ellenőrizd az AD-fiók állapotát Get-ADUser -Properties LockedOut, PasswordExpired parancscsal, és kérdezd meg a felhasználót, kapott-e MFA-promptot a telefonján. Az esetek 95 százaléka jelszó-lejárat, fiókzárolás vagy elmaradt MFA-jóváhagyás.

Hogyan állítsam vissza a VPN ügyfelet Windows 11-en?

Töröld a profilt (Remove-VpnConnection), távolítsd el a WAN Miniport adaptereket az Eszközkezelőben, futtass netsh int ip reset és netsh winsock reset parancsokat, indítsd újra a gépet, majd hozd létre újra a profilt PowerShell-szkripttel vagy Intune-konfigurációval.

Miért lassú a VPN kapcsolat csatlakozás után?

A csatlakozás utáni lassúság leggyakrabban MTU-méret problémára, hibás split tunneling konfigurációra vagy túlterhelt VPN-átjáróra utal. Csökkentsd a VPN adapter MTU-ját 1400-ra netsh interface ipv4 set subinterface paranccsal teszteléshez, és ellenőrizd, hogy a felesleges forgalom (Teams médiafolyam, Windows Update) ki van-e zárva az alagútból.