SSTP behind a TLS-inspecting proxy: where the session breaks

Your browser loads the corporate intranet, the proxy certificate is trusted, and the SSTP client still drops near the end of the connection. That pattern points at the difference between a web request and a tunneled session, not at a wrong password. Walk the connection from TCP upward and note the first stage that fails. The stage, not the error code, tells you whether the proxy is the cause.

Start where the client stops

The client passes through a fixed sequence: TCP connect to port 443, TLS handshake, certificate validation, the SSTP HTTP exchange, PPP negotiation and authentication, then IP configuration. A failure at each stage leaves a different signature, and mixing them up sends you to the wrong configuration page.

A TCP failure is a timeout or a reset before any TLS byte appears. A TLS failure is an alert or a handshake timeout. A certificate failure produces a warning about the chain or the name. An HTTP failure arrives after a successful handshake, often as a status code or an immediate close. A PPP failure comes after the tunnel is technically established, which is why it looks like an authentication problem.

Read the client log for the last successful stage rather than the first error line. The error line is usually the client reporting the consequence, while the stage boundary names the component that refused.

What SSTP asks the network to carry

SSTP runs over TLS on TCP 443 and then sends an HTTP request called SSTP_DUPLEX_POST, defined in the SSTP specification, to a path of the form /sra_{GUID}/. The request declares an effectively unlimited content length and keeps the stream open in both directions for the life of the session. The PPP frames travel inside that stream.

This is why a proxy that handles ordinary browsing can still fail. A GET or a POST with a finite body can be buffered, inspected and forwarded; a duplex stream with a body that never ends cannot. A proxy that waits for the body to complete waits forever, and the client eventually times out.

Method filtering and authentication add their own failure modes. If the proxy challenges the request for credentials, the VPN client may not answer the challenge even though the browser would. If it strips or rewrites the method, the gateway rejects the request before PPP begins.

Why inspection changes the identity

A TLS-inspecting proxy terminates the client's TLS connection and opens a separate one to the gateway. The client therefore validates the proxy's certificate, not the gateway's, and the gateway sees the proxy as its peer. When the organization distributes its own root, the browser and the VPN client may both accept that chain, so the handshake succeeds and the problem moves to the next stage.

Successful validation does not mean the proxy can carry the session. It still has to relay an unbounded bidirectional POST without buffering, and it has to keep both connections alive for hours. Many inspection products are built for request-response traffic and handle this case poorly or not at all.

This is also why adding an unknown root or disabling verification is the wrong repair. It changes which certificate the client accepts; it does nothing about the stream handling that actually broke the session.

Identify the issuer before changing settings

Ask the endpoint what certificate it presents and who signed it. The commands below show the chain and the issuer without starting a VPN session:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

If the issuer is a public CA, the connection is probably not being intercepted for this host and the failure is elsewhere. If the issuer is the organization's own CA, inspection is active and the gateway is reached through a proxy. Compare the fingerprint with the one the network team expects before drawing a conclusion from the name alone.

A browser test to the same host proves only that the proxy accepts a GET. It says nothing about the SSTP method, the request URI or the lifetime of the body, so do not treat a working intranet page as evidence that the tunnel path is supported.

Choose the supported path

Ask the network owner one concrete question: does the proxy permit an unbuffered duplex POST to this gateway on port 443? A yes leads to a proxy exception or a documented bypass for the VPN host. A no means the inspected path cannot carry SSTP, and the supported fix is a different path or protocol rather than a client tweak.

Options usually include a non-inspected egress for the VPN gateway, a split-tunnel design that sends only corporate traffic through the proxy, or an alternate protocol the organization supports on a different port. Each belongs to the network design, and each should be tested with the same device and profile so the comparison isolates the path.

Document the outcome: issuer, failing stage, proxy rule and chosen path. The next person who sees the same 98 percent stall can then check one fact instead of repeating the whole walkthrough.