Windows 11 VPN-yhteysongelmat – Virhekoodit, korjausohjeet ja Always On VPN

Miksi VPN-yhteys ei toimi Windows 11:ssä?

VPN-ongelmat ovat IT-helpdeskin arkipäivää — etenkin nyt, kun etätyö on vakiintunut pysyväksi käytännöksi lähes jokaisessa organisaatiossa. Tunnet varmaan tilanteen: käyttäjä soittaa, kertoo ettei pääse yritysverkkoon, ja sinun pitäisi ratkaista asia mielellään heti. Aina se ei ole niin yksinkertaista.

Windows 11:n viimeaikaiset päivitykset ovat tuoneet mukanaan yllättäviäkin haasteita VPN-yhteyksille. SMB-allekirjoituksen pakollisuus versiosta 24H2 alkaen, NTLMv1-protokollan poistaminen ja palomuurisääntöjen muutokset voivat kaikki vaikuttaa VPN-tunneleiden toimintaan. Ja sitten päälle vielä sertifikaattiongelmat, virheelliset profiiliasetukset ja porttiblokit.

Olen koonnut tähän oppaan käytännönläheiset ohjeet yleisimpiin VPN-ongelmiin. Virhekoodit, korjausohjeet, Always On VPN -konfiguraatio — kaikki löytyy yhdestä paikasta. Seuraavan kerran kun puhelin soi, sinulla on vastaus valmiina.

Windows 11:n sisäänrakennettu VPN-tuki — protokollat ja asetukset

Windows 11 tukee useita VPN-protokollia suoraan ilman kolmannen osapuolen ohjelmistoja. Tämä on hyvä uutinen IT-tiimeille, jotka haluavat pitää asennukset yksinkertaisina.

Mutta on tärkeää ymmärtää, mitä kukin protokolla tekee ja milloin sitä kannattaa käyttää.

Tuetut tunnelointiprotokollat

• IKEv2 (Internet Key Exchange version 2): Microsoftin suosittelema protokolla. Nopea, turvallinen ja tukee automaattista uudelleenkytkentää verkon vaihtuessa (esim. Wi-Fi → mobiilidata). Paras valinta Always On VPN -käyttöön — ja rehellisesti sanottuna useimpiin muihinkin tilanteisiin.
• SSTP (Secure Socket Tunneling Protocol): Toimii TCP-portin 443 kautta, joten se läpäisee käytännössä kaikki palomuurit. Erinomainen vaihtoehto rajoittavissa verkkoympäristöissä, kuten hotelleissa tai konferenssikeskuksissa.
• L2TP/IPsec: Vanha mutta tuttu protokolla. Käyttää UDP-portteja 500, 4500 ja 1701. Voi aiheuttaa ongelmia NATin takana. Uusiin käyttöönottoihin en suosittele.
• PPTP (Point-to-Point Tunneling Protocol): Vanhentunut ja turvaton. Älä käytä uusissa asennuksissa — mainitsen sen tässä vain siksi, että vanhemmissa ympäristöissä siihen törmää edelleen.
• Automaattinen: Windows kokeilee protokollia järjestyksessä turvallisimmasta alkaen (IKEv2 → SSTP → L2TP → PPTP). Käytännöllinen, mutta saattaa hidastaa yhteydenmuodostusta jonkin verran.

VPN-yhteyden luominen Windows 11:ssä

Perus-VPN-yhteyden luominen Windowsin omilla asetuksilla on suoraviivaista:

1. Avaa Asetukset → Verkko ja internet → VPN
2. Napsauta Lisää VPN
3. Valitse VPN-palveluntarjoajaksi Windows (sisäänrakennettu)
4. Anna yhteydelle nimi, palvelimen osoite ja valitse tunnelointiprotokolla
5. Valitse todennusmenetelmä (käyttäjätunnus/salasana, sertifikaatti tai älykortti)
6. Tallenna ja yhdistä

Nyrkkisääntö: jos et tiedä, mikä protokolla on käytössä yrityksessäsi, aloita IKEv2:lla. Jos se ei toimi, kokeile SSTP:tä. Näin vältät turhaa arvailua.

Yleisimmät VPN-virhekoodit ja niiden korjaaminen

VPN-virhekoodit ovat niitä mystisiä numeroita, jotka kertovat ongelman syyn — kunhan tiedät, mitä etsiä. Käydään läpi yleisimmät ja miten ne ratkaistaan käytännössä.

Virhe 800: Etäyhteyden muodostaminen epäonnistui

Tämä on todennäköisesti yleisin VPN-virhe, johon törmäät. Se tarkoittaa yksinkertaisesti, että VPN-tunnelia ei voitu muodostaa — tyypillisesti siksi, että VPN-palvelin ei ole tavoitettavissa.

Tyypilliset syyt:

• VPN-palvelimen osoite on kirjoitettu väärin (kyllä, tämä on yllättävän yleinen syy)
• Palomuuri estää tarvittavat portit
• VPN-tunnelin tyyppi on asetettu automaattiseksi eikä mikään protokolla onnistu
• Verkkoyhteys puuttuu kokonaan

Korjausohjeet:

1. Tarkista VPN-palvelimen osoite ensin — kirjoitusvirhe on syynä useammin kuin uskoisi
2. Testaa yhteys palvelimeen:

Test-NetConnection -ComputerName vpn.yritys.fi -Port 443
ping vpn.yritys.fi

3. Varmista, että UDP-portit 500 ja 4500 (IKEv2/IPsec) tai TCP-portti 443 (SSTP) ovat auki
4. Kokeile vaihtaa VPN-tunnelin tyyppi automaattisesta tiettyyn protokollaan (IKEv2 tai SSTP)

Virhe 809: Yhteyttä ei voida muodostaa paikallisen koneen ja VPN-palvelimen välille

Tämä virhe tarkoittaa, että etäpalvelin ei vastaa. Syynä on melkein aina jokin verkkolaite — reititin, palomuuri tai NAT — joka estää VPN-liikenteen.

Korjausohjeet:

1. Varmista, että UDP-portit 500 ja 4500 ovat auki kaikissa laitteissa asiakaskoneelta VPN-palvelimelle saakka
2. Tarkista, ettei IPsec ole estetty missään välipalomuurissa
3. Jos käytät L2TP:tä NATin takana, varmista NAT Traversal -tuki:

# Tarkista NAT-T-rekisteriasetus
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -ErrorAction SilentlyContinue

# Jos asetus puuttuu, lisää se (vaatii järjestelmänvalvojan oikeudet):
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -Value 2 -PropertyType DWORD -Force

# Käynnistä uudelleen muutosten aktivoimiseksi
Restart-Computer

Virhe 812: Todennusmenetelmä ei täsmää

Tämä virhe kertoo, että VPN-palvelimen ja asiakkaan todennusmenetelmät eivät ole linjassa. Erityisen yleinen Always On VPN -ympäristöissä, joissa NPS (Network Policy Server) on konfiguroitu väärin.

Korjausohjeet:

• Tarkista NPS-palvelimen todennusasetukset — PEAP-todennuksen tulee sallia sama menetelmä kuin VPN-profiilissa
• Varmista, ettei NPS-käytäntö vaadi sertifikaattipohjaista todennusta, jos asiakas käyttää EAP-MSCHAPv2:ta
• Tarkista NPS:n tapahtumaloki — tapahtuma 20276 paljastaa ristiriidan tarkan syyn

Virhe 13806: IKE ei löydä kelvollista konesertifikaattia

IKEv2-yhteys vaatii toimivan konesertifikaatin sekä palvelimella että asiakaskoneella. Jos sertifikaatti puuttuu tai on vanhentunut, saat tämän virheen. Oma kokemukseni on, että useimmiten syynä on yksinkertaisesti vanhentunut sertifikaatti, jota kukaan ei ole muistanut uusia.

Korjausohjeet:

1. Tarkista sertifikaattivarasto asiakaskoneella:

# Näytä koneen henkilökohtaiset sertifikaatit
certutil -store My

# Näytä luotetut juurisertifikaatit
certutil -store Root

# Tarkista sertifikaatin voimassaolo PowerShellillä
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, Thumbprint | Format-Table -AutoSize

2. Varmista, että VPN-palvelimen sertifikaatissa on Server Authentication Enhanced Key Usage -merkintä
3. Tarkista, että asiakaskoneella on juurisertifioijan (CA) juurisertifikaatti asennettuna
4. Varmista, että sertifikaatin nimi (Subject Name) vastaa VPN-palvelimen osoitetta

Virhe 13801: IKE-todennustiedot ovat virheelliset

Tämäkin liittyy sertifikaattien validointiin. Syitä voi olla useita:

• VPN-palvelimen konesertifikaatti on vanhentunut
• Sertifikaatissa ei ole Server Authentication -merkintää
• Asiakaskoneelta puuttuu juurisertifikaatti
• VPN-osoite ei vastaa sertifikaatin Subject Name -kenttää

Nopea tarkistus PowerShellillä:

# Tarkista VPN-palvelimen sertifikaatti etäyhteyden kautta
# (suorita VPN-palvelimella)
Get-ChildItem Cert:\LocalMachine\My | Where-Object {
    $_.EnhancedKeyUsageList.FriendlyName -contains "Server Authentication"
} | Select-Object Subject, NotAfter, Issuer | Format-List

Windows 11 24H2:n muutokset, jotka vaikuttavat VPN-yhteyksiin

Windows 11 versio 24H2 toi mukanaan useita muutoksia, jotka voivat aiheuttaa ihan odottamattomia VPN-ongelmia. Jos organisaatiosi on päivittänyt koneet 24H2-versioon ja VPN-ongelmat alkoivat sen jälkeen — tämä osio on sinua varten.

SMB-allekirjoitus on nyt pakollinen

Windows 11 24H2 vaatii oletuksena SMB-allekirjoituksen (SMB signing) kaikissa yhteyksissä. Käytännössä tämä voi aiheuttaa yhteysongelmia VPN:n yli jaettuihin verkkolevyasemiin, jos palvelinpuoli ei tue allekirjoitusta.

Oireet: VPN-yhteys muodostuu normaalisti, mutta verkkolevyasemat eivät toimi tai ovat tuskallisen hitaita.

Ratkaisu: Päivitä tiedostopalvelin tukemaan SMB-allekirjoitusta tai ota ominaisuus väliaikaisesti pois käytöstä ryhmäkäytännöllä:

# Tarkista SMB-allekirjoituksen tila
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

# Jos tarvitset väliaikaisen ohituksen (EI suositella pysyväksi ratkaisuksi):
Set-SmbClientConfiguration -RequireSecuritySignature $false -Force

NTLMv1 poistettu käytöstä

NTLMv1-protokolla on poistettu kokonaan Windows 11 24H2:sta. Jos VPN-palvelimesi tai sen takana oleva palvelu käyttää vielä NTLMv1-todennusta, yhteys yksinkertaisesti ei onnistu.

Ratkaisu: Siirry NTLMv2-todennukseen tai (vielä parempi) Kerberos-pohjaiseen todennukseen. Kannattaa tarkistaa NTLMv1-riippuvuudet auditointilokista ennen kuin päivität tuotantokoneita.

Palomuurisääntöjen muutokset

Windows 11 24H2 muutti myös oletuspalomuurisääntöjä: uusi "Tiedoston ja tulostimen jakaminen (rajoitettu)" -ryhmä ei enää sisällä NetBIOS-portteja 137–139. Tämä voi näkyä siinä, että vanhoihin verkkoresursseihin ei pääse VPN:n kautta kuten ennen.

Always On VPN — konfigurointi ja vianmääritys

Always On VPN on Microsoftin suosittelema ratkaisu yritysympäristöihin. Idea on yksinkertainen: VPN-yhteys muodostuu automaattisesti ilman käyttäjän toimenpiteitä. Se korvaa vanhan DirectAccess-teknologian ja on rehellisesti sanottuna paljon joustavampi vaihtoehto.

Always On VPN:n keskeiset ominaisuudet

• Automaattinen yhdistäminen: VPN käynnistyy automaattisesti käyttäjän kirjautuessa sisään, verkon vaihtuessa tai näytön käynnistyessä
• Sovellustriggerit: Voidaan konfiguroida käynnistymään tietyn sovelluksen avautuessa
• Nimipohjaiset triggerit: VPN aktivoituu, kun tietty verkkotunnus ratkaistaan DNS:llä
• Luotetun verkon tunnistus: VPN ei muodosta yhteyttä, kun laite on jo yritysverkossa (tämä säästää paljon turhia tikettejä)
• IKEv2-tuki: Nopea uudelleenkytkentä verkon vaihtuessa

Always On VPN:n yleisimmät ongelmat

Nämä ongelmat toistuvat Always On VPN -käyttöönotoissa kerta toisensa jälkeen:

1. VPN ei yhdistä automaattisesti kirjautumisen yhteydessä

Tarkista nämä:

• VPN-profiili on otettu käyttöön oikeassa kontekstissa (käyttäjätunneli vs. laitetunneli)
• "Anna sovellusten käyttää tätä VPN-yhteyttä automaattisesti" on valittuna asetuksissa
• AppData-kansion uudelleenohjausta ei ole käytössä — tämä on yllättävän yleinen syyllinen, joka estää automaattisen kytkeytymisen

2. Microsoft Entra Conditional Access -ongelma

Jos käyttäjä saa virheilmoituksen "Hups, et pääse tähän vielä", kyseessä on Conditional Access -käytännön ongelma. Tarkista seuraavat:

# Tarkista VPN-profiilin konfiguraatio
Get-WmiObject -Class MDM_VPNv2_01 -Namespace root\cimv2\mdm\dmmap

# Tarkista, että sertifikaatissa on AAD Conditional Access EKU
certutil -store -user My | findstr "AAD"

• Varmista, että VPN-profiilin TLSExtensions-osiossa on AAD Conditional Access EKU (OID: 1.3.6.1.4.1.311.87)
• Tarkista, ettei käyttäjän henkilökohtaisessa sertifikaattivarastossa ole ylimääräisiä Client Authentication -sertifikaatteja — ne saattavat aiheuttaa konflikteja

3. NPS-palvelin hylkää todennuspyynnöt

Tarkista NPS-lokitiedostot:

# NPS-lokien oletussijainti
Get-Content "$env:SystemRoot\System32\Logfiles\IN*.txt" | Select-Object -Last 50

# Tai tarkista tapahtumaloki
Get-WinEvent -LogName "Security" -FilterXPath "*[System[EventID=6273]]" -MaxEvents 10 | Format-List

Yleisimmät NPS-hylkäyssyyt (joihin itse olen törmännyt):

• Käyttäjä ei kuulu VPN Users -ryhmään
• RADIUS-jaettu salaisuus ei täsmää VPN-palvelimen ja NPS:n välillä
• Verkkokäytäntö on konfiguroitu väärin

VPN-vianmäärityksen PowerShell-työkalupakki

Tässä on kokoelma PowerShell-komentoja, joita itse käytän lähes päivittäin VPN-ongelmien selvittämiseen. Kannattaa tallentaa nämä jonnekin helposti saataville — ne todella säästävät aikaa.

Diagnostiikkaskripti: VPN-yhteyden tarkistus

# VPN-yhteyden diagnostiikkaskripti
# Suorita PowerShell-konsolissa järjestelmänvalvojana

Write-Host "=== VPN-diagnostiikka ===" -ForegroundColor Cyan

# 1. Listaa kaikki VPN-yhteydet
Write-Host "`n--- VPN-yhteydet ---" -ForegroundColor Yellow
Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, ConnectionStatus, AuthenticationMethod | Format-Table -AutoSize

# 2. Tarkista RAS-palveluiden tila
Write-Host "--- RAS-palvelut ---" -ForegroundColor Yellow
Get-Service -Name "RasMan", "SstpSvc", "IKEEXT" | Select-Object Name, Status, StartType | Format-Table -AutoSize

# 3. Tarkista verkkoliitännät
Write-Host "--- Aktiiviset verkkoliitännät ---" -ForegroundColor Yellow
Get-NetAdapter | Where-Object {$_.Status -eq "Up"} | Select-Object Name, InterfaceDescription, Status, LinkSpeed | Format-Table -AutoSize

# 4. Tarkista DNS-asetukset
Write-Host "--- DNS-konfiguraatio ---" -ForegroundColor Yellow
Get-DnsClientServerAddress -AddressFamily IPv4 | Where-Object {$_.ServerAddresses} | Select-Object InterfaceAlias, ServerAddresses | Format-Table -AutoSize

# 5. Tarkista palomuurisäännöt VPN-porteille
Write-Host "--- VPN-palomuurisäännöt ---" -ForegroundColor Yellow
Get-NetFirewallRule -Direction Outbound | Where-Object {$_.DisplayName -match "VPN|IKE|SSTP|L2TP"} | Select-Object DisplayName, Enabled, Action | Format-Table -AutoSize

Write-Host "`nDiagnostiikka valmis." -ForegroundColor Green

VPN-yhteyden uudelleenkäynnistys

# Katkaise ja muodosta VPN-yhteys uudelleen
$vpnName = "YritysVPN"  # Vaihda VPN-yhteyden nimi

# Katkaise yhteys
rasdial $vpnName /disconnect

# Odota 5 sekuntia
Start-Sleep -Seconds 5

# Käynnistä RAS-palvelut uudelleen
Restart-Service -Name RasMan -Force
Restart-Service -Name IKEEXT -Force

# Yhdistä uudelleen
rasdial $vpnName

VPN-tapahtumalokin lukeminen

# Hae viimeisimmät VPN-tapahtumat (RasClient)
Get-WinEvent -LogName "Application" -FilterXPath "*[System[Provider[@Name='RasClient']]]" -MaxEvents 20 | 
    Select-Object TimeCreated, Id, Message | 
    Format-List

Split Tunnel vs. Force Tunnel — kumpi on parempi valinta?

VPN-reitityksessä on kaksi peruslähestymistapaa. Oikea valinta vaikuttaa merkittävästi sekä käyttökokemukseen että turvallisuuteen, joten tähän kannattaa käyttää hetki aikaa.

Split Tunnel (jaettu tunneli)

Vain yritysverkon liikenne kulkee VPN:n kautta. Muu internet-liikenne (YouTube, Teams-puhelut, päivitykset) käyttää suoraa internet-yhteyttä.

Edut: Nopeampi käyttökokemus, vähemmän kuormaa VPN-palvelimelle, Teams-puhelut toimivat huomattavasti paremmin.

Haitat: Käyttäjän internet-liikenne ei kulje yrityksen suojausten läpi.

Force Tunnel (pakotettu tunneli)

Kaikki liikenne — myös tavallinen internet-selailu — kulkee VPN:n kautta yritysverkon palomuurin läpi.

Edut: Täysi kontrolli kaikesta liikenteestä, DLP- ja web-suodatusratkaisut toimivat.

Haitat: Hitaampi käyttökokemus ja enemmän kuormaa VPN-palvelimelle.

Suositus vuodelle 2026

Useimmat organisaatiot ovat jo siirtyneet Split Tunnel -malliin, erityisesti Microsoft 365 -liikenteen optimoimiseksi. Microsoft itse suosittelee, että Teams- ja Office 365 -liikenne ohjataan suoraan internetiin ilman VPN-tunnelia. Puheluiden laatu paranee ja viive vähenee merkittävästi. Omasta mielestäni tämä on oikea suunta — Force Tunnel tuntuu nykypäivänä turhan raskaalta ratkaisulta useimmille organisaatioille.

SMB over QUIC — VPN:n vaihtoehto tiedostopalvelimille

Mielenkiintoinen kehityssuunta vuodelle 2026: SMB over QUIC mahdollistaa turvallisen tiedostopalvelinyhteyden ilman VPN:ää. QUIC käyttää sertifikaattipohjaista salausta ja toimii UDP-portin 443 kautta.

Jos organisaatiosi käyttää VPN:ää pääasiassa tiedostopalvelimille pääsyyn, tämä voi olla yksinkertaisempi ja nopeampi ratkaisu. Se ei korvaa VPN:ää kokonaan (sisäisiin web-sovelluksiin et pääse ilman sitä), mutta tiedostojakojen osalta se on ehdottomasti varteenotettava vaihtoehto.

Vaatimukset:

• Windows Server 2025 tai Windows Server 2022 Azure Edition tiedostopalvelimena
• Windows 11 asiakaskoneissa
• TLS-sertifikaatti tiedostopalvelimella

Vianmäärityksen pikaopas IT-helpdeskille

Tässä on nopea tarkistuslista siihen hetkeen, kun käyttäjä ilmoittaa VPN-ongelmasta. Käy nämä läpi järjestyksessä — yleensä ongelma löytyy jo ensimmäisten kohtien aikana.

1. Internet-yhteys: Toimiiko internet ilman VPN:ää? Pyydä käyttäjää avaamaan selain ja testaamaan. Jos ei toimi, ongelma ei ole VPN:ssä.
2. VPN-palvelimen osoite: Onko osoite kirjoitettu oikein? Kopioi ja liitä, älä kirjoita käsin.
3. Virhekoodi: Mikä virhekoodi näkyy? Tarkista tämän oppaan virhekoodiosiosta.
4. Palvelut: Ovatko RasMan- ja IKEEXT-palvelut käynnissä?
5. Palomuuri: Tarkista paikalliset ja verkon palomuurisäännöt — UDP 500, 4500 ja TCP 443 pitää olla auki.
6. Sertifikaatit: Ovatko konesertifikaatti ja juurisertifikaatti voimassa ja oikein asennettu?
7. Päivitykset: Onko äskettäinen Windows-päivitys aiheuttanut ongelman? Tarkista päivityshistoria.
8. Profiili: Yritä poistaa VPN-profiili ja luoda se uudelleen — joskus profiili yksinkertaisesti korruptoituu eikä sille voi mitään.

Usein kysytyt kysymykset

Miksi VPN-yhteys katkeaa jatkuvasti Windows 11:ssä?

Jatkuvat katkokset johtuvat yleensä joko verkkoliitännän virransäästöasetuksista tai IKEv2-yhteyden aikakatkaisusta. Tarkista ensin, ettei Windows sammuta verkkokorttia virransäästön vuoksi: Laitehallinta → Verkkokortit → Ominaisuudet → Virranhallinta → poista valinta kohdasta "Salli tietokoneen sammuttaa tämä laite virran säästämiseksi". IKEv2-yhteyden timeout-arvoja voi säätää rekisteristä polusta HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters.

Mitä portteja VPN tarvitsee palomuurissa?

Se riippuu protokollasta. IKEv2/IPsec vaatii UDP 500 ja 4500. SSTP käyttää TCP 443. L2TP/IPsec vaatii UDP 500, 4500 ja 1701. PPTP käyttää TCP 1723 ja GRE-protokollaa (IP-protokolla 47). Suositeltavin yhdistelmä on IKEv2 (UDP 500/4500) ja varaprotokollana SSTP (TCP 443).

Voiko Windows 11:n sisäänrakennettu VPN korvata kolmannen osapuolen VPN-ohjelmiston?

Monissa tapauksissa kyllä. Windows 11 tukee IKEv2:ta, SSTP:tä, L2TP:tä ja PPTP:tä suoraan. Always On VPN tarjoaa automaattisen yhteydenmuodostuksen, sovelluskohtaisen VPN:n ja Conditional Access -integraation. Jos yrityksesi käyttää Windows-palvelininfrastruktuuria, sisäänrakennettu ratkaisu on usein riittävä — ja rehellisesti sanottuna yksinkertaisempi hallita Intunella tai ryhmäkäytännöillä kuin monien kolmannen osapuolen VPN-ohjelmistojen kanssa.

Miten testaan VPN-yhteyden toimivuuden komentoriviltä?

Käytä PowerShellin Test-NetConnection-komentoa: Test-NetConnection -ComputerName vpn.yritys.fi -Port 443 SSTP:lle tai Test-NetConnection -ComputerName vpn.yritys.fi -Port 500 -InformationLevel Detailed IKEv2:lle. VPN:n yli voit testata sisäverkon resursseja komennolla Test-NetConnection -ComputerName sisainen-palvelin.yritys.local -Port 445.

Mikä on Always On VPN ja miten se eroaa tavallisesta VPN-yhteydestä?

Always On VPN muodostaa VPN-tunnelin automaattisesti ilman, että käyttäjän tarvitsee tehdä mitään. Se aktivoituu kirjautumisen, verkon vaihtumisen tai näytön käynnistymisen yhteydessä. Tavallinen VPN vaatii aina manuaalisen yhdistämisen. Always On VPN tukee myös laitetunnelia (yhteys ennen kirjautumista), sovelluskohtaisia triggereitä ja luotetun verkon tunnistusta. Se on Microsoftin suosittelema ratkaisu yritysympäristöihin ja korvaa vanhan DirectAccess-teknologian.