When deploying SSTP (Secure Socket Tunneling Protocol) VPNs for users or customers, ensuring that DNS queries do not leak outside the encrypted tunnel is a critical security and privacy requirement. DNS leaks can expose browsing activity, internal domain lookups, and even the physical region of the user despite an otherwise solid VPN encryption channel. This article provides a pragmatic, technically detailed playbook for locking down SSTP VPNs to prevent DNS leaks across end systems, servers, and network infrastructure.

Why DNS leaks matter for SSTP

SSTP encapsulates PPP over HTTPS (TCP/443), offering good compatibility with firewalls and network address translation (NAT). However, because SSTP rides over the standard network stack, DNS traffic may still be generated by the operating system or applications outside the PPP interface. Common leak vectors include:

  • OS-level resolver preferences — Windows, macOS, and Linux may prefer locally configured DNS servers (IPv4/IPv6) or DNS over system services that bypass the PPP adapter.
  • Split tunneling or incorrect routing — If only certain subnets route through the VPN, DNS queries for non-routed destinations can egress through the ISP.
  • Application-level DNS — Browsers or apps using DNS-over-HTTPS (DoH) to external resolvers can circumvent the VPN unless specifically routed.
  • IPv6 misconfiguration — Many deployments forget to route IPv6 or disable IPv6 on the server/client, allowing IPv6 DNS traffic to leak.

Core principles for preventing DNS leaks

Approach DNS leak mitigation with layered controls. Relying on a single policy or client setting is fragile. Combine server-side enforcement, client configuration, and network controls:

  • Force all DNS to tunnel — Ensure the PPP link is the preferred path for every DNS request (IPv4 and IPv6).
  • Disable alternate resolver fallbacks — Prevent the OS or apps from using cached or statically assigned DNS servers when VPN is active.
  • Block non-VPN DNS egress — Use firewall rules to drop DNS traffic that does not originate from the VPN interface or IP range.
  • Detect and alert — Implement monitoring and periodic testing to detect regressions or misconfigurations.

Server-side SSTP configuration tips

On Windows Server Routing and Remote Access (RRAS) or Linux SSTP servers (e.g., sstpd), enforce DNS settings from the server when a PPP session comes up.

Windows RRAS

  • In RRAS, configure the IPv4 and IPv6 static address pools for clients and set DNS servers under the Network Policy or the Remote Access Policies so clients receive the intended DNS via PPP IPCP.
  • Enable the option to “Use default gateway on remote network” for user profiles to prevent split routing unless you intentionally permit split tunneling.
  • Consider Group Policy Objects (GPO) to set DNS suffix and prevent clients from changing DNS settings.

Linux SSTP servers

  • When using pppd together with sstpd, push DNS servers via pppd options: ms-dns 10.0.0.1 (for each resolver) in the options file or via ip-up scripts.
  • Use /etc/ppp/ip-up.d scripts to update client-side resolvers or to enforce iptables/nftables rules specific to the ppp interface.
  • Disable IPv6 DNS leakage by configuring pppd to advertise IPv6 routes and DNS (e.g., via radvd or ra daemon) or explicit RA suppression where appropriate.

Client hardening (Windows, macOS, Linux)

Client systems are the most common source of leaks. Apply the following specific steps per platform.

Windows

  • Set the PPP adapter to be the primary DNS source. This often happens automatically, but verify adapter metrics: lower metric gets priority. Use PowerShell to adjust metrics: Set-NetIPInterface -InterfaceAlias "PPP Adapter" -InterfaceMetric 10.
  • Disable Teredo and other IPv6 transition technologies if they are not routed through the VPN: netsh interface teredo set state disabled.
  • Disable Windows’ automatic “Smart Multi-Homed Name Resolution” to avoid parallel queries to multiple DNS servers: configure via Group Policy under Computer Configuration → Administrative Templates → Network → DNS Client → Turn off smart multi-homed name resolution.
  • Block DNS over non-VPN interfaces: use Windows Firewall with Advanced Security to create outbound rules that only allow UDP/TCP port 53 (and DoH ports if you want to control them) through the PPP interface or the VPN-assigned IP range.

macOS

  • Use network service ordering to prioritize the VPN interface. In System Preferences → Network, drag the VPN to the top of the list or use networksetup -ordernetworkservices.
  • Inspect /etc/resolv.conf after connection; macOS uses the system resolver and mDNSResponder. Use scripts triggered on connect/disconnect to ensure VPN-provided DNS servers are registered.
  • Disable DoH/DoT in browsers or enforce enterprise browser policy to route DoH through the VPN resolver.

Linux

  • Manage resolvers with resolvconf, systemd-resolved, or NetworkManager and make sure the PPP interface DNS is written to /etc/resolv.conf. Prefer systemd-resolved’s per-link DNS where available.
  • Force DNS via iptables/nftables: reject outbound UDP/TCP port 53 to any address that is not the VPN server or the internal DNS IPs.
  • Disable DNS-related services that may override settings (e.g., dnsmasq on NetworkManager) or configure them to use the VPN DNS.

Network and firewall rules to enforce DNS egress

Server and perimeter firewalls are the last line of defense. Explicitly deny DNS that tries to bypass the VPN.

iptables/nftables examples

  • Block all outbound DNS except from the VPN network and the server itself:
    • iptables -A OUTPUT -p udp –dport 53 -m owner ! –uid-owner pppd -j DROP (example idea; owner match depends on pppd user)
    • On routers: iptables -I FORWARD -p udp –dport 53 -s 192.168.0.0/24 -j DROP (allow only if source is VPN pool)
  • Better: DNS proxy on the server and a firewall rule that only allows DNS to the proxy IP. This centralizes DNS and simplifies auditing.

Router / Perimeter

  • On home or enterprise routers, block outbound DNS to the Internet for internal subnets; whitelist only the VPN server and internal resolvers.
  • Implement DNS ACLs on the perimeter DNS server so it refuses recursive queries from non-VPN addresses.

Handling DNS-over-HTTPS (DoH) and DoT

DoH and DoT in modern browsers and OSes can bypass system DNS. Tactics:

  • Disable DoH or DoT via enterprise policies in browsers (Firefox, Chrome, Edge support group policies or command-line flags).
  • Intercept and redirect DoH traffic at the firewall if permitted (e.g., block known DoH endpoints or port 443 connections to them; use SNI inspection or TLS interception only if legally and ethically acceptable within your environment).
  • Prefer offering your own DoH/DoT endpoint over the VPN; make clients use it via configuration management.

IPv6 — don’t forget it

IPv6 is a frequent cause of stealthy leaks. Options:

  • Fully support IPv6 in the VPN: assign IPv6 addresses and route DNS over the VPN, ensuring the client prefers VPN-provided AAAA records.
  • Alternatively, disable IPv6 on clients and servers where permissible to eliminate the leak vector.
  • Ensure firewall rules also cover port 53 over IPv6 and DoH endpoints addressed by IPv6.

Testing and continuous validation

Perform both manual and automated tests. Manual checks help during commissioning; automation prevents regressions.

  • Use online tools to reveal DNS and IP: ipleak.net, dnsleaktest.com, and Perfect Privacy DNS Leak Test. These show detected resolvers and whether queries originate from the VPN.
  • Perform packet captures (tcpdump/wireshark) on client and server: filter for DNS traffic (port 53, DoH patterns) and ensure the source/destination addresses are inside the VPN.
  • Automate periodic checks from representative endpoints using scripts or remote agents that log and alert on unexpected DNS endpoints.

Troubleshooting common scenarios

Client still showing ISP DNS after connecting

  • Verify PPP negotiation includes DNS options (IPCPOPT). If missing, set server-side options to push DNS.
  • Check adapter metrics and binding order on the OS; enforce metric preference for the PPP adapter.
  • Inspect local DNS services (dnsmasq, systemd-resolved) that may cache previous DNS; restart them after connection.

DoH active inside browser despite system settings

  • Use browser policies to disable DoH or configure DoH to point to the VPN resolver.
  • Temporarily block DoH endpoints at the firewall to confirm behavior and adjust policies accordingly.

IPv6 DNS leaks

  • Check IPv6 routing table for default routes that bypass the VPN. Remove or override them on connection.
  • Use firewall rules for ip6tables/nftables to block IPv6 DNS egress outside the VPN.

Operational recommendations

  • Document all DNS and routing configurations in your runbooks. Include expected DNS IPs for different client types.
  • Use configuration management (Ansible, Puppet) to enforce consistent DNS settings on servers and, where possible, clients.
  • Log DNS accesses centrally and correlate with VPN session logs to detect anomalous patterns (e.g., a user making DNS queries to unexpected public resolvers).
  • Train support staff to reproduce DNS leak checks and to know the common fixes (metric changes, firewall rules, disabling DoH).

Preventing DNS leaks in SSTP deployments requires attention to detail across the stack: server authentication and PPP provisioning, OS resolver behavior, application-level DNS features, and perimeter enforcement. By combining server-side pushes of DNS, client hardening, firewall enforcement, and continuous testing, you can reduce the attack surface significantly and maintain the privacy guarantees users expect.

For detailed guides on configuring dedicated DNS and VPN infrastructure or managed SSTP deployments, see Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.