Secure Socket Tunneling Protocol (SSTP) is a popular VPN transport that tunnels PPP over an HTTPS session. For administrators, developers, and site operators, being able to inspect SSTP traffic is essential for troubleshooting connectivity, performance, and protocol-level issues. This article provides a detailed, practical walkthrough for capturing and analyzing SSTP VPN traffic with Wireshark, including realistic approaches to decryption, common pitfalls, and advanced tips for extracting PPP-encapsulated traffic.

Why monitor SSTP traffic?

SSTP encapsulates PPP frames inside TLS-encrypted TCP connections (commonly on port 443). Monitoring SSTP can help you:

  • Verify TCP and TLS handshake behavior (retransmissions, MTU issues).
  • Confirm SSTP session establishment and PPP negotiation (LCP/CHAP/MS-CHAPv2, IPCP).
  • Diagnose authentication failures, tunnel fragmentation, or throughput bottlenecks.
  • Validate server configuration and certificate behavior from the client perspective.

High-level approach

The process breaks down into three stages:

  • Capture the traffic at an appropriate point (client, server, or an inline tap).
  • Identify relevant SSTP/TLS/TCP streams using Wireshark filters and protocol recognition.
  • Attempt decryption where possible to recover PPP frames and inner-IP traffic for deep analysis.

Prerequisites and environment considerations

Before beginning, ensure you have:

  • Wireshark (latest stable release recommended) installed on the machine you will use for analysis.
  • Appropriate capture permissions and tools: on Windows use Npcap in WinPcap compatibility mode; on Linux use libpcap (tcpdump) or Wireshark’s built-in capture.
  • Access to either the client (preferred) or server environment to enable key logging or to collect cryptographic keys if decryption is required.
  • Awareness of privacy and legal implications—decrypting VPN traffic can expose sensitive data and should only be performed on systems you control or with explicit authorization.

Step 1 — Capturing SSTP traffic

Capturing in the right place makes analysis easier. Options:

  • Client-side capture: Capture on the client machine (where the SSTP VPN is initiated). This is ideal for extracting session secrets and seeing full conversation including the TLS handshake.
  • Server-side capture: Capture on the VPN server’s external interface. If RSA key exchange is used (non-DHE/ECDHE), the server’s private key may enable decryption.
  • Network tap or mirror: Capture on a network tap or SPAN port; you will generally see encrypted traffic and will need session secrets or the server private key to decrypt.

Practical tips for capturing:

  • Use a capture filter to limit volume, e.g. tcp port 443 and host 198.51.100.10 (replace with the VPN server address).
  • Enable TCP reassembly in Wireshark preferences (Analyze → Preferences → Protocols → TCP → Allow subdissector to reassemble TCP streams) so that SSTP records that span multiple segments are reassembled.
  • Capture the full TLS handshake—decryption using session secrets requires the ClientHello/ServerHello exchange.

Step 2 — Identifying and inspecting SSTP flows in Wireshark

Wireshark includes an SSTP dissector. After loading your capture:

  • Use display filters to find SSTP traffic: sstp or by port tcp.port==443 and tls. SSTP frames may also be parsed as TLS application data until the SSTP dissector decodes them.
  • Look for the SSTP control messages such as SSTP_CONTROL_PKT and PPP negotiation packets inside SSTP.
  • Use Follow → TCP Stream on a candidate stream to view the TLS-level conversation and ensure you captured the full handshake.

When SSTP is decoded successfully you will see PPP frames labeled inside the SSTP packets; expand PPP to see LCP, CHAP or IP payloads depending on negotiation.

Step 3 — Decrypting TLS to reveal PPP

Decrypting TLS is the key to seeing inner PPP traffic. There are three practical options, each with limitations:

1. Use Pre-Master / Session secrets via SSLKEYLOGFILE (recommended for many clients)

Browsers and some OpenSSL/NSS-based clients support writing TLS session secrets to a file referenced by the environment variable SSLKEYLOGFILE. If your SSTP client or the library it uses supports this, Wireshark can consume that file.

Procedure:

  • On the client, set the environment variable before initiating the SSTP connection: set SSLKEYLOGFILE=C:keyssslkeys.log (Windows) or export SSLKEYLOGFILE=/home/user/sslkeys.log (Linux).
  • Start the SSTP connection and capture traffic with Wireshark.
  • In Wireshark go to Analyze → Preferences → Protocols → TLS and set “Pre-Master-Secret log filename” to the path of the file.
  • Reload or re-open the capture so Wireshark applies the keys; encrypted Application Data should then decrypt and the SSTP dissector will reveal PPP payload.

Limitations: Not all SSTP clients use NSS/OpenSSL and therefore don’t honor SSLKEYLOGFILE. The official Windows SSTP client uses SChannel and does not export keys to SSLKEYLOGFILE by default.

2. Use the server’s private RSA key (only if RSA key exchange is used)

If the TLS handshake used RSA key exchange (no DHE/ECDHE), the server private key can be used by Wireshark to decrypt the TLS session. Steps:

  • Obtain the server private key file (PEM format).
  • In Wireshark: Analyze → Preferences → Protocols → TLS → (RSA Keys List) → add entry with IP, port (443), protocol (http), and path to the PEM private key.
  • Reload the capture and Wireshark will attempt to decrypt sessions that used RSA key exchange.

Limitations: ECDHE/DHE (ephemeral) key exchanges are nearly universal for secure servers today—RSA key decryption rarely works on modern SSTP endpoints.

3. Client-based full packet capture and offline analysis

If you cannot obtain keys you can still perform deep protocol analysis by capturing on the endpoint where plaintext is available (for example, capturing the virtual adapter on the client after decryption by the OS). On Windows, the SSTP driver renders PPP/virtual adapter traffic locally; capturing that interface (the PPP or NDIS interface) can show inner IP packets without TLS.

  • Capture on the virtual adapter (for example “Ethernet 2” corresponding to the VPN interface) with Wireshark.
  • This method yields unencrypted inner-IP frames and is often the simplest approach for troubleshooting application-level behavior.

Limitations: This requires capture privileges on the client endpoint and may not show the TLS-level handshake details.

Decrypting MPPE and PPP-level encryption

Even after decrypting TLS, PPP may still use MPPE (Microsoft Point-to-Point Encryption) to encrypt payloads. Wireshark supports MPPE decryption if you can provide the MS-CHAPv2 master key. To decrypt MPPE:

  • Obtain the MS-CHAPv2 NT password hash or the derived MS-MPPE-Send-Key/MS-MPPE-Recv-Key from the authentication exchange.
  • Configure PPP dissector or the appropriate preferences in Wireshark to import the keys.

In practice this is complex and often requires server-side logs or access to the RADIUS/AAA server that derived the keys. For many troubleshooting scenarios, decrypting TLS and inspecting PPP control frames (LCP/CHAP/IPCP) suffices.

Useful Wireshark display filters and tips

  • Find SSTP packets: sstp
  • Find TLS application data over the PPTP/TCP stream: tcp.port==443 and tls.record.version
  • View PPP frames: after SSTP is decoded you can use ppp or ppp.lcp, ppp.chap
  • Follow inner IP flows: once PPP is decrypted, use ip.addr==10.8.0.5 replacing with client/server virtual IPs assigned by IPCP.
  • Check for fragmentation/retransmissions: tcp.analysis.retransmission or tcp.analysis.lost_segment

Common troubleshooting scenarios

Below are frequent problems and how monitoring SSTP with Wireshark can help:

Authentication failures

Inspect PPP LCP and authentication packets. An MS-CHAPv2 failure will be visible in the PPP authentication exchange. If TLS completes but PPP authentication fails, check username/password, RADIUS responses, and authentication method mismatch.

Frequent disconnects or renegotiation

Observe the TLS session lifetime and any alerts (tls.handshake.alert). Look for TCP Keepalives, abrupt FIN/RST, or PPP LCP Terminate messages. Packet loss and retransmits at TCP level often cause renegotiation behavior.

Performance issues

Use round-trip-time measurements in Wireshark and observe TCP windowing and any application-level retransmits. MTU/MSS clamping issues are visible by checking for ICMP fragmentation-needed or seeing repeated retransmission of large segments.

Advanced: automating capture and correlation

For large-scale environments, consider:

  • Using remote packet capture appliances or tcpdump on the server with indexed pcaps sent to a central ELK or analysis pipeline.
  • Logging TLS session secrets centrally where clients support SSLKEYLOGFILE and correlating with Wireshark or tshark processes for automated decryption.
  • Correlating VPN server logs (SSTP service logs, RADIUS accounting) with packet captures using timestamps to speed root cause analysis.

Limitations and security considerations

Decryption is powerful but sensitive. Always ensure you have authorization. Modern TLS configurations (ECDHE) and best-practice authentication/encryption (MPPE or stronger) are designed to prevent passive decryption—this is good for security but complicates troubleshooting. When possible, prefer client-side virtual adapter captures for inner-IP visibility, and use key logging on test clients to enable full TLS decryption for debugging sessions.

Monitoring SSTP traffic with Wireshark can unlock deep insights into VPN behavior when approached methodically: capture at the right point, preserve the TLS handshake, and use the appropriate decryption strategy. While server private-key decryption is often impossible on modern systems due to ephemeral key exchanges, client-side key logging or virtual-adapter captures typically provide the necessary visibility for effective troubleshooting.

For further resources and recommendations tailored to managed VPN deployments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.