SSTP Layers Explained: What the Inner Packet Still Reveals

SSTP wraps PPP and an inner packet inside TLS, but the outer TCP connection still shows who talked to whom. Label every layer before you read a capture.

Two facts about SSTP get merged in most explanations, and the merge is what makes captures confusing. The application packet survives inside the protected channel, and the TCP connection carrying that channel keeps its own addresses throughout. What travels the wire is a carrier plus its cargo, never a substitute for either. Walk the stack from the outside inward and label each boundary as you cross it.

Start at the Outer Carrier

The first thing on the wire is an ordinary TCP connection to port 443, with real addresses that routers forward. That connection is what survives network address translation and what an access provider can count. Protecting the payload does not remove the carrier, and it does not hide volume or timing.

Everything after this point is carried rather than routed. The carrier keeps working even when the inner exchange fails.

Follow the Encapsulation Inward

Inside the protected channel sits an SSTP control exchange, then a PPP session, then the network packet the client wants delivered. Each layer has its own negotiation, its own error messages and its own state machine. A fault can therefore look like a TLS fault from one vantage point and a PPP fault from another. Reading the layers in order tells you which state machine stopped.

A single capture rarely shows the whole stack. Outer headers are visible only outside the endpoint, and inner headers only after decapsulation. That asymmetry comes from where you stand, not from the protocol.

The diagram below groups the layers so they can be discussed at all. It is not a byte layout, it does not promise one record per packet, and it says nothing about how many cryptographic operations an implementation performs.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Label the Observer Before Reading a Capture

Two captures of one session answer different questions, and the interface they were taken on decides which. On the access path you see the carrier and the TLS records, and you can measure sizes and intervals without seeing an inner address. At the endpoint, after decapsulation, the inner packet is ordinary traffic under the private forwarding policy.

Write the interface and the direction on every capture before interpreting it. A trace from a physical adapter will never show the inner application's addresses as plain outer fields, and reading that absence as an encryption failure is a common mistake. A trace from inside the tunnel shows no carrier at all, so it cannot answer a question about the provider's view. The same discipline applies to endpoint logs, which record negotiation order rather than contents.

Keep the Checks the Diagram Cannot Prove

Layer order does not establish that a deployment validates the server certificate, negotiates a supported TLS version or authorises the account. Each of those is a configuration decision that fails independently of the encapsulation.

Verify them with a client that reports what it negotiated instead of reasoning from a drawing. Start with the TLS handshake, then the SSTP exchange, then PPP, and stop at the first stage that reports an error. The first command prints the chain and the negotiated version, and the second lists the handshakes present in a capture.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"

ဆက်စပ်ဆောင်းပါးများ