Secure Socket Tunneling Protocol (SSTP) remains a practical choice for remote access because it tunnels PPP over an SSL/TLS channel on TCP port 443, providing strong firewall traversal and interoperability with Microsoft clients. When you need to serve many concurrent SSTP clients from multiple backend VPN servers, integrating a load balancer becomes essential for scalability and availability. However, SSTP is a stateful, long-lived, TLS-wrapped TCP stream carrying PPP frames, and that creates specific constraints and design choices for load balancers. This article explores practical architectures, configuration patterns, and operational considerations for integrating SSTP VPNs with load balancers in production environments.

How SSTP Works (Key Points for Load Balancer Design)

Understanding the SSTP negotiation is critical to selecting the right load balancing approach:

  • Connection type: SSTP uses TCP (default port 443) and TLS to encapsulate PPP frames. The client initiates a TLS handshake, then performs an HTTP-style POST to a server-side SSTP endpoint (commonly under /sra_{GUID}). After the TLS and HTTP exchange, the PPP frames are exchanged inside the encrypted session.
  • Authentication: SSTP supports EAP (EAP-TLS client certificates), MS-CHAPv2 (username/password), and other EAP variants. When using client certificate authentication, the TLS session must be terminated at the backend to validate the client cert.
  • Session characteristics: Sessions are long-lived TCP/TLS streams and can survive for hours. They are stateful and demand affinity so that subsequent packets for a tunnel reach the same backend server.

Load Balancer Modes: Passthrough vs TLS Termination

Two primary load balancer architectures apply to SSTP:

1. TCP Passthrough (Layer 4)

  • Description: The load balancer forwards raw TCP connections to backend VPN servers without terminating TLS.
  • Why it fits: Because SSTP’s TLS session must be between client and VPN server for client-certificate authentication and to preserve the SSTP semantics, passthrough is the simplest and most compatible approach.
  • Benefits: Full compatibility with EAP-TLS; backend servers see original TLS client handshake and certificate; minimal protocol interpretation by LB; simpler for PPP over TLS traffic.
  • Considerations: You lose visibility into HTTP-layer details and cannot do HTTP-based health checks or advanced routing based on HTTP headers.

2. TLS Termination (Layer 7 / SSL Offload)

  • Description: The load balancer terminates TLS, inspects the HTTP-level SSTP POST, and then either forwards decrypted traffic to backends or re-encrypts to them.
  • Why it’s tricky: Terminating TLS at the LB breaks client-certificate authentication to the backend unless you implement mutual TLS between LB and backend and pass client identity information separately. Also, SSTP’s encapsulated PPP frames are not plain HTTP and require safe pass-through of binary streams after termination.
  • Use cases: May be suitable if you want to centralize certificate management, perform application-layer DDoS mitigation, or inject web application firewalls — but expect complexity and possible re-engineering of authentication.

Choosing the Right Load Balancer

Practical choices depend on whether client certificate authentication is required and on the level of control you want over sessions:

  • For strict EAP-TLS client-cert authentication: Prefer Layer 4 (TCP) passthrough load balancers: AWS Network Load Balancer (NLB), HAProxy in TCP mode, NGINX stream module, or hardware L4 appliances. These keep TLS end-to-end between client and backend server.
  • For username/password (MS-CHAPv2) and central TLS management: You can consider TLS offloading at the LB, but you must preserve authentication semantics (e.g., re-authenticate to a backend RADIUS or AD) and ensure LB forwards client identity securely.
  • Cloud-managed options: AWS NLB, GCP TCP proxy, Azure Load Balancer (Basic) are good for passthrough. Avoid HTTP/HTTPS-specific ALBs or Application Gateway for SSTP passthrough since they terminate/inspect HTTP and expect HTTP semantics that SSTP does not conform to after the TLS handshake.

Session Persistence and Affinity

Because SSTP uses a single persistent TCP connection per client, ensuring requests from the same client go to the same backend for the duration of the session is mandatory. Techniques include:

  • Source IP affinity: Bind incoming connections from the same source IP to the same backend. Simple and effective when NAT doesn’t change the source IP (or when clients have stable IPs). However, it fails when multiple clients share a public IP (e.g., behind a NAT) or when clients’ IPs change.
  • TCP-level connection steering: Use the LB’s natural connection mapping (each TCP connection is directed to one backend) and avoid connection multiplexing. Ensure the LB’s idle timeout exceeds the expected life of SSTP sessions.
  • Sticky sessions with proxy protocol: When using HAProxy or similar, enable the proxy protocol or use a UUID cookie is not applicable for raw TCP; rely on the LB’s persistent connection handling and avoid connection re-assignment during scaling operations.

Health Checks and Probes

Standard HTTP health checks are inadequate for passthrough mode because they do not verify the SSTP-handshake readiness. Recommended approaches:

  • TCP-level health checks: Basic but fast — confirm the backend accepts TCP connections on port 443. This detects a dead process or crashed host but not S S T P-specific readiness.
  • TLS-aware probes: Implement a probe that performs a TLS handshake and optionally sends the SSTP-specific HTTP POST to the server endpoint (e.g., the /sra_{GUID} resource used by Microsoft clients) verifying the SSTP server accepts and responds correctly. Many load balancers support custom health checks or scripts for this purpose.
  • Application-layer checks on a management port: Run a lightweight HTTP endpoint on each backend that reports the state of the SSTP service and use that for faster and safer health gating behind the LB.

Scaling Patterns and High Availability

Because each backend keeps per-connection state, scaling SSTP requires careful operational patterns:

  • Horizontal scaling: Add more SSTP servers behind the LB. Each session is handled by one server. Use automated provisioning and configuration management that sets identical certificates and authentication hooks (RADIUS/AD) across backends.
  • Connection draining: When removing a backend, enable graceful draining to avoid cutting active sessions. The LB should stop sending new connections to that backend but allow current TCP sessions to complete until idle timeout or manual termination.
  • Active-active with shared auth backend: Use centralized authentication (RADIUS/LDAP/AD) so that adding/removing SSTP servers does not affect credential verification. Do not rely on local-only user stores unless replicated and consistent.
  • State synchronization (if needed): SSTP itself does not support session failover; if you require failover of active tunnels, consider client-side reconnection mechanisms or architectures that use VPN concentrators that support session replication.

Security Considerations

  • Cipher suites: Enforce modern TLS versions (TLS 1.2 or 1.3) and strong cipher suites. Disable legacy protocols to prevent downgrade attacks.
  • Client certificates: Prefer EAP-TLS for strong, certificate-based client authentication where compliance or high assurance is required.
  • DoS and rate limiting: Long-lived TCP sessions are vulnerable to resource exhaustion attacks. Use upstream protections like SYN cookies, connection rate limits, and per-IP connection caps on the LB.
  • Logging and audit trails: Ensure TLS termination point or backend logs capture authentication events. If using passthrough, collect logs at the SSTP servers and centralize them for auditing.

Operational Tips and Troubleshooting

  • Adjust idle timeouts: Set LB TCP idle timeouts significantly longer than typical session keepalive intervals to prevent premature disconnection. Many LBs default to 60 seconds; consider 15–30 minutes or more depending on usage.
  • MTU/MSS clamping: Because SSTP encapsulates PPP frames over TLS, path MTU issues can lead to fragmentation. Configure MSS clamping on the LB or edge firewall to avoid PMTUD failures.
  • Monitoring metrics: Track active TCP connections, TLS handshake failures, authentication success/failure rates (from backends), and backend health. Correlate with LB metrics for early detection of saturation.
  • Certificate lifecycle: When rolling certificates, plan overlapping validity windows and use connection draining to avoid disconnecting active clients when backends are updated.
  • Custom SSTP probes: If possible, implement a probe that performs a TLS handshake and sends the minimal SSTP POST, verifying a 200 OK response, which confirms a full SSTP stack is ready.

Example Config Snippets (Conceptual)

Below are conceptual examples to illustrate the right direction—adapt them for your environment and LB product.

HAProxy (TCP mode, passthrough)

Use TCP mode and set long timeouts. Enable the proxy protocol if backends support it so servers can learn original client IPs.

  • mode tcp
  • option tcplog
  • timeout client 3600s
  • timeout server 3600s
  • balance roundrobin

NGINX (stream passthrough)

  • stream {
  • upstream sstp_backends { server 10.0.0.10:443; server 10.0.0.11:443; }
  • server { listen 443; proxy_pass sstp_backends; proxy_timeout 1h; }
  • }

For cloud providers, choose NLB (AWS), TCP/SSL load balancer (GCP), or Basic Load Balancer (Azure) for TLS passthrough.

Conclusion

Integrating SSTP VPNs behind load balancers can deliver scalable, highly available remote access, but it requires careful alignment of load balancer mode, session persistence, authentication requirements, and health checks. For the most compatible and secure deployments, use TCP passthrough LBs when you require client certificate authentication, ensure long idle timeouts and graceful draining, centralize authentication (RADIUS/AD), and implement TLS-aware health probes. Where TLS termination is necessary, plan for re-establishing equivalent authentication and secure forwarding of client identity information.

For detailed implementation guides and further reading on SSTP, load balancer selection, and example configurations tailored to specific platforms, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.