Windows built-in VPN cannot reach a vendor SSL gateway: why

Four tunnel types ship with Windows, and a vendor SSL gateway is not one of them. Point a built-in profile at one anyway and the connection fails before the credential prompt, usually with a message about the connection being terminated by the local system. That text is a mismatch signal rather than a diagnosis. The profile type and the client that owns the protocol have to agree, and one of them is missing.

Four types and one dialog

Every stored profile carries a tunnel type. The built-in client accepts PPTP, L2TP, IKEv2 and SSTP, plus an automatic mode that tries them in order. There is no generic SSL VPN entry, and there is no way to add one through the dialog. A vendor gateway speaks its own application protocol over TLS, which only that vendor's client implements.

The list is one command away, and it is worth running before any other troubleshooting because it takes a second and removes a whole class of wrong assumptions:

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

If the profile says SSTP and the gateway is not an RRAS server, the mismatch is already established. No amount of certificate or firewall work changes it.

SSTP and vendor TLS look alike on port 443

SSTP wraps a PPP session inside TLS and rides on TCP 443. In the Microsoft stack it is terminated by RRAS, which presents a server certificate the client validates. A Fortinet, Citrix or Pulse appliance also terminates TLS on 443, and its portal opens in any browser without complaint.

That browser test proves reachability, not compatibility. The session protocol behind the portal belongs to the vendor, and the built-in client has no implementation of it. Whether the vendor ships a client of its own tells you which half of the mismatch you are dealing with.

The reverse confusion happens too. A profile configured as SSTP against a genuine RRAS server can fail on certificate validation while the portal is fine, which is a certificate problem and not a protocol problem.

Errors that appear before a tunnel exists

The 800-series codes are reported before any tunnel is established, which is why firewall rules rarely move them. Error 812 is a server-side policy rejecting the authentication method the client offered. Others in the range come from the local connection manager rather than from the network.

Turn on tracing before rebuilding anything. The trace names the failing stage, and a stage name is worth more than the dialog text:

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

Traces land under the tracing directory and stay until you clear them, so disable tracing afterwards rather than leaving it running for weeks.

A connected profile can still break everything

A profile that connects and then breaks browsing, a local share or a container engine has a routing problem, not a tunnel problem. The default gateway moved to the tunnel, so every destination now goes through a peer that may not route it.

Two controls decide this. One is the split-tunneling property on the profile. The other is the per-adapter option to use the default gateway on the remote network, which lives under the IPv4 advanced settings.

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

Turning split tunneling on without adding routes produces a tunnel that connects and reaches nothing. Turning it off without checking DNS produces internal names that resolve to public answers, because the adapter's own suffix and servers are not being used.

Verify the plumbing, then the type

Work in this order, and stop when a step fails rather than adjusting everything at once:

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

The first command separates reachability from protocol. The second confirms what the profile claims to be. The route table shows whether the tunnel captured the default route. The dial command reports the connection manager's own error, which is often clearer than the dialog.

Record the tunnel type, the gateway product and the exact error in the ticket. The next person then knows within a minute whether this is a protocol mismatch, a certificate failure or a routing decision, instead of starting from "the VPN does not work".