Secure Socket Tunneling Protocol (SSTP) offers an attractive combination of strong encryption and wide client compatibility, especially in restrictive network environments where other VPN protocols are blocked. While Ubiquiti EdgeRouter doesn’t ship with a turnkey SSTP server like some consumer routers, it’s fully capable of hosting an SSTP service with a combination of packages, certificates, firewall rules and routing. This guide walks you through a robust, production-oriented SSTP setup on EdgeRouter, with practical command snippets, configuration examples and troubleshooting tips suitable for webmasters, enterprise administrators and developers.

Why use SSTP on EdgeRouter?

SSTP tunnels TCP over TLS (typically TCP 443), which provides two main advantages:

  • Firewall-friendly connectivity: SSTP is very likely to work from restrictive networks since it uses the same port as HTTPS.
  • Strong transport security: The tunnel is encapsulated in SSL/TLS, providing authentication and encryption comparable to HTTPS when configured with proper certificates.

For organizations that require a dedicated IP on an edge device and want centralized control over client authentication, SSTP on EdgeRouter can be a solid option.

Prerequisites and planning

Before beginning, ensure you have the following:

  • EdgeRouter with a model that supports custom packages and sufficient CPU (EdgeRouter X/ERLite-3/ERPro generally work; CPU matters because TLS is CPU-intensive).
  • EdgeOS firmware updated to a recent stable release. Older versions may lack package repo compatibility.
  • A public static IP (or dynamic DNS) on the WAN interface so clients can reliably reach your SSTP endpoint.
  • Root/SSH access to the router and familiarity with the CLI.
  • Basic knowledge of iptables/edgeos firewall zones and routing.

Plan for certificate management: use a trusted CA (Let’s Encrypt or a commercial CA) to avoid client trust issues, or provision clients with your internal CA certificate if you prefer an internal PKI.

Overview of the setup steps

  • Install required software (stunnel/pppd/sstpd or use strongSwan with SSTP support depending on EdgeOS/firmware).
  • Create or import server certificate and private key.
  • Configure SSTP server to handle TLS and PPP user authentication (PAP/CHAP/MS-CHAPv2) or use certificate-based client auth.
  • Set up local IP pool, DNS and routes pushed to clients.
  • Apply firewall rules and NAT for client traffic.
  • Test connectivity and troubleshoot common issues.

Choosing an SSTP server implementation

EdgeOS doesn’t include an official SSTP daemon, but the community commonly uses one of these approaches:

  • sstpd – a lightweight SSTP server implementation (often compiled from source or available in some community repositories).
  • stunnel + pppd – use stunnel to accept TLS and then hand off to pppd for PPP negotiation. This is flexible but requires careful configuration.
  • use a VM/container behind the EdgeRouter – host an SSTP server (e.g., on a small Linux VM) and forward TCP/443 from EdgeRouter to that VM. This is often the easiest path for production as it offloads TLS processing.

For high-performance or production use, we recommend running the SSTP server in a small Linux VM/container on the same network and NAT/forward port 443 from the EdgeRouter to the VM. That simplifies troubleshooting and allows easier package management.

Server certificate: generating and deploying

Use a certificate signed by a public CA to avoid client certificate import headaches. Let’s Encrypt is a common choice but has short validity (90 days) and requires automation. For proof-of-concept or closed environments, you may use an internal CA and distribute the CA cert to clients.

Example using OpenSSL to generate a self-signed cert (for lab use):

openssl req -newkey rsa:4096 -nodes -keyout sstp.key -x509 -days 3650 -out sstp.crt -subj "/CN=vpn.example.com"

Combine key and cert into a PEM file for stunnel or sstpd:

cat sstp.key sstp.crt > /etc/ssl/private/sstp.pem

Configuring stunnel + pppd (example)

If you use stunnel on the EdgeRouter or VM, a sample stunnel configuration looks like this:

[sstp-server] accept = 0.0.0.0:443
connect = 127.0.0.1:444
cert = /etc/ssl/private/sstp.pem
; Optional: require client cert
; verify = 2

Then run an SSTP daemon or a small wrapper that listens on 127.0.0.1:444 and starts pppd for each connection. Alternatively, you can configure stunnel to run a script via the exec option to spawn pppd for each accepted connection.

pppd and authentication

Configure /etc/ppp/options.sstp (example):

debug
lock
noauth
mtu 1400
mru 1400

Use local IP server-side and remote IP pool

ms-dns 8.8.8.8
ms-dns 8.8.4.4
proxyarp
; Authentication file
auth

Use /etc/ppp/chap-secrets or pap-secrets to store user credentials:

username servername password *

For higher security, prefer MS-CHAPv2 with strong passwords, or client certificate authentication if supported by your server implementation.

EdgeRouter firewall and NAT configuration

Whether your SSTP server runs on the EdgeRouter or behind it, you must open and forward ports correctly. For a VM-based SSTP server:

  • Forward TCP port 443 from the EdgeRouter WAN to the internal SSTP server IP.
  • Allow established/related traffic.
  • Ensure the SSTP server’s outbound traffic is NATed to the public IP (source NAT/Masquerade) if you don’t have a routed public network.

Example EdgeOS commands to forward TCP/443 to internal host 192.168.1.10:

configure
set nat destination rule 100 description "SSTP forward"
set nat destination rule 100 destination port 443
set nat destination rule 100 inbound-interface eth0
set nat destination rule 100 protocol tcp
set nat destination rule 100 translation address 192.168.1.10
commit
save
exit

Add firewall rules to permit the traffic through the WAN_LOCAL or WAN_IN chain depending on how your EdgeRouter is structured.

Client IP addressing and routing

SSTP typically hands out private IP addresses to clients via PPP. Ensure the IP pool does not conflict with your LAN subnets. Example: assign 10.8.0.1 as server and 10.8.0.2-10.8.0.254 for clients. You can push routes/DNS via pppd options like ms-dns and route commands.

If you want clients to access LAN resources behind the EdgeRouter, add static routes or enable proxy ARP when appropriate. Also ensure local firewall rules allow VPN client subnet to reach internal networks.

Testing and verification

Steps to validate the setup:

  • From an external network, test TCP connection: telnet vpn.example.com 443 or openssl s_client -connect vpn.example.com:443 to inspect the certificate and TLS handshake.
  • On Windows, add a new VPN (SSTP) profile in Network and Sharing Center -> Set up a new connection or network -> Connect to a workplace. Use the server hostname and credentials. Verify that the certificate presented matches your server.
  • Check pppd logs and stunnel logs on the server for authentication and link-up messages. Look for IP assignment and route push messages.
  • From the client, verify IP, DNS and routes: Windows uses ipconfig /all, Linux ip addr and route -n or ip route.

Troubleshooting common issues

TLS handshake failing

Symptoms: OpenSSL s_client shows handshake errors. Check:

  • Certificate chain: ensure full chain (intermediate + leaf) is presented.
  • Cipher support: ensure server supports modern ciphers and the client accepts them.
  • Time synchronization: certificate validation fails if device time is wrong.

Authentication fails (PPP)

Symptoms: connection establishes TLS but PPP authentication fails. Check:

  • Correct format in chap-secrets/pap-secrets.
  • pppd options: ensure auth and the intended auth types (e.g., require-mschap-v2) are enabled.
  • Log verbosity: enable debug in pppd to get detailed messages.

Clients can connect but no internet access

Likely NAT or firewall issues:

  • Ensure server or EdgeRouter is NATing VPN client traffic to the public IP (source NAT).
  • Check FORWARD chain rules on the EdgeRouter and the VM.
  • DNS: ensure ms-dns is pushed or clients have resolvers to resolve external names.

Security hardening and best practices

  • Use certificates from a trusted CA to avoid trusting self-signed certs on all clients.
  • Prefer MS-CHAPv2 only when necessary and avoid older insecure auth methods. Better: use certificate-based client authentication if your server supports it.
  • Enforce strong TLS configs: disable SSLv3/TLS1.0 and prefer TLS1.2+/modern ciphers. Keep the SSTP server software updated.
  • Limit access by firewall rules to known source IPs if feasible, or rate-limit new connections to mitigate brute-force attacks.
  • Monitor logs on both the EdgeRouter and the SSTP server for repeated failed auth attempts or anomalous traffic patterns.
  • Plan certificate renewal: automate Let’s Encrypt renewal if used, and ensure the private key is securely stored.

Client configuration tips

Windows clients have built-in SSTP support and normally work with minimal configuration: specify server address, username/password, and optionally disable machine cert checking if using internal CA (not recommended). For Linux, use the network-manager-sstp plugin or sstp-client; for macOS and iOS, native SSTP support is limited—third-party apps (such as those available in App Store or open-source clients) are required.

Scaling and performance considerations

TLS (particularly AES and RSA operations) is CPU-bound. On busy gateways, offload SNI/TLS to dedicated hardware or use a VM on host with better CPU. Use session caching and reasonably sized MTU to reduce fragmentation. If many concurrent connections are expected, plan for multi-core processing and network throughput capacity.

Deploying SSTP on an EdgeRouter is feasible and often practical for environments that require a firewall-friendly VPN protocol. The recommended production approach is to host the actual SSTP server on a small Linux VM or container and use the EdgeRouter for NAT, routing and perimeter firewall enforcement—this yields easier maintenance and higher flexibility.

For more advanced guides, automation scripts and managed SSTP deployment options tailored to dedicated public IPs, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/. Dedicated-IP-VPN provides focused resources to help you deploy secure, reliable VPN services for your website or enterprise environment.