Fejlfinding 12 min læsning

VPN fejlfinding i Windows 11 for helpdesk — den komplette guide til 2026

VPN-problemer er en af de hyppigste helpdesk-henvendelser i 2026, især efter KB5074109-opdateringen. Denne guide dækker de mest almindelige fejlkoder (720, 789, 809, 812, 13801), Always On VPN-problemer, split tunneling og et komplet PowerShell-diagnostikscript.

Editorial Team

VPN-problemer i 2026 — velkommen til hverdagen

Hvis du sidder på en IT-helpdesk i 2026, så ved du det allerede: VPN-tickets er som ukrudt. Du kan rydde bunken, og næste morgen er der ti nye. Især efter Microsofts januar-opdatering KB5074109 har vi set en nærmest eksplosiv stigning i VPN-relaterede henvendelser. Brugere der pludselig ikke kan forbinde, tunneler der dropper midt i et Teams-opkald, og fejlkoder der virker som om de er genereret af en tilfældighedsgenerator.

Denne guide er til dig. Dig der sidder i frontlinjen og skal have folk online igen — hurtigt og uden alt for meget drama. Vi gennemgår de mest almindelige VPN-fejlkoder i Windows 11, dykker ned i Always On VPN-problemer, ser på split tunneling-konfiguration og slutter af med et PowerShell-diagnostikscript, du kan smide direkte ind i dit workflow.

Ingen akademisk teori. Bare det der virker i praksis.

Del 1: De klassiske VPN-fejlkoder i Windows 11

Windows 11's indbyggede VPN-klient er... ja, den er funktionel. Det er nok det pæneste man kan sige. Når den fejler, giver den dig som regel en fejlkode, og det er faktisk ret nyttigt — hvis man altså ved hvad koderne betyder. Her er de hyppigste vi ser på helpdesk i 2026.

Fejlkode 720 — forbindelsen kunne ikke oprettes

Denne her er en klassiker. Fejl 720 betyder typisk, at der er et problem med PPP-forhandlingen mellem klienten og serveren. I praksis ser vi den oftest, når WAN Miniport-driverne er korrupte eller når der er en IP-adressekonflikt.

Sådan fikser du det:

  1. Nulstil WAN Miniport-adapterne via Enhedshåndtering
  2. Geninstaller TCP/IP-stakken
  3. Tjek at DHCP-puljen på VPN-serveren ikke er udtømt (det sker oftere end man tror)
# Nulstil netværksadapterne
netsh int ip reset
netsh winsock reset

# Genstart WAN Miniport via PowerShell
Get-PnpDevice | Where-Object {$_.FriendlyName -like "*WAN Miniport*"} | ForEach-Object {
    Disable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false
    Start-Sleep -Seconds 2
    Enable-PnpDevice -InstanceId $_.InstanceId -Confirm:$false
}

# Genstart maskinen bagefter — ja, det er nødvendigt
Restart-Computer -Force

Pro tip: Hvis fejl 720 dukker op på flere maskiner samtidig, så kig på serverens DHCP-scope først. Ni ud af ti gange er puljen løbet tør, og det sparer dig for en masse unødig fejlfinding på klientsiden.

Fejlkode 789 — L2TP/IPsec-forbindelsen fejlede

Fejl 789 er den, der får nye helpdesk-medarbejdere til at svede. Den lyder dramatisk, men årsagen er som regel en af tre ting:

  • IPsec-tjenesten kører ikke (eller er crashet)
  • Den foruddelte nøgle (PSK) er forkert
  • NAT-T er ikke konfigureret korrekt — og dette er langt den hyppigste årsag i 2026

Hvis brugeren sidder bag en NAT-router (og det gør de næsten altid, når de arbejder hjemmefra), skal du sikre dig, at denne registry-nøgle er sat:

# Aktiver NAT-Traversal for L2TP/IPsec
reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 2 /f

# Genstart IPsec-tjenesten
Restart-Service -Name PolicyAgent -Force

# Og genstart IKEEXT for en god ordens skyld
Restart-Service -Name IKEEXT -Force

Værdien 2 betyder, at Windows tillader NAT-T selv når både klient og server er bag NAT. Det er den mest kompatible indstilling, og ærligt talt burde det være standard i 2026. Men det er det ikke. Klassisk Microsoft.

Fejlkode 809 — serveren svarer ikke

Fejl 809 er frustrerende, fordi den bare siger "serveren svarer ikke" uden at fortælle dig hvorfor. Det kan være alt fra en firewall der blokerer trafik til en server der er nede. Her er den systematiske tilgang:

  1. Tjek firewall-regler: UDP port 500, UDP port 4500 og ESP-protokol (IP protocol 50) skal være åbne
  2. Verificer serveren: Kan du pinge den? Svarer den på port 443 hvis det er SSTP?
  3. Tjek certifikater: Hvis I bruger certifikatbaseret autentificering, er certifikatet udløbet?
# Test om VPN-serveren svarer på de relevante porte
Test-NetConnection -ComputerName vpn.dinvirksomhed.dk -Port 443
Test-NetConnection -ComputerName vpn.dinvirksomhed.dk -Port 500 -InformationLevel Detailed

# Tjek Windows Firewall-regler for VPN
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*IKE*" -or $_.DisplayName -like "*IPsec*"} | Format-Table DisplayName, Enabled, Direction, Action

Helt ærligt — i min erfaring er fejl 809 i 80% af tilfældene en firewall-problemstilling. Enten brugerens hjemmerouter, virksomhedens firewall, eller (min personlige favorit) en nyligt opdateret firewall-regel som ingen husker at have ændret.

Fejlkode 812 — serveren afviste forbindelsen

Denne er anderledes end de andre, fordi den faktisk kommer fra serveren. Fejl 812 betyder, at din VPN-server aktivt har afvist forbindelsesforsøget — typisk på grund af en policy-mismatch.

De hyppigste årsager:

  • Brugeren er ikke medlem af den korrekte AD-gruppe, der har VPN-adgang
  • NPS (Network Policy Server) har en policy der ikke matcher klientens autentificeringsmetode
  • Tunneltype-mismatch mellem klient og server (brugeren prøver IKEv2, serveren forventer SSTP)
# Tjek brugerens gruppetilhørsforhold (kør på domain controller eller med RSAT)
Get-ADUser -Identity "brugernavn" -Properties MemberOf | Select-Object -ExpandProperty MemberOf

# Tjek NPS-loggen for afvisningsårsagen
Get-WinEvent -LogName "Security" -FilterXPath "*[System[(EventID=6273)]]" -MaxEvents 10 | Format-List TimeCreated, Message

Fejl 812 er næsten altid et server-side problem. Spar dig selv for tid og start med at tjekke NPS-loggen — den fortæller dig præcis hvorfor forbindelsen blev afvist. Hvis du ikke har adgang til serveren, så eskaler med det samme. Der er ingen mening i at rode rundt på klientsiden.

Fejlkode 13801 — IKEv2-certifikatfejl

Fejl 13801 er relativt ny i vores fejlfindingsværktøjskasse og dukker primært op med IKEv2-forbindelser. Den betyder, at certifikatvalideringen fejlede under IKE-forhandlingen.

Typiske årsager:

  • Serverens certifikat indeholder ikke den korrekte EKU (Enhanced Key Usage) — det skal have "IP security IKE intermediate"
  • Certifikatets CN eller SAN matcher ikke det servernavn, klienten forbinder til
  • Rod-CA'en er ikke i klientens Trusted Root Certification Authorities-store
  • Certifikatet er udløbet (ja, det sker stadig — deprimerende ofte)
# Tjek certifikater i maskinens certifikatstore
Get-ChildItem Cert:\LocalMachine\Root | Where-Object {$_.Subject -like "*VPN*" -or $_.Subject -like "*CA*"} | Format-Table Subject, NotAfter, Thumbprint

# Verificer serverens certifikat
$cert = Test-NetConnection -ComputerName vpn.dinvirksomhed.dk -Port 443 -InformationLevel Detailed
# Eller brug openssl hvis det er tilgængeligt:
# openssl s_client -connect vpn.dinvirksomhed.dk:443 -showcerts

# Tjek CRL-tilgængelighed
certutil -verify -urlfetch servercert.cer

En hurtig advarsel: efter KB5074109-opdateringen har vi set tilfælde, hvor certifikat-cachen bliver korrupt. Hvis alt ser rigtigt ud, men forbindelsen stadig fejler med 13801, så prøv at rydde certifikat-cachen:

# Ryd IKEv2 certifikat-cache
certutil -urlcache * delete
ipconfig /flushdns
Restart-Service -Name IKEEXT -Force

Del 2: Always On VPN — når det "altid tændte" slukker

Always On VPN er Microsofts afløser for DirectAccess, og i teorien er det en elegant løsning: brugeren forbinder automatisk til VPN, når de er udenfor virksomhedsnetværket. I praksis? Det er en konfigurationsmæssig rædsel, der kan give selv erfarne netværksfolk grå hår.

Profilinstallationsfejl

Det allerførste sted, hvor ting kan gå galt, er ved installation af VPN-profilen. Always On VPN bruger ProfileXML, der skal deployes via Intune, SCCM eller PowerShell. Og det XML... ja, det er følsomt.

De mest almindelige profilfejl:

  • Forkert XML-formatering (et enkelt manglende tag, og hele profilen afvises)
  • Forkerte DNS-suffixer i profilen
  • Certifikatreferencen i profilen matcher ikke det faktisk installerede certifikat
# Tjek om VPN-profilen er korrekt installeret
Get-VpnConnection -AllUserConnection | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod

# Se den rå profil-XML
$vpn = Get-VpnConnection -AllUserConnection -Name "AlwaysOnVPN"
$vpn | Format-List *

# Tjek event-loggen for profilinstallationsfejl
Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational" -MaxEvents 20 | Where-Object {$_.LevelDisplayName -eq "Error"} | Format-List TimeCreated, Message

Et lille trick jeg har lært den hårde vej: test altid din ProfileXML i en online XML-validator, før du deployer den. Det lyder banalt, men det havde sparet mig for adskillige timer i 2025.

Device Tunnel vs. User Tunnel

Always On VPN understøtter to tunneltyper, og det er vigtigt at forstå forskellen:

  • Device Tunnel: Opretter forbindelse før brugerlogin. Bruges til domæneautentificering og maskinpolitikker. Kræver IKEv2 og certifikatbaseret maskinautentificering.
  • User Tunnel: Opretter forbindelse efter brugerlogin. Understøtter IKEv2, SSTP og flere autentificeringsmetoder.

Problemet? De to tunneler kan konflikte med hinanden, især hvis routingtabellerne overlapper. Det er som at have to GPS'er i bilen der peger i hver sin retning.

# Tjek aktive VPN-tunneler
Get-VpnConnection -AllUserConnection | Select-Object Name, ConnectionStatus, TunnelType
rasdial

# Se routingtabellen for at finde konflikter
Get-NetRoute | Where-Object {$_.InterfaceAlias -like "*VPN*"} | Sort-Object DestinationPrefix | Format-Table DestinationPrefix, NextHop, RouteMetric, InterfaceAlias

# Tjek Device Tunnel specifikt (kører som SYSTEM)
$taskResult = schtasks /query /tn "VPN Device Tunnel" 2>&1
if ($LASTEXITCODE -eq 0) { Write-Output "Device Tunnel task exists" } else { Write-Output "No Device Tunnel task found" }

KB5074109 og Always On VPN — den perfekte storm

Her kommer vi til det, som mange af jer nok har oplevet de seneste måneder. Microsofts januar 2026-opdatering KB5074109 introducerede ændringer i kryptografi-stakken, der direkte påvirker IKEv2-forhandlinger. Resultatet? Always On VPN-forbindelser der dropper tilfældigt, eller som slet ikke kan etableres.

Symptomerne:

  • VPN-forbindelsen dropper efter 5-30 minutter
  • Event log viser fejl 13801 eller 809 i RasClient-loggen
  • Problemet opstod pludselig efter opdateringsinstallation

Løsningen:

  1. Installer den kumulative opdatering KB5077744 (den retter de kryptografiske ændringer)
  2. Hvis du ikke kan patche med det samme, kan du midlertidigt deaktivere den problematiske kryptografiændring:
# Midlertidig workaround for KB5074109 VPN-problemer
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers" /v DisableCapiOverrideForRSA /t REG_DWORD /d 0 /f

# Genstart IKE-relaterede tjenester
Restart-Service -Name IKEEXT -Force
Restart-Service -Name PolicyAgent -Force
Restart-Service -Name RasMan -Force

# Vigtigt: Denne workaround er midlertidig!
# Registry-nøglen fjernes i opdateringer planlagt til april 2026

Personligt har jeg set dette problem ramme mindst 30-40% af de virksomheder, jeg har arbejdet med i Q1 2026. Hvis din Always On VPN pludselig begyndte at opføre sig mærkeligt i januar, er KB5074109 næsten garanteret synderen.

Del 3: Split tunneling — balancen mellem sikkerhed og brugervenlighed

Split tunneling er et af de emner, hvor IT-sikkerhed og brugeroplevelse støder direkte sammen. Skal al trafik gå gennem VPN (fuld tunnel), eller skal kun virksomhedstrafik routes gennem VPN, mens resten går direkte ud på internettet (split tunnel)?

Svaret er: det kommer an på. (Jeg ved godt, det er det mest frustrerende svar i IT, men det er nu engang sandheden.)

Konfiguration af split tunneling i Windows 11

Windows 11 understøtter split tunneling via både GUI og PowerShell. PowerShell giver dig langt mere kontrol, så lad os starte der:

# Aktiver split tunneling på en eksisterende VPN-forbindelse
Set-VpnConnection -Name "Virksomheds-VPN" -SplitTunneling $true

# Tilføj specifikke routes der skal gå gennem VPN
Add-VpnConnectionRoute -ConnectionName "Virksomheds-VPN" -DestinationPrefix "10.0.0.0/8"
Add-VpnConnectionRoute -ConnectionName "Virksomheds-VPN" -DestinationPrefix "172.16.0.0/12"
Add-VpnConnectionRoute -ConnectionName "Virksomheds-VPN" -DestinationPrefix "192.168.1.0/24"

# Verificer konfigurationen
Get-VpnConnection -Name "Virksomheds-VPN" | Select-Object Name, SplitTunneling
(Get-VpnConnection -Name "Virksomheds-VPN").Routes

Force tunneling med undtagelser

En hybrid-tilgang, som mange virksomheder vælger i 2026, er force tunneling med specifikke undtagelser — typisk for Microsoft 365-trafik og andre cloud-tjenester, der alligevel er krypterede.

# Force tunnel med undtagelser for M365
Set-VpnConnection -Name "Virksomheds-VPN" -SplitTunneling $false

# Tilføj undtagelser for Microsoft 365 optimize-endpoints
# Disse IP-ranges er fra Microsofts officielle endpoint-liste (marts 2026)
$m365Endpoints = @(
    "13.107.6.152/31",
    "13.107.18.10/31",
    "13.107.128.0/22",
    "23.103.160.0/20",
    "40.96.0.0/13",
    "40.104.0.0/15",
    "52.96.0.0/14",
    "131.253.33.215/32",
    "132.245.0.0/16",
    "150.171.32.0/22",
    "204.79.197.215/32"
)

foreach ($prefix in $m365Endpoints) {
    Add-VpnConnectionRoute -ConnectionName "Virksomheds-VPN" -DestinationPrefix $prefix -PassThru
}

# Tilføj Teams media-trafik (vigtigt for opkaldskvalitet)
$teamsMedia = @("13.107.64.0/18", "52.112.0.0/14", "52.120.0.0/14")
foreach ($prefix in $teamsMedia) {
    Add-VpnConnectionRoute -ConnectionName "Virksomheds-VPN" -DestinationPrefix $prefix -PassThru
}

Det her er i øvrigt en af de konfigurationer, der gør størst forskel for brugertilfredsheden. Brugere der sidder på fuld tunnel klager konstant over langsomme Teams-opkald og træg internetadgang. Med split tunneling for M365 forsvinder de fleste af de klager. Det er en af de hurtigste "wins" du kan opnå som helpdesk.

DNS-konfiguration ved split tunneling

Her er noget, som mange glemmer: når du aktiverer split tunneling, skal du også tænke over DNS. Ellers ender du med brugere, der kan nå interne ressourcer via IP, men ikke via hostname. Irriterende.

# Konfigurer DNS for split tunnel
# Sæt virksomhedens DNS-servere kun for virksomhedsdomæner
$vpnAdapter = Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*VPN*"}

# Tilføj NRPT-regler (Name Resolution Policy Table)
Add-DnsClientNrptRule -Namespace ".dinvirksomhed.dk" -NameServers "10.0.0.1","10.0.0.2"
Add-DnsClientNrptRule -Namespace ".intern.local" -NameServers "10.0.0.1"

# Verificer NRPT-regler
Get-DnsClientNrptRule | Format-Table Namespace, NameServers

Del 4: Diagnostik med PowerShell — automatiser fejlfindingen

Okay, nu til den sjove del. (Ja, PowerShell-scripts kan være sjove. Døm mig ikke.) Her er et diagnostikscript, du kan bruge til hurtigt at indsamle al relevant VPN-information fra en brugers maskine. Du kan køre det remote via PowerShell Remoting eller bede brugeren køre det lokalt.

Det komplette VPN-diagnostikscript

#Requires -RunAsAdministrator
# VPN-Diagnostik.ps1 — Komplet VPN-fejlfindingsscript for Windows 11
# Version 2.1 — Marts 2026

param(
    [string]$VpnName = "*",
    [string]$OutputPath = "$env:TEMP\VPN-Diagnostik-$(Get-Date -Format 'yyyyMMdd-HHmmss').txt"
)

function Write-Section {
    param([string]$Title)
    $separator = "=" * 60
    "`n$separator`n  $Title`n$separator" | Tee-Object -FilePath $OutputPath -Append
}

# System information
Write-Section "SYSTEMINFORMATION"
$os = Get-CimInstance Win32_OperatingSystem
$output = @"
Computernavn: $env:COMPUTERNAME
OS: $($os.Caption) Build $($os.BuildNumber)
Sidste opdatering: $((Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn)
"@
$output | Tee-Object -FilePath $OutputPath -Append

# Installed updates (VPN-relevant)
Write-Section "RELEVANTE INSTALLEREDE OPDATERINGER"
Get-HotFix | Where-Object {
    $_.HotFixID -in @("KB5074109", "KB5077744", "KB5078127")
} | Format-Table HotFixID, InstalledOn, Description | Tee-Object -FilePath $OutputPath -Append

# VPN connections
Write-Section "VPN-FORBINDELSER"
$vpnConnections = Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue
$vpnConnections += Get-VpnConnection -ErrorAction SilentlyContinue
$vpnConnections | Where-Object {$_.Name -like $VpnName} | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling, ConnectionStatus, IdleDisconnectSeconds | Tee-Object -FilePath $OutputPath -Append

# Network adapters
Write-Section "NETVÆRKSADAPTERE"
Get-NetAdapter | Where-Object {$_.Status -eq "Up" -or $_.InterfaceDescription -like "*VPN*" -or $_.InterfaceDescription -like "*WAN*"} | Format-Table Name, InterfaceDescription, Status, LinkSpeed | Tee-Object -FilePath $OutputPath -Append

# VPN-related services
Write-Section "VPN-RELATEREDE TJENESTER"
$services = @("RasMan", "IKEEXT", "PolicyAgent", "SstpSvc", "RasAuto", "RemoteAccess")
foreach ($svc in $services) {
    $service = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if ($service) {
        "$($service.DisplayName): $($service.Status)" | Tee-Object -FilePath $OutputPath -Append
    }
}

# Routing table
Write-Section "ROUTINGTABEL (VPN-relateret)"
Get-NetRoute | Where-Object {
    $_.InterfaceAlias -like "*VPN*" -or $_.DestinationPrefix -like "10.*" -or $_.DestinationPrefix -like "172.16.*" -or $_.DestinationPrefix -like "192.168.*"
} | Sort-Object DestinationPrefix | Format-Table DestinationPrefix, NextHop, RouteMetric, InterfaceAlias | Tee-Object -FilePath $OutputPath -Append

# DNS configuration
Write-Section "DNS-KONFIGURATION"
Get-DnsClientNrptRule | Format-Table Namespace, NameServers | Tee-Object -FilePath $OutputPath -Append
Get-DnsClientServerAddress | Where-Object {$_.ServerAddresses} | Format-Table InterfaceAlias, ServerAddresses | Tee-Object -FilePath $OutputPath -Append

# Certificate check
Write-Section "CERTIFIKATER (VPN-relevante)"
Get-ChildItem Cert:\LocalMachine\My | Where-Object {
    $_.EnhancedKeyUsageList.FriendlyName -contains "IP security IKE intermediate" -or
    $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"
} | Format-Table Subject, NotAfter, Thumbprint, @{N="EKU";E={$_.EnhancedKeyUsageList.FriendlyName -join ", "}} | Tee-Object -FilePath $OutputPath -Append

# NAT-T registry check
Write-Section "REGISTRY-INDSTILLINGER"
$natT = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent" -Name "AssumeUDPEncapsulationContextOnSendRule" -ErrorAction SilentlyContinue
$cryptoOverride = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Cryptography\Providers" -Name "DisableCapiOverrideForRSA" -ErrorAction SilentlyContinue
"NAT-T (AssumeUDPEncapsulationContextOnSendRule): $(if ($natT) { $natT.AssumeUDPEncapsulationContextOnSendRule } else { 'Ikke sat (standard: 0)' })" | Tee-Object -FilePath $OutputPath -Append
"CryptoOverride (DisableCapiOverrideForRSA): $(if ($cryptoOverride) { $cryptoOverride.DisableCapiOverrideForRSA } else { 'Ikke sat' })" | Tee-Object -FilePath $OutputPath -Append

# Recent VPN events
Write-Section "SENESTE VPN-HÆNDELSER (sidste 24 timer)"
$yesterday = (Get-Date).AddDays(-1)
Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational" -ErrorAction SilentlyContinue | Where-Object {$_.TimeCreated -gt $yesterday} | Select-Object -First 20 | Format-Table TimeCreated, LevelDisplayName, Id, Message -Wrap | Tee-Object -FilePath $OutputPath -Append

# Firewall rules
Write-Section "FIREWALL-REGLER (VPN/IKE/IPsec)"
Get-NetFirewallRule | Where-Object {
    ($_.DisplayName -like "*VPN*" -or $_.DisplayName -like "*IKE*" -or $_.DisplayName -like "*IPsec*") -and $_.Enabled -eq "True"
} | Format-Table DisplayName, Direction, Action, Profile | Tee-Object -FilePath $OutputPath -Append

Write-Section "DIAGNOSTIK AFSLUTTET"
"Rapport gemt: $OutputPath" | Tee-Object -FilePath $OutputPath -Append
Write-Host "`nRapport gemt til: $OutputPath" -ForegroundColor Green
Write-Host "Kopier filen og send den til din IT-afdeling for analyse." -ForegroundColor Yellow

Scriptet samler alt det, du normalt ville bruge 15-20 minutter på at tjekke manuelt, og pakker det ind i en pæn rapport. Du kan bede brugeren køre det (hvis de har admin-rettigheder), eller du kan køre det remote:

# Kør diagnostik remote på en brugers maskine
Invoke-Command -ComputerName "PC-BRUGERNAVN" -FilePath "\\server\scripts\VPN-Diagnostik.ps1" -ArgumentList "*","\\server\logs\vpn-diag.txt"

Del 5: Hurtig fejlfindingsguide — flowchartet

Til slut har jeg lavet en hurtig beslutningsguide, du kan bruge når en bruger ringer ind med VPN-problemer. Tænk på det som et flowchart i tekstform:

  1. Kan brugeren forbinde overhovedet?
    • Nej → Tjek fejlkoden (se Del 1)
    • Ja, men forbindelsen dropper → Gå til punkt 3
  2. Hvilken fejlkode får brugeren?
    • 720 → WAN Miniport/DHCP-problem
    • 789 → L2TP/NAT-T-problem
    • 809 → Firewall/port-blokering
    • 812 → NPS-policy/AD-gruppe
    • 13801 → Certifikatproblem
    • Ingen fejlkode → Kør diagnostikscriptet
  3. Forbindelsen dropper?
    • Er KB5074109 installeret uden KB5077744? → Installer KB5077744
    • Dropper efter præcis X minutter? → Tjek idle timeout-indstillinger
    • Dropper tilfældigt? → Tjek routingtabel for konflikter, kør diagnostikscriptet
  4. Forbindelsen er oppe, men interne ressourcer er utilgængelige?
    • Kan du pinge IP-adresser men ikke hostnames? → DNS/NRPT-problem
    • Kan du ikke pinge noget internt? → Split tunneling-routes mangler
    • Kun visse tjenester der ikke virker? → Tjek firewall-regler på serveren

Afsluttende tanker

VPN-fejlfinding i Windows 11 i 2026 er — lad os kalde det, hvad det er — en uundgåelig del af helpdesk-hverdagen. Men med de rigtige værktøjer og en systematisk tilgang behøver det ikke være en kamp hver gang. De vigtigste ting at huske:

  • Hold styr på dine opdateringer. KB5074109 uden KB5077744 er en opskrift på kaos.
  • NAT-T registry-nøglen for fejl 789 burde være standard på alle fjernarbejdsenheder.
  • Split tunneling med M365-undtagelser er en af de hurtigste måder at reducere VPN-klager på.
  • Automatiser din diagnostik med PowerShell-scriptet — det sparer dig tid hver eneste dag.

Og husk: når alt andet fejler, er der ingen skam i at genstarte. Både tjenester og maskiner. Nogen gange er det enkleste svar også det rigtige.

Om Forfatteren Editorial Team

Our team of expert writers and editors.

Relaterede Artikler