Lock Down Cloud Database Connections with SSTP VPN — A Step-by-Step Guide

Securing access to cloud-hosted databases is a high-priority task for webmasters, enterprises, and developers. Exposing database ports to the public Internet increases risk from credential stuffing, automated scanning, and targeted attacks. One robust approach is to lock down database connections behind an SSTP VPN, forcing clients to authenticate to a VPN endpoint before they can reach the database. This guide covers the concept, design considerations, and step-by-step implementation details for deploying SSTP (Secure Socket Tunneling Protocol) to protect cloud databases, including platform-specific examples, firewall rules, and database-side configuration.

Why SSTP for database protection?

SSTP encapsulates PPP traffic over an HTTPS TLS tunnel (TCP/443). That provides several advantages for database protection:

• Reliable connectivity through restrictive networks: SSTP runs over TCP/443, which is almost always allowed through corporate proxies and restrictive NATs.
• TLS-secured transport: SSTP leverages TLS, so the tunnel is encrypted end-to-end.
• Native support on Windows clients: Windows has built-in SSTP client support, simplifying deployment for Windows-heavy organizations.
• Possible to bind database access to VPN-only addresses: Once a VPN is in place, you can restrict database access to the VPN subnet or a dedicated egress IP.

High-level design and prerequisites

Before implementation, design the topology. Two common models:

• VPN server public endpoint + cloud database in private subnet: VPN server sits in a public-facing subnet (or DMZ); database is in a private subnet and only accepts connections from the VPN server / VPN client subnet or a dedicated NAT IP.
• Cloud-managed VPN + private endpoint: Use cloud-managed SSTP-capable gateways (rare) or deploy SSTP server in the cloud and place DB in same VPC/VNet private zone.

Prerequisites:

• Public IP or DNS name for the SSTP endpoint (TCP/443).
• Server platform: Windows Server (RRAS) for native SSTP or Linux SSTPd implementation (e.g., sstp-server/sstpd or ppp + sslwrap).
• Valid TLS certificate (SAN) for the SSTP server. Self-signed can work for controlled environments, but public CA cert is recommended for broad client compatibility.
• Admin access to cloud security groups / firewall to create rules allowing only VPN-origin traffic to DB port (e.g., 5432 for PostgreSQL, 3306 for MySQL).

Step 1 — Provision and secure the SSTP server

Option A: Windows Server RRAS (recommended for Windows clients)

Windows Server’s RRAS provides a straightforward SSTP setup. Key steps:

• Install the Remote Access role (Routing and Remote Access).
• Obtain and install a TLS certificate bound to the SSTP hostname: use an internal CA or public CA. Certificate should have a Subject Alternative Name (SAN) matching the DNS name used by clients.
• Configure RRAS: enable VPN, choose SSTP, configure authentication (RADIUS or Active Directory). Configure address assignment (static pool or DHCP).
• Open TCP/443 on the server and any perimeter firewall. If NAT exists, forward 443 to the SSTP server.

Example PowerShell steps (simplified):

Install-WindowsFeature -Name DirectAccess-VPN -IncludeManagementTools

Use the RRAS MMC to configure SSTP and bind the certificate. For production, integrate with RADIUS (e.g., NPS) to centralize authentication and MFA.

Option B: Linux SSTP server

Open-source implementations exist: sstp-server (from ppp project) or sstpd. A common approach is sstpd + ppp and systemd. Outline:

• Install sstpd (package name varies) or build from source.
• Install a TLS certificate (server.crt and server.key), set permissions (600 on private key).
• Configure ppp options for DNS, routes, and IP pool.
• Open TCP/443 on the host and forward if behind NAT.

Basic iptables to allow SSTP and NAT VPN clients to access internal DB subnet:

iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE

Step 2 — Certificate management

SSTP requires a TLS server certificate. Use these guidelines:

• Prefer certificates from a public CA for broad trust.
• If using an internal CA, ensure clients trust the root CA (domain-joined machines typically do).
• Use a certificate with a long enough key (2048+ RSA or ECDSA) and modern TLS ciphers enabled at the server.

Generate a self-signed cert (example OpenSSL):

openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key -subj "/CN=vpn.example.com"

Step 3 — VPN authentication and authorization

Authentication options:

• Local username/password on the VPN server (simple, not scalable).
• Active Directory integration (for Windows environments) with user/group-based authorization.
• RADIUS (NPS, FreeRADIUS) for centralized auth and MFA integration.

Best practice: combine RADIUS with MFA to harden access. Configure RADIUS clients and use secure shared secrets between SSTP server and RADIUS.

Step 4 — Networking: IP pools, routing, and dedicated egress IP

Decide IP addressing for VPN clients. Typical choices:

• Private subnet per VPN (e.g., 10.10.10.0/24). Use non-overlapping ranges.
• Push routes to the database subnet or enable full tunnel (route-all) depending on policy.
• For stricter control, SNAT VPN client traffic to a single dedicated egress IP (the server’s public IP or a NAT IP). This makes it easy for cloud DB security groups to whitelist one address.

Example NAT rule to SNAT VPN clients to server public IP (iptables):

iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j SNAT --to-source 203.0.113.45

Where 203.0.113.45 is the dedicated public IP assigned to the SSTP server.

Step 5 — Lock down the cloud database

On the cloud provider side, restrict who can connect to the DB:

• Configure security groups / firewall rules to allow DB port only from the SSTP egress IP (203.0.113.45) or the VPN subnet CIDR.
• Disable public accessibility for managed DB services where possible (AWS RDS: set Publicly Accessible = No; use private subnets + security groups).
• For additional protection, use database-level SSL/TLS and enforce host-based restrictions in DB config.

AWS Security Group example (conceptual):

Allow inbound on TCP/5432 from 203.0.113.45/32 (or the VPN subnet).

Database configuration examples

PostgreSQL (postgresql.conf + pg_hba.conf)

• postgresql.conf: set listen_addresses = ‘localhost,10.10.20.5’ (only the private DB IP and loopback).
• pg_hba.conf: add a line to allow VPN subnet:

host all all 10.10.10.0/24 md5

MySQL / MariaDB

• Edit my.cnf: bind-address = 10.10.20.5 (private DB IP only).
• GRANT privileges to user@’10.10.10.%’ or to specific hostnames/IPs.

Step 6 — Client configuration and deployment

Windows clients (native SSTP):

• Create a new VPN connection (Settings > Network & Internet > VPN): Server name = vpn.example.com, VPN type = SSTP, sign-in info = username/password or smart card.
• If using an internal CA, ensure the client trusts the CA root certificate.
• Force all traffic through the VPN if you want the DB traffic to always exit via the VPN egress IP. In the VPN connection properties > Networking > IPv4 properties > Advanced, uncheck “Use default gateway on remote network” depending on split-tunnel needs.

Linux and macOS: Use sstp-client (Linux) or SSTP client implementations. Configure user credentials and CA certificate trust store.

Step 7 — Test connectivity and verify access control

Testing checklist:

• From a machine outside the VPN: confirm you cannot connect to the DB port (telnet ip port or nmap).
• Connect via SSTP VPN and confirm you can reach the DB (psql, mysql client), verify source IP (SELECT inet_client_addr() in PostgreSQL or check connection status) shows the VPN-side IP or NATed egress.
• Check logs on the SSTP server and DB server for connections and authentication events.

Monitoring, logging, and hardening

Operational best practices:

• Enable detailed logs on the SSTP server (connection start/stop, auth success/failure).
• Ship logs to a centralized SIEM for alerting on anomalies.
• Rotate credentials and enforce MFA where possible.
• Harden the SSTP server: timely OS patches, minimal services, host-based firewall, and intrusion detection.
• Consider high availability: put SSTP servers behind a load balancer or use active/passive failover with floating IPs.

Common pitfalls and troubleshooting

• Certificate mismatch errors: ensure the SSTP DNS name matches the certificate CN/SAN.
• MTU/fragmentation: databases over PPP might need adjusted MTU; lower to 1400 if you see fragmentation.
• Split-tunnel pitfalls: if split tunneling is enabled, ensure routes for the DB subnet are pushed correctly; otherwise traffic may try the public network.
• Cloud NAT egress changes: if the SSTP server uses ephemeral public IPs, update the DB security group when IP changes. Use an Elastic/Static IP where possible.

Scaling and HA considerations

For larger deployments:

• Use a fleet of SSTP servers with a front-end load balancer that preserves client TLS session behavior and forwards TCP/443 to servers.
• Assign a stable elastic IP for NAT or use a NAT gateway so DB security rules do not need frequent updates.
• Automate configuration with IaC tools (Terraform, CloudFormation) to ensure consistent security group rules and server buildouts.

Conclusion: Deploying SSTP as a gatekeeper to your cloud databases is a pragmatic way to reduce attack surface while preserving connectivity in restrictive environments. By combining a properly configured SSTP server, strict cloud firewall rules, and database-level host restrictions, you can ensure that only authenticated and authorized VPN clients reach your data stores.

For more deployment patterns, detailed product comparisons, and static IP VPN services that integrate with these practices, visit Dedicated-IP-VPN.