Port 443 Answers, SSTP Still Fails: Which Stage Broke?

Completing a TCP handshake to port 443 while the tunnel never builds proves one thing, and it is a small thing. Something is listening and willing to accept a connection at that address. It does not identify the service, the certificate it will present, or what happens after the first bytes.

Four stages sit between that handshake and a working tunnel, and each one produces a different error.

An Open Port Describes One Layer Only

Accepting a TCP connection means a process owns the socket and the path permits the handshake. It says nothing about whether that process is an SSTP server, whether it holds a certificate valid for the name in your profile, or whether it will authorize your account. A web server on the same address answers the handshake perfectly and then responds to your SSTP request with an HTTP error. Everything above that handshake stays untested.

Treat the port test as the cheapest possible filter rather than as a verdict. Its value is that it removes one whole category of failure, not that it confirms everything above it.

Confusing the two is why people reinstall clients after a test that never examined the client's actual problem.

Separate the Four Stages With Evidence

The stages are transport reachability, TLS validation, the SSTP exchange over HTTPS, and PPP authentication inside the tunnel. A path that passes the first and fails the fourth needs a credential fix; one that fails the second needs a certificate or name fix. Those repairs have nothing in common, and picking the wrong one wastes the outage.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

The third command is worth reading carefully. A 200 from an ordinary web page tells you a web service is there; it does not tell you the SSTP request will be understood. A 404 from the same address is equally uninformative about the VPN. Only the client log tells you which of the four stages it reached.

Note which name each command used. The certificate is selected by the name you send, so a mismatch between the profile and the test is a mismatch you introduced. Writing that name next to the result prevents the confusion later.

Read Partial Success in the Right Direction

An intermediary can permit ordinary browsing and refuse the later exchange, which is why a proxy that works for websites can still fail for a tunnel. The same pattern appears when a certificate is valid for a browser name but not for the name configured in the profile: the browser is satisfied and the client is not, and both are correct about what they checked.

Keep server validation enabled while you diagnose this. Disabling it converts a certificate mismatch into a successful handshake and hides the only evidence that would have explained the failure.

If the same profile works from another network, the difference is path-dependent. That narrows the search to intermediaries without telling you which one, and it is still a useful step forward. Record the network you used, because the comparison is worthless without it.

Then Test the Application, Not Just the Session

Once a session exists, verify the intended route, name resolution and service permission from the client that needs them. A connected tunnel can still have missing forwarding on the far side or a return route that never existed, and those failures look exactly like an application problem to the person waiting.

Keep every conclusion attached to the stage that produced it. Calling an open port a working VPN is how a five-minute certificate check becomes a day of reinstalling software.