SSTP Fails Where the Browser HTTPS Succeeds: Why
SSTP runs inside TLS on port 443, but it is not a web request. Test TCP, TLS identity, the SSTP exchange and PPP authentication as separate stages.
The browser opens the VPN hostname over HTTPS without complaint, and the SSTP client still refuses to connect. Nothing about that pair is contradictory. SSTP uses TLS as an outer transport and then runs its own request and PPP payload inside that connection, so a successful page load proves one narrow thing: the host answers a GET on port 443. The client is asking a different question, and the server may answer it badly.
The page loads and the tunnel does not
People reach for the browser test because it is quick, then treat the result as proof that the server is reachable and configured. It is proof about a GET to whatever path the address bar opened, nothing more. The VPN conversation starts after the same TLS handshake but sends a method and a path a web page never uses. A 200 for the browser therefore says nothing about whether the SSTP endpoint exists.
Separate the two observations and the search gets shorter. Transport and certificate chain work, and something in the protocol exchange above them does not. That is a different investigation from a broken port or an expired certificate, and it needs different evidence.
What the SSTP client actually sends
The client sends an HTTP request with the method SSTP_DUPLEX_POST to the path /sra_{GUID}/, then keeps the connection body open as a bidirectional stream carrying PPP frames. A compliant server answers HTTP/1.1 200 and stops behaving like a web server. Anything else is a signature: 405 or 404 means the endpoint is not there, 301 or 302 means something is redirecting the request, and an immediate FIN means a proxy or server closed the stream.
That is why the target has to be an SSTP server rather than a web server with a TLS certificate bolted on. The method, the path and the long-lived body are protocol requirements, so a reverse proxy cannot add them from configuration alone. A proxy that forwards ordinary HTTPS perfectly can still refuse a method it does not recognise.
Where a proxy or web server breaks the stream
An intermediary inspects the HTTP request line before it forwards anything, and a custom method with an unusual path may fail its rules. Some devices serve a normal page while rejecting or interrupting the tunnel, so the client reports a connection that starts and then dies rather than a clean refusal. Others accept the request, then apply a body or idle timeout that the PPP keepalives cannot survive. Both look alike from the client side, which is why the stage that failed matters more than the error text.
Sharing port 443 between a website and SSTP is a routing choice, not a promise that every hop handles both conversations the same way. If a load balancer, firewall or TLS terminator sits in the path, add it to the suspect list before you touch the VPN configuration.
Test the stages separately
Run the checks in order and stop at the first failure, because each stage rules out a different layer. The TLS probe below separates certificate identity from anything SSTP does. Replace the hostname with your endpoint and read the subject and chain it prints.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comThen map the remaining evidence onto the stages rather than guessing from the client error. The table below is the checklist to quote in the ticket, with the signature that separates one failure from the next.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Record the last stage that succeeded in the ticket instead of writing "cannot connect". The MS-SSTP specification documents the request and the PPP exchange that follow the TLS handshake, which is the reference for why a browser test cannot stand in for either.
Identity first, then PPP
TLS identity and PPP authentication are sequential, not alternative, and confusing them sends people to the wrong server setting. The client validates the server certificate and its intended purpose first, then PPP negotiates its own state and authenticates the user with a challenge-response method or EAP. A certificate problem produces a different error than a rejected password, and neither error describes the stage the other one covers.
Swapping the hostname for an address, or clicking past the certificate warning, removes the check that would have identified the failing stage instead of fixing it. Keep the warning and read it. Do not reset a PPP password when the HTTP exchange never reached the SSTP behaviour either, because the credential was never asked for.