Secure Socket Tunneling Protocol (SSTP) remains a robust option for remote access VPNs, especially in environments where SSL/TLS-friendly ports are required or when clients are behind restrictive NATs and proxies. When deploying SSTP in environments that rely on split-DNS — where internal names resolve to private addresses and external names to public addresses — careful planning is required to ensure reliable name resolution, certificate validation, and traffic routing. This article walks through practical steps and best practices for configuring SSTP VPN in split-DNS scenarios, covering server and client configuration, DNS strategies, certificate considerations, routing, firewall and NAT implications, and troubleshooting tips for administrators and developers.

Understanding the interaction between SSTP and split-DNS

Before configuring anything, it’s critical to understand the basic interactions:

  • SSTP uses TLS/SSL so the VPN server’s certificate (Common Name or Subject Alternative Name) must match the hostname clients use to connect.
  • Split-DNS means the same hostname resolves differently on internal vs. external networks (private IP internally, public IP externally), which affects both connectivity and certificate validation.
  • VPN tunneling and DNS resolution order determine whether a client resolves internal resources via internal DNS or through the VPN’s DNS once the tunnel is established.

These factors drive the configuration decisions: which DNS name clients connect to, how certificates are issued, how client routing and DNS suffixes are applied, and how to avoid DNS leaks or circular resolution problems.

Design considerations

Start by making choices that reduce complexity and improve security. Key design questions include:

  • Will clients connect to an external public hostname (e.g., vpn.example.com) that resolves to a public IP, or to an internal hostname when on LAN?
  • Do you require clients to use internal DNS servers for corporate name resolution once the VPN is connected?
  • Are split-brain DNS situations present (same name different records internally/externally)?
  • Do you control client configuration centrally (Group Policy, MDM) or rely on manual setup?

A common and recommended pattern is to use a single public-facing DNS name (FQDN) for SSTP that resolves to the public IP for external clients, and that same FQDN resolves to the internal (private) IP when clients are inside the corporate network. This simplifies certificate issuance and ensures the certificate CN/SAN always matches the FQDN clients use.

Server-side configuration: certificates, RRAS/IIS, and firewall

Certificate requirements and issuance

SSTP requires a server certificate that clients trust. Best practices:

  • Use a certificate with the server’s FQDN in the Subject Alternative Name (SAN); the CN may also be the FQDN.
  • Obtain certificates from a public CA if clients include unmanaged or BYOD devices; internal CA is acceptable for domain-joined managed clients.
  • Key usage must include Server Authentication (OID: 1.3.6.1.5.5.7.3.1).
  • Prefer RSA 2048/3072+ or ECDSA keys for stronger security and performance.

Example SAN entry: vpn.example.com (and optionally vpn.internal.example.com if internal clients use a different name).

Installing the certificate

On Windows Server (RRAS or NPS/IIS hosting SSTP):

  • Import the certificate into the Local Computer Personal store.
  • Ensure the certificate includes the private key and the corresponding CA chain is installed in Trusted Root (public CA) or Trusted Root/Intermediate (internal CA).
  • Configure RRAS or IIS bindings to use the certificate. For RRAS, use the Routing and Remote Access MMC to set the SSL certificate for SSTP.

RRAS and IIS considerations

Windows SSTP is implemented via the Web datagram over HTTPS. On Windows Server:

  • Enable and configure RRAS for VPN (Remote Access role) and enable SSTP.
  • Ensure the SSL certificate is selected for SSTP under RRAS properties.
  • If using NLB or reverse proxies, ensure proper handling of client IP and SSL passthrough or offload decisions; certificate matching must still be maintained.

Firewall and NAT

SSTP uses TCP port 443. Configure perimeter firewalls and NAT to forward TCP/443 to the internal SSTP server (or load balancer). If you use a reverse proxy:

  • Prefer SSL passthrough so RRAS sees the original TLS connection for certificate validation unless you reissue and install the proxy certificate and reconfigure clients.
  • Ensure stateful inspection does not interfere with long-lived TLS sessions.

DNS strategies for split-DNS

Authoritative zones and conditional forwarding

To support split DNS reliably, implement one of these strategies:

  • Split-horizon DNS (authoritative internal and external zones): Maintain an internal DNS zone for example.com with FQDN vpn.example.com resolving to the private IP, and the public zone at the public DNS provider with vpn.example.com resolving to public IP. This is the most common approach.
  • Conditional forwarders: Configure internal DNS servers to forward queries for the public domain to internal DNS servers that can resolve private addresses. Useful for multi-site architectures.
  • DNS policies (Windows Server 2016+): Use DNS Server policies to answer differently based on client subnet (works well for complex scenarios).

DNS suffix and search order on clients

Ensure clients receive the correct DNS suffixes via DHCP or Group Policy so that short-name resolution behaves predictably. When the VPN connects and supplies internal DNS servers, the client should prefer those for internal domains. Use Group Policy to push DNS settings for domain-joined machines.

Client configuration: routing, DNS, and authentication

Routing vs. split tunneling

Decide whether to route all traffic through the VPN (full tunnel) or only internal traffic (split tunnel). Each approach impacts DNS:

  • Full tunnel: All traffic, including DNS, usually goes through the VPN; easier to enforce internal DNS and policies but increases bandwidth usage on the server.
  • Split tunnel: Only traffic destined for internal networks uses the VPN; clients may still use external DNS for public names, so ensure internal DNS suffixes are prioritized for corporate names.

Windows client settings

On Windows clients using the built-in SSTP client (PPTP/L2TP/SSTP configured via Network Connections or rasphone):

  • Set the VPN connection to use the server name that matches the certificate (vpn.example.com).
  • In the VPN adapter properties, on the Networking tab -> IPv4 -> Advanced -> DNS, configure “Use default gateway on remote network” (for full tunnel) or uncheck it for split tunnel, and add DNS suffixes as needed.
  • Use PowerShell or rasphone.pbk/phonebook entries for mass deployment and automation.

Mobile and third-party clients

For iOS, Android, or custom clients, ensure the client supports SSTP and has the capability to set DNS suffixes or use push profiles from MDM. For unmanaged devices, prefer a public CA certificate so users don’t need to manually trust a private CA.

Advanced: handling certificate validation and internal name resolution loops

A common pitfall is that clients on the internal network attempt to connect to the public IP or external resolver and then fail certificate validation. To avoid this:

  • Ensure internal DNS resolves the SSTP FQDN to the internal VIP address so clients connect directly to the internal server without traversing NAT.
  • Do not publish different hostnames for internal vs external access whenever possible; using the same FQDN simplifies certificate and client configuration.
  • For environments where you must split names, include both internal and external names in the certificate SANs and ensure each name resolves correctly depending on client location.

Troubleshooting checklist and diagnostics

When issues arise, follow this practical checklist:

  • Certificate mismatch: Verify the client is connecting to the FQDN that appears in the certificate (check Subject/SAN).
  • Port reachability: Use telnet or Test-NetConnection (PowerShell) to verify TCP/443 connectivity to the SSTP endpoint.
  • TLS handshake: Capture packets with Wireshark to confirm TLS completion. Look for ClientHello/ServerHello sequences and certificate exchange.
  • DNS resolution: Use nslookup/dig on the client to ensure the FQDN resolves to the expected internal or external IP depending on network location.
  • Authorization and authentication: Inspect RRAS/NPS logs for rejected authentication attempts or missing RADIUS responses.
  • Routing problems: After successful connection, run ipconfig /all and route print on Windows clients to confirm DNS suffixes, DNS server order, and route entries.
  • Event logs: Check System and Application logs on both client and server for SSTP-specific errors (e.g., Event IDs related to Secure Socket Tunneling Protocol).

Security and operational best practices

  • Rotate certificates before expiration; enforce strong key sizes and algorithms.
  • Harden server OS and apply TLS best-practices (disable SSLv3, TLS1.0; prefer TLS1.2/TLS1.3 where supported).
  • Limit management interfaces and employ MFA for remote access. SSTP integrates well with RADIUS for MFA enforcement.
  • Monitor VPN connections, bandwidth, and authentication events centrally (SIEM) to detect abnormal activity.
  • Document split-DNS zones and maintain change control for both internal and external DNS so accidental misconfiguration does not break connectivity.

Deployment tips for scale and reliability

  • Use load balancers with session persistence (TCP or SSL) when deploying multiple SSTP servers; ensure the load balancer handles TCP/443 correctly and preserves client IP if required.
  • Use DNS TTLs wisely: low TTLs help when changing IPs, but excessive churn increases DNS load.
  • Where feasible, use DNS policies or geo-aware DNS to reduce latency for distributed clients while maintaining consistent certificate names.

Configuring SSTP VPN in a split-DNS environment requires careful alignment of DNS records, certificates, and client networking settings. By ensuring the VPN FQDN resolves appropriately depending on client location, using certificates that match the FQDN, and configuring DNS/stateful routing correctly, administrators can deliver secure and reliable remote access without name resolution surprises.

For more implementation guides, examples, and troubleshooting resources related to dedicated IP VPN setups, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.