De ingebouwde VPN van Windows bereikt geen SSL-gateway van een leverancier: waarom

Windows levert vier tunneltypen mee, en een leveranciersgateway is er daar geen van. Richt je toch een ingebouwd profiel op zo’n gateway, dan mislukt de verbinding vóór de vraag om inloggegevens, meestal met de melding dat de verbinding door het lokale systeem is beëindigd. Die tekst is een signaal van een mismatch, geen diagnose. Het profieltype en de client die het protocol bezit moeten overeenkomen, en een van beide ontbreekt.

Vier typen en één dialoogvenster

Elk opgeslagen profiel draagt een tunneltype. De ingebouwde client accepteert PPTP, L2TP, IKEv2 en SSTP, plus een automatische modus die ze op volgorde probeert. Er is geen algemene SSL VPN-ingang, en je kunt er ook geen toevoegen via het dialoogvenster. Een leveranciersgateway spreekt zijn eigen applicatieprotocol over TLS, dat alleen de client van die leverancier implementeert.

De lijst is één opdracht verwijderd, en het loont hem vóór alle andere probleemoplossing te draaien, want hij kost een seconde en haalt een hele klasse verkeerde aannames weg:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Zegt het profiel SSTP en is de gateway geen RRAS-server, dan staat de mismatch al vast. Geen enkel certificaat- of firewallwerk verandert dat.

SSTP en leveranciers-TLS lijken op poort 443 op elkaar

SSTP verpakt een PPP-sessie in TLS en rijdt over TCP 443. In de Microsoft-stack wordt die beëindigd door RRAS, dat een servercertificaat presenteert dat de client valideert. Een apparaat van Fortinet, Citrix of Pulse beëindigt ook TLS op 443, en de portal opent in elke browser zonder klagen.

Die browsertest bewijst bereikbaarheid, niet compatibiliteit. Het sessieprotocol achter de portal is van de leverancier, en de ingebouwde client heeft er geen implementatie van. Of de leverancier een eigen client levert, vertelt je met welke helft van de mismatch je te maken hebt.

De omgekeerde verwarring komt ook voor. Een profiel dat als SSTP is ingesteld tegen een echte RRAS-server kan falen op certificaatvalidatie terwijl de portal in orde is, en dat is een certificaatprobleem en geen protocolprobleem.

Fouten die verschijnen voordat er een tunnel is

De codes uit de 800-serie worden gemeld voordat er een tunnel tot stand komt, daarom verplaatsen firewallregels ze zelden. Fout 812 is een beleid aan de serverkant dat de authenticatiemethode weigert die de client aanbood. Andere uit de reeks komen van de lokale verbindingsbeheerder en niet van het netwerk.

Schakel tracing in voordat je iets opnieuw opbouwt. De tracing noemt de fase die faalt, en een fasenaam is meer waard dan de tekst in het dialoogvenster:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Traces belanden onder de tracing-map en blijven daar tot je ze opruimt, dus schakel tracing daarna uit in plaats van het wekenlang te laten lopen.

Een verbonden profiel kan nog steeds alles stukmaken

Een profiel dat verbindt en daarna browsen, een lokale share of een container-engine stukmaakt, heeft een routeringsprobleem, geen tunnelprobleem. De standaardgateway is naar de tunnel verhuisd, dus elke bestemming gaat nu via een peer die hem misschien niet routeert.

Twee instellingen beslissen dit. De ene is de split-tunneling-eigenschap op het profiel. De andere is de optie per adapter om de standaardgateway op het externe netwerk te gebruiken, die onder de geavanceerde IPv4-instellingen staat.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Split tunneling aanzetten zonder routes toe te voegen levert een tunnel op die verbindt en niets bereikt. Het uitzetten zonder DNS te controleren levert interne namen op die naar openbare antwoorden resolven, omdat het eigen achtervoegsel en de servers van de adapter niet worden gebruikt.

Controleer de bekabeling, dan het type

Werk in deze volgorde, en stop wanneer een stap mislukt in plaats van alles tegelijk bij te stellen:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

De eerste opdracht scheidt bereikbaarheid van protocol. De tweede bevestigt wat het profiel beweert te zijn. De routetabel laat zien of de tunnel de standaardroute heeft overgenomen. De inbelopdracht meldt de eigen fout van de verbindingsbeheerder, die vaak duidelijker is dan het dialoogvenster.

Noteer het tunneltype, het gatewayproduct en de exacte fout in de ticket. De volgende persoon weet dan binnen een minuut of het een protocolmismatch, een certificaatfout of een routeringsbeslissing is, in plaats van te beginnen bij “de VPN werkt niet”.