SSTP on Linux Fails Before Login? Check the Runtime Pieces

You install the SSTP plugin, the radio button appears in the network editor, you fill in a gateway and a username, and the profile fails with a generic error before it ever asks for a password. Nothing about that sequence is unusual, and nothing in it proves the tunnel software is installed. An SSTP connection is assembled from parts that ship separately: a VPN plugin that NetworkManager can launch, the SSTP client program that owns the TLS and PPP session, the PPP daemon underneath it, and a secret store the connection is permitted to read.

What the menu entry adds, and what it does not

The plugin contributes a service description that tells NetworkManager how to start it, and on most distributions a small editor that draws the form. That is the entire scope of the menu entry. The client program comes from a different source package, and the plugin's own README states the split directly: it is a plugin, not a client.

The client then needs PPP, because SSTP carries a PPP session inside a TLS connection. Without pppd the tunnel can complete its TLS handshake and still die at the first control frame, which reads like a credentials problem and is not one. On Debian and Ubuntu the pieces arrive as network-manager-sstp, sstp-client and ppp, and installing only the first is the most common reason a form accepts every field while the connection never finishes.

Desktop choice adds one more split. Plasma edits profiles through plasma-nm, which needs its own SSTP component and reads the same service description, so an editor with no SSTP entry and a CLI that creates profiles fine is a missing editor half rather than a broken runtime.

Read the first failing stage before reinstalling anything

A failed SSTP attempt passes through stages in a fixed order, and the stage that failed tells you which component to look at.

Launching the plugin is the first, and a failure there produces a message about the VPN service rather than about the server. A TCP connection to port 443 comes next; a refusal or timeout here is a reachability problem, not a TLS one. Then the TLS handshake and the server identity check, then PPP negotiation and account authentication, and finally address assignment and routes. Watch journalctl -f -u NetworkManager while you activate the profile once, and read the first specific line instead of the last generic one.

That ordering explains a common misreading. A certificate complaint is reported before any credential is sent, so changing the password cannot help; a PPP authentication rejection arrives after a successful handshake, so replacing the certificate cannot help either. Keep the first error and its stage, and you have a diagnosis rather than a symptom.

Certificate trust and account login are separate gates

The handshake validates that the server is the one you meant to reach, using the issuer and name you configured. Only after that does the PPP layer offer your username and password to the gateway's authentication method. Two independent checks, then, evaluated in a fixed order, with separate settings for each. Nothing typed into the password field can influence the first one.

A profile that trusts the wrong issuer fails at the first gate with an identity error. A profile that trusts it correctly but stores a stale password fails at the second with an authentication rejection. Both look like a VPN that will not connect, and neither is fixed by the other's remedy.

Get the expected issuer and server name from whoever runs the gateway rather than guessing at the editor defaults, and record the authentication method they require. If the organisation needs a method the plugin cannot express, the honest answer is an approved client that can, not a profile with validation switched off to make the error disappear.

Let one owner hold the profile and the secrets

Once the profile exists, activate it through NetworkManager and let that manager own the resulting routes and resolver changes. Starting a second standalone SSTP client while NetworkManager already runs the connection gives you two route sets, two DNS configurations, and a debugging session with no single source of truth.

Secrets have an owner too. A connection marked for system-wide use stores credentials differently from one restricted to your user session, and a profile created by hand in a keyfile may not be readable by the secret agent that expects to supply the password interactively. Check which context the profile expects before you retype a password that was never the problem. Activating the same profile from a terminal with nmcli is the quickest test, because a prompt that never appears tells you the agent already had nothing to offer.

Verify the tunnel, the routes and the resolver separately

A connected indicator only claims that the link came up. Check the destination you actually need, the route that carries it, and the resolver in use, one at a time; each can be wrong while the other two are fine.

For a failed attempt, capture the version of each component and the sanitised error text. Share those, not the full profile, because the profile can contain the pre-shared secret and your stored credentials.

Finally, disconnect and reconnect, then reboot once. If the profile only works on the first attempt, the problem sits in secret handling or in route ownership, and both are cheaper to fix now than in the middle of a working day.