Das integrierte Windows-VPN erreicht kein SSL-Gateway eines Anbieters: warum

Windows bringt vier Tunneltypen mit, und ein Anbietergateway ist keiner davon. Richtest du trotzdem ein integriertes Profil auf eines, scheitert die Verbindung vor der Abfrage der Anmeldedaten, meist mit der Meldung, die Verbindung sei vom lokalen System beendet worden. Dieser Text ist ein Signal für eine Fehlpaarung, keine Diagnose. Profiltyp und der Client, dem das Protokoll gehört, müssen zusammenpassen, und eines von beiden fehlt.

Vier Typen und ein Dialog

Jedes gespeicherte Profil trägt einen Tunneltyp. Der integrierte Client akzeptiert PPTP, L2TP, IKEv2 und SSTP, dazu einen automatischen Modus, der sie der Reihe nach probiert. Einen allgemeinen SSL-VPN-Eintrag gibt es nicht, und über den Dialog lässt sich keiner hinzufügen. Ein Anbietergateway spricht sein eigenes Anwendungsprotokoll über TLS, das nur der Client dieses Anbieters umsetzt.

Die Liste ist einen Befehl entfernt, und sie lohnt sich vor jeder weiteren Fehlersuche, weil sie eine Sekunde dauert und eine ganze Klasse falscher Annahmen beseitigt:

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

Sagt das Profil SSTP und ist das Gateway kein RRAS-Server, steht die Fehlpaarung bereits fest. Keine Zertifikats- oder Firewallarbeit ändert daran etwas.

SSTP und Anbieter-TLS sehen auf Port 443 gleich aus

SSTP packt eine PPP-Sitzung in TLS und fährt über TCP 443. Im Microsoft-Stack beendet RRAS sie, das ein Serverzertifikat vorzeigt, welches der Client prüft. Auch eine Appliance von Fortinet, Citrix oder Pulse beendet TLS auf 443, und ihr Portal öffnet sich in jedem Browser ohne Beanstandung.

Dieser Browsertest beweist Erreichbarkeit, nicht Kompatibilität. Das Sitzungsprotokoll hinter dem Portal gehört dem Anbieter, und der integrierte Client hat keine Umsetzung dafür. Ob der Anbieter einen eigenen Client liefert, sagt dir, mit welcher Hälfte der Fehlpaarung du es zu tun hast.

Die umgekehrte Verwechslung kommt auch vor. Ein als SSTP eingerichtetes Profil gegen einen echten RRAS-Server kann an der Zertifikatsprüfung scheitern, während das Portal in Ordnung ist, und das ist ein Zertifikatsproblem und kein Protokollproblem.

Fehler, die auftreten, bevor ein Tunnel existiert

Die Codes der 800er-Reihe werden gemeldet, bevor irgendein Tunnel steht, deshalb bewegen Firewallregeln sie selten. Fehler 812 ist eine serverseitige Richtlinie, die das vom Client angebotene Authentifizierungsverfahren ablehnt. Andere aus dem Bereich stammen vom lokalen Verbindungsmanager und nicht vom Netzwerk.

Schalte die Ablaufverfolgung ein, bevor du irgendetwas neu aufbaust. Die Ablaufverfolgung benennt die scheiternde Stufe, und ein Stufenname ist mehr wert als der Dialogtext:

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

Ablaufverfolgungen landen im Tracing-Verzeichnis und bleiben dort, bis du sie löschst, also schalte die Verfolgung danach ab, statt sie wochenlang laufen zu lassen.

Ein verbundenes Profil kann trotzdem alles kaputt machen

Ein Profil, das sich verbindet und dann Surfen, eine lokale Freigabe oder eine Container-Engine kaputt macht, hat ein Routingproblem, kein Tunnelproblem. Das Standardgateway ist in den Tunnel gewandert, also geht jedes Ziel jetzt über einen Peer, der es womöglich nicht weiterleitet.

Zwei Einstellungen entscheiden das. Die eine ist die Split-Tunneling-Eigenschaft des Profils. Die andere ist die Option pro Adapter, das Standardgateway im Remotenetzwerk zu verwenden, die unter den erweiterten IPv4-Einstellungen liegt.

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

Split Tunneling einzuschalten, ohne Routen hinzuzufügen, ergibt einen Tunnel, der sich verbindet und nichts erreicht. Es auszuschalten, ohne DNS zu prüfen, ergibt interne Namen, die zu öffentlichen Antworten auflösen, weil Suffix und Server des Adapters nicht genutzt werden.

Prüfe die Verkabelung, dann den Typ

Arbeite in dieser Reihenfolge und halte an, wenn ein Schritt scheitert, statt alles gleichzeitig zu verstellen:

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

Der erste Befehl trennt Erreichbarkeit vom Protokoll. Der zweite bestätigt, was das Profil zu sein behauptet. Die Routentabelle zeigt, ob der Tunnel die Standardroute übernommen hat. Der Wählbefehl meldet den eigenen Fehler des Verbindungsmanagers, der oft klarer ist als der Dialog.

Notiere Tunneltyp, Gatewayprodukt und den genauen Fehler im Ticket. Die nächste Person weiß dann binnen einer Minute, ob es eine Protokollfehlpaarung, ein Zertifikatsfehler oder eine Routingentscheidung ist, statt mit „das VPN funktioniert nicht“ zu beginnen.