Secure Socket Tunneling Protocol (SSTP) is often overlooked compared to OpenVPN or IKEv2, yet it provides a robust option for Windows-centric deployments and scenarios where TCP 443 access is the only permitted outbound channel. This article breaks down the SSTP negotiation sequence with concrete technical details — from TCP connection setup through SSL/TLS handshake, SSTP control message exchange, PPP negotiation, to MPPE keying and data transport. The goal is to give webmasters, enterprise architects, and developers a clear, actionable understanding of how an SSTP VPN session is established and maintained.

Overview of SSTP Architecture and Use Cases

SSTP encapsulates PPP frames inside an SSL/TLS channel, allowing VPN traffic to traverse firewalls and proxies that permit HTTPS. It leverages standard Windows components (RAS, SSTP driver) and uses TCP port 443 by default. Typical use cases include:

  • Corporate remote access where only HTTPS is allowed.
  • BYOD scenarios on locked-down networks.
  • Integration with Windows Server routing and remote access service (RRAS).

Before we dive into the sequence, it’s helpful to remember the protocol layers involved: TCP → TLS → SSTP control/data → PPP → network protocols (IP, IPv6, etc.).

Preconditions and Network Considerations

Successful SSTP negotiation assumes:

  • Server listens on TCP/443 (or custom port) and is reachable.
  • TLS certificate on server is trusted by client (public CA or pre-provisioned).
  • Firewall and NAT behaviors are accounted for — TCP semantics mean NAT timeouts and connection resets can affect stability.

Note: Because SSTP runs over TCP, it is susceptible to TCP-in-TCP interaction and path MTU issues; fragmentation handling and keepalives need special attention on both client and server.

Step-by-Step SSTP Negotiation Sequence

1. TCP Three-Way Handshake

The connection begins with the standard TCP three-way handshake. Client opens a socket to the server’s IP on port 443 (unless configured otherwise):

  • Client: SYN → Server
  • Server: SYN-ACK → Client
  • Client: ACK → Server

This establishes a reliable byte stream used by TLS. Because SSTP uses TCP, any middleboxes that inspect TLS streams may influence negotiation.

2. TLS/SSL Handshake

Once the TCP socket is established, the client initiates a TLS handshake. The handshake sequence (simplified) is:

  • ClientHello (cipher suites, versions, extensions)
  • ServerHello (selected cipher suite, session parameters)
  • Certificate (server certificate chain)
  • ServerKeyExchange (if necessary)
  • CertificateRequest (optional)
  • ServerHelloDone
  • Client Certificate (if requested)
  • ClientKeyExchange
  • ChangeCipherSpec / Finished → bidirectional traffic encryption activated

Key details: SSTP commonly requires TLS 1.2 or higher for modern security. Cipher suites should provide forward secrecy (ECDHE) and strong symmetric ciphers (AES-GCM). Certificate validation is critical — expired or mismatched certificates will break negotiation. Some deployments use client certificates for mutual TLS authentication, but typical Windows SSTP clients rely on PPP-level authentication (e.g., MS-CHAPv2) after TLS establishment.

3. SSTP Control Channel Establishment (HTTPS POST)

After TLS is established, SSTP wraps control messages over the encrypted channel. The client initiates using an HTTP POST to the SSTP endpoint, commonly /sra_{GUID}/ for server RRAS implementations:

  • Client sends a POST request with Content-Type: application/sstp
  • Server responds with HTTP/1.1 200 OK indicating acceptance

Within the HTTP payload, the SSTP control packets begin. The SSTP packet header (first few bytes) identifies message type and length.

4. SSTP Control Packet Exchange: CONNECT and HLOS

SSTP control messages follow a compact binary format. Important initial messages include:

  • SSTP_CALL_CONNECT_REQUEST / SSTP_CALL_CONNECT_ACK — used for call establishment semantics
  • SSTP_CRED — credential negotiation flags
  • SSTP_PORTS — optional parameters

The client and server exchange these to agree on capabilities and to signal readiness to carry PPP frames. The initial SSTP control packets are exchanged within the encapsulated HTTPS body and are always TLS-protected.

5. PPP LCP Negotiation

Once the SSTP control channel signals that a virtual link is up, PPP (Point-to-Point Protocol) begins. LCP (Link Control Protocol) frames negotiate link options. Typical LCP sequence:

  • Client sends LCP Configure-Request with options: MRU, Authentication Protocols Preference, Magic Number, Protocol Field Compression (PFC), Address-and-Control-Field-Compression (ACFC).
  • Server replies Configure-Ack, Configure-Nak, or Configure-Reject as appropriate.
  • Negotiate until both sides exchange Configure-Ack → LCP Opened state.

MRU/MTU considerations: Because SSTP encapsulates PPP inside TLS/TCP, the effective MTU is lower; servers often reduce MRU to prevent fragmentation. MSS clamping at edge routers can help avoid excessive fragmentation inside the TLS stream.

6. Authentication (PAP/CHAP/MS-CHAPv2)

After LCP, PPP authentication occurs. Historically PAP and CHAP were used, but MS-CHAPv2 is common on Windows clients for compatibility. Sequence for MS-CHAPv2:

  • Server issues CHAP Challenge.
  • Client responds with CHAP Response containing peer challenge, NT response generated from user password hash (MD4 of Unicode password) and server challenge.
  • Server validates NT response against stored credentials (often against Active Directory via RADIUS/NPS).

Security note: MS-CHAPv2 has known weaknesses; it should be paired with TLS and ideally combined with EAP-TLS or certificates in enterprise deployments for stronger authentication. When using RADIUS, EAP-TLS or PEAP is preferable.

7. IPCP / IPv6CP — Network Protocol Configuration

After authentication, PPP negotiates network-layer parameters:

  • IP Control Protocol (IPCP) exchanges to assign IPv4 addresses, DNS, WINS.
  • IPv6 Control Protocol (IPV6CP) if IPv6 is desired.

Server typically assigns an IP address and pushes DNS server and routing information. Routes and split-tunnel rules may be applied here or via server-side policy.

8. MPPE Keying and Data Encryption

SSTP leverages MPPE (Microsoft Point-to-Point Encryption) to encrypt PPP payloads. Keying material for MPPE is derived from the MS-CHAPv2 authentication exchange. High-level keying flow:

  • MS-CHAPv2 produces an MSK (Master Session Key) from the authentication exchange.
  • MSK is used to derive send/receive RC4 keys for MPPE (historical) or keys for modern symmetric ciphers when using updated implementations.

Because the PPP payload is already encapsulated in TLS, MPPE may seem redundant. However, MPPE provides per-packet encryption at the PPP layer and compatibility with Windows VPN stack expectations. For modern security, TLS encryption provides the primary confidentiality and integrity.

9. Data Transfer — Encapsulation and Framing

Once PPP and MPPE are in place, user traffic is encapsulated in PPP frames which are then packaged into SSTP data messages. Data flow:

  • Higher-layer IP packet → PPP frame
  • PPP frame → MPPE (optional) → SSTP data chunk
  • SSTP data chunk placed into the TLS record layer → TCP stream → network

Because TLS records are delivered over TCP, and TCP delivers an ordered, reliable stream, SSTP must handle segmentation boundaries carefully. SSTP data packets embed a length field so recipients can parse frames from the TLS stream correctly.

Keepalives, Fragmentation, and Connection Maintenance

Server and client implement keepalive mechanisms to detect dead peers. Typical strategies include:

  • Periodic SSTP control messages (CallKeepAlive) or periodic null data packets.
  • TCP keepalives at OS level and TLS session timeouts.
  • PPP LCP echo-request/echo-reply to detect link failure.

Fragmentation is an operational concern: large PPP frames might be split across multiple TLS records. SSTP includes fragmentation flags in control/data headers to signal continuation fragments. Administrators should tune MRU and MSS to minimize path fragmentation. Additionally, middleboxes that reassemble TLS streams incorrectly can cause issues.

Common Troubleshooting Scenarios

Understanding the sequence helps diagnose common failures:

  • TLS handshake failures: check certificate chain, trusted CA, cipher suite mismatches, TLS version incompatibility, or SNI issues.
  • HTTP-level problems: proxies or NGFWs blocking POSTs or tampering with headers — ensure the SSTP endpoint path and headers are preserved by intermediaries.
  • Authentication failures: inspect RADIUS/NPS logs for MS-CHAPv2 errors or mismatched user credentials; verify time synchronization for Kerberos-related flows.
  • IP assignment failures: ensure IPCP is not blocked, and server is configured to hand out IP/DNS settings or integrate with DHCP backend appropriately.
  • Stability issues: long-lived TCP/TLS over NAT may be terminated by NAT timeouts — configure keepalives and adjust NAT mapping timers where possible.

Security Best Practices

For production environments, follow these recommendations:

  • Enforce TLS 1.2+ with strong ciphers and ECDHE for forward secrecy.
  • Prefer certificate-based or EAP-based authentication (EAP-TLS, PEAP with MS-CHAPv2 replaced) for stronger identity assurance.
  • Harden the server: disable obsolete cipher suites and protocols, enable HTTP Strict Transport Security (HSTS) if applicable for the portal endpoints, and restrict management interfaces.
  • Monitor for anomalous authentication patterns in RADIUS/NPS and use multi-factor authentication where possible.
  • Tune MRU/MSS to prevent excessive fragmentation and avoid TCP-in-TCP performance degradation.

Integration Points and Interoperability

SSTP integrates smoothly with Microsoft-centric infrastructures (Active Directory, NPS/RADIUS, RRAS). When integrating with non-Windows servers, ensure the SSTP implementation strictly follows RFC 4762-related behaviors and that TLS and PPP options are compatible. Common interoperability steps:

  • Verify certificate chain and server name indications (SNI) when behind load balancers.
  • Confirm RADIUS attributes (Framed-IP-Address, MS-MPPE-Keys) are correctly relayed and encrypted where needed.
  • Test across client OS versions: Windows SSTP client behavior may differ slightly between OS versions.

Understanding the SSTP negotiation flow — from TCP and TLS to SSTP control exchanges and PPP — gives architects and administrators the tools to design, secure, and troubleshoot SSTP VPN deployments effectively. Proper tuning of TLS parameters, PPP options, and network elements reduces failure modes and improves user experience.

For implementation guidance, server configuration best practices, and managed dedicated IP options tailored to SSTP deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.