Secure Socket Tunneling Protocol (SSTP) remains a compelling choice for VPN deployments where reliable TCP-based connectivity over port 443 is required—particularly for users behind restrictive firewalls or captive portals. When SSTP demand grows beyond a single server, deploying a high-availability, scalable load balancing layer becomes essential. This article dives into the technical architecture and operational considerations for building a scalable, secure SSTP VPN platform using a Network Load Balancer (NLB). It targets site operators, enterprise networking teams, and developers building managed VPN services.

Why use an NLB for SSTP?

Network Load Balancers operate at Layer 4 and are optimized for high-performance TCP traffic forwarding. SSTP tunnels are TCP sessions encapsulated in SSL, so an NLB’s ability to perform transparent TCP passthrough with minimal latency makes it an ideal front-end. Key reasons to choose an NLB:

  • High throughput and low connection latency for TCP flows.
  • Support for millions of concurrent connections with efficient connection tracking.
  • Transparent IP preservation (source IP passthrough) on many NLB implementations, enabling backend servers to see client addresses for logging and policy decisions.
  • Integration with autoscaling groups and health checks for dynamic capacity management.

Design patterns for SSTP behind an NLB

There are two primary design approaches depending on where you terminate TLS/SSL:

1. TLS passthrough to SSTP servers (recommended)

With passthrough, the NLB forwards raw TCP traffic to backend SSTP servers without decrypting it. This preserves end-to-end TLS and server certificate validation, which is important for SSTP’s security model. Benefits include:

  • End-to-end encryption maintained; backend servers validate client traffic and present certificates.
  • Backend servers can implement per-connection policies, client certificate authentication, and logging.
  • No need to replicate private keys at the load balancer layer.

2. TLS termination at the load balancer

Terminating TLS at the NLB (or a frontend proxy) is less common for SSTP because SSTP expects TLS on the server. If termination is used, the load balancer must re-encrypt traffic to backend SSTP endpoints or forward unencrypted traffic, which weakens security and complicates SSTP semantics. Use this only when you need centralized certificate management and can ensure secure, trusted connections between the NLB and backend servers (e.g., inside private networks).

Session affinity and connection management

SSTP creates persistent TCP sessions for the lifetime of the VPN tunnel. Proper connection management is required to minimize session disruptions during scaling and failover:

  • Connection draining — When removing a backend instance, enable connection draining (deregistration delay) to allow established SSTP sessions to finish gracefully instead of being reset.
  • Session stickiness — Layer 4 load balancers generally do not offer application-layer sticky sessions. However, because SSTP is a long-lived TCP connection, the NLB will maintain the 5-tuple (client IP, client port, VIP, VIP port, protocol) binding for the lifetime of the connection. Restarting backend instances or rebalancing can break sessions—plan maintenance windows accordingly.
  • Source IP preservation — Use NLB features that preserve source addresses so backends can make policy decisions based on real client IPs (logging, geo-IP, access control).

Health checks tailored for SSTP

Health checks for SSTP should be conservative and reflect the nature of the service. Typical approaches:

  • TCP-level health checks on the SSTP listening port (default 443). These confirm the backend accepts TCP connections.
  • Application-level probes where a minimal SSTP handshake is simulated. Since SSTP handshake requires SSL/TLS negotiation and SSTP-specific messages, implement a lightweight probe that performs a TLS hello and expects a valid server cert response.
  • Longer probe intervals and retry thresholds to avoid false-positives on transient overload.

Security considerations

Securing a multi-node SSTP deployment involves several layers:

  • Certificate management — Use a robust PKI for server certificates. If using passthrough, maintain certificates on backend servers. Rotate and revoke certificates via automation (Cert Manager, ACME where possible, or centralized PKI tools).
  • Client authentication — SSTP supports user/pass or certificate-based client authentication. For high assurance, implement EAP-TLS or mutual TLS to authenticate clients with client certs issued by your CA.
  • Network segmentation — Place SSTP backends in a private subnet only accessible from the NLB. Apply strict security group / firewall rules to limit management access to trusted IPs.
  • DDoS mitigation — NLBs provide basic DDoS protection, but layer 3/4 attacks can still affect your infrastructure. Use cloud DDoS services and autoscaling to absorb volumetric spikes.
  • Logging and auditing — Capture TLS handshake metadata, client IPs, certificate details, session durations, and bytes transferred. Centralize logs for analysis and incident response.

Scaling SSTP backends

Autoscaling SSTP servers requires careful orchestration because SSTP sessions are stateful. Best practices:

  • Scale out based on connection metrics — Monitor active TCP connections and per-instance CPU/memory and scale when thresholds are crossed.
  • Use graceful shutdown hooks to deregister instances from the NLB before terminating, allowing connection draining.
  • Ensure all SSTP instances use consistent configuration (certificates, authentication backends, routing policies). Configuration drift can cause inconsistent client experiences.
  • Leverage centralized authentication and session stores if session mobility is required (e.g., RADIUS, LDAP, or token-based auth). Note: migrating in-flight SSTP sessions between instances is impractical—the usual approach is to let sessions persist on their original host.

Performance tuning and TCP considerations

SSTP encapsulates traffic in TLS over TCP, which can create head-of-line blocking and performance challenges. Optimization techniques:

  • MSS clamping and MTU tuning — Ensure backend servers and clients negotiate an MTU that accounts for SSTP and TLS overhead to avoid fragmentation. Configure MSS clamping on firewall or VPN server interfaces if clients experience path MTU issues.
  • TCP keepalive and timeouts — Adjust keepalive intervals to detect dead peers sooner without prematurely tearing down valid mobile clients.
  • SSL/TLS parameters — Use modern TLS versions and cipher suites that balance performance and security. Enable session resumption (session tickets or session IDs) to speed up reconnections.
  • Offload considerations — Avoid TLS offloading at the NLB if you rely on backends for certificate validation. If offloading is necessary, ensure backend-to-load-balancer links are on private networks with encryption or strong access controls.

Observability and operations

Operational visibility is essential for maintaining SLA and troubleshooting:

  • Collect metrics: active sessions, connection rate, bytes in/out, TLS handshake failures, auth failures.
  • Instrument health dashboards (CloudWatch, Prometheus, Grafana) and set alerts for threshold breaches.
  • Aggregate logs: VPN server logs (SSTP/TLS), authentication logs (RADIUS/LDAP), and NLB connection logs for end-to-end traceability.
  • Perform regular chaos and failover testing to validate connection draining and autoscaling behavior.

Example architecture

A robust deployment typically includes:

  • An internet-facing NLB with listeners on TCP/443 forwarding to an autoscaling group of SSTP servers.
  • A private subnet with SSTP servers running hardened OS images and VPN daemons configured for SSTP.
  • Centralized authentication (RADIUS or LDAP) and a centralized logging endpoint.
  • Monitoring pipeline for metrics and logs, along with DDoS/edge protections.

Migrating from single-server SSTP to NLB-based architecture

Migration steps to minimize customer impact:

  • Deploy NLB and new SSTP nodes in parallel with the existing server.
  • Replicate certificates and authentication backend configurations to the new nodes.
  • Begin sending a portion of new connections to the NLB while still accepting direct connections to the legacy server during testing.
  • Monitor client behavior, handshake success rates, and application performance. Tune MTU, MSS, and TLS settings as needed.
  • Once confident, switch DNS VIPs to the NLB and decommission or repurpose the legacy server after ensuring session draining.

Building a scalable SSTP VPN platform with a Network Load Balancer provides a high-performance, resilient foundation for delivering TCP-based VPN tunnels at scale. The key is to preserve end-to-end security through TLS passthrough, implement conservative health checks, plan for stateful connection lifecycle management, and implement robust monitoring and certificate lifecycle management. With these elements in place, operators can deliver a reliable SSTP service that scales to meet enterprise and large user-base demands.

For more detailed guides and managed solutions, visit Dedicated-IP-VPN.