SSTP vs OpenVPN: Same Port 443, Different Protocol

Both options can sit behind TCP 443, so people assume they are interchangeable endpoints. They are not: an SSTP server speaks PPP inside HTTPS, while an OpenVPN server speaks its own protocol over TLS or a raw UDP flow. Pointing one client at the other's port produces a connection that never reaches a login prompt. The choice is about which client and transport you can support, not about the number.

A shared port does not make a shared protocol

The TLS handshake can complete and still lead nowhere, because the client and server then disagree about what to say next. In a packet capture you see a clean handshake followed by application data that the peer rejects or ignores. That pattern is the signature of a protocol mismatch rather than a firewall block.

Neither a renamed profile nor a different menu entry converts one into the other. An SSTP connection is created from the Windows VPN settings with a server address and the operator's authentication details, while an OpenVPN connection needs the client and the matching configuration file. Microsoft's SSTP specification describes the former, and it does not describe an OpenVPN handshake.

Port 443 is a policy convenience. It passes networks that permit little else, and that is a real advantage, but it tells you nothing about which protocol is running behind it.

SSTP tunnels PPP inside HTTPS

The name describes the construction: PPP frames carried inside an HTTPS session, which means TLS underneath and a certificate the client can check. Windows includes this as a native VPN type, so a managed laptop can often connect with no additional software beyond the profile the operator supplies.

Other platforms are a different story. A Linux or macOS client needs a maintained implementation, and those vary in what they support and how they report errors. Check the client you actually intend to use rather than assuming the built-in Windows capability transfers, and confirm the server name in the profile matches the certificate the server presents.

SSTP is typically TCP only. That single transport affects how it behaves on a lossy link, because retransmission happens inside the tunnel as well as underneath it.

OpenVPN brings its own client and a transport choice

OpenVPN ships its own client and profile, which gives you diagnostics that a native Windows dialog does not expose. The server can listen on UDP or TCP, and the operator's configuration decides which one your client must use. A profile pointed at the wrong transport fails before authentication.

Authentication is equally configuration-driven. A deployment can require certificates only, certificates plus a username and password, or a second factor on top, and the client has to match that arrangement exactly. The fact that a connection reaches the TLS stage does not tell you which credentials it will ask for next.

UDP is the usual default because it avoids nesting a reliable stream inside another reliable stream. TCP mode exists for networks that block UDP, and it works, but heavy loss can make it feel worse than the UDP path it replaced. Choose TCP when you must, not because it sounds more reliable.

Choose by client, transport and support

Three questions settle most of these decisions. Does every client device need a connection that works with zero extra software? Does the network you depend on permit UDP, or is TCP 443 the only exit? And who supports the client, its updates and its recovery when a profile expires?

When you compare the two, test on the same device and the same access network. If the SSTP endpoint and the OpenVPN endpoint are different servers or different sites, your result includes those routes and machines rather than isolating the protocol. That is the most common way these comparisons produce a confident but wrong answer.

Then confirm which one you actually established before you debug anything else:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

Either way, finish by testing the resource and the DNS you need rather than declaring success at the tunnel state. Both protocols can be configured to carry only selected private traffic, and a connected tunnel with no working name resolution looks like a broken VPN when it is really a split-tunnel or DNS design.

On a managed fleet, profile distribution and update support usually decide the question long before any transport benchmark does.