SSTP VPN for Split‑DNS: Practical Configuration and Best Practices

When deploying Secure Socket Tunneling Protocol (SSTP) VPNs for remote users, many organizations require precise control over domain name resolution. Split‑DNS (also called split‑brain DNS or split‑tunnel DNS) lets you route queries for internal domains to corporate resolvers while allowing public DNS queries to go to public resolvers. This article dives into practical configuration steps, troubleshooting techniques, and operational best practices for implementing SSTP VPN with split‑DNS—targeted at webmasters, enterprise architects, and developers responsible for secure remote access.

Why split‑DNS matters for SSTP deployments

Split‑DNS reduces attack surface and preserves performance. By ensuring internal DNS names are only resolvable through corporate DNS servers, you prevent leakage of internal topology to the public internet and keep sensitive hostnames private. At the same time, you avoid forcing all public DNS traffic through the VPN, which can reduce latency and bandwidth consumption for generic browsing.

With SSTP—an SSL/TLS‑based VPN commonly used on Windows platforms—the tunnel terminates over TCP port 443. SSTP clients receive PPP parameters over the tunnel, including DNS servers and DNS suffixes. Properly configuring those parameters and the client DNS behavior is essential to achieve reliable split‑DNS.

Key design considerations

• Split tunneling vs full tunneling: Decide whether only application/data traffic should go via VPN (split) or all traffic (full). Split‑DNS is relevant for split tunneling; if you use full tunnel, all DNS should normally be forced to corporate resolvers.
• DNS server placement: Place DNS resolvers reachable over the tunnel (ideally redundant and behind the VPN gateway), and configure conditional forwarders for internet and partner domains.
• Security controls: Prevent DNS leaks by firewalling client DNS to force queries to the intended resolver, and consider encrypted DNS inside the tunnel (DoH/DoT) for additional privacy.
• Client diversity: SSTP clients are often Windows built‑in clients; mobile and macOS clients may behave differently with split‑DNS. Account for cross‑platform differences.
• Certificate and SNI considerations: SSTP uses TLS; ensure certificates are trusted on clients and that SNI/HTTPS inspection rules on middleboxes don’t interfere with establishing the tunnel on TCP/443.

Practical configuration: Windows Server RRAS as SSTP endpoint

On Windows Server (RRAS), SSTP is integrated and can be configured to provide DNS and domain settings to VPN clients via PPP IPCP options. The basic steps:

1. Prepare the SSTP server and certificates

Install a certificate with a common name or SAN matching the public endpoint hostname clients connect to. The certificate must be trusted by clients (public CA or enterprise CA root trusted by client machines). Open firewall for TCP 443 to the SSTP service. Ensure the server has a public IP or a NAT rule forwarding 443 to it.

2. Configure RRAS IP address assignment and DNS

In the RRAS console, right‑click the server and open Properties > IPv4. Configure IP address assignment (DHCP or static address pool) for VPN clients. In the same place, specify the DNS servers you want clients to receive when they connect. You can also set the DNS primary domain (DNS suffix) that will be pushed.

These settings propagate via PPP IPCP so Windows clients automatically receive the provided DNS servers and suffix for the VPN interface.

3. Enable split tunneling and push routes

For split‑DNS you typically enable split tunneling so only specific networks route via the tunnel. In Windows VPN client properties, uncheck “Use default gateway on remote network” or use PowerShell: Set-VpnConnection -Name “CorpVPN” -SplitTunneling $true. On the server, push specific routes using RRAS static routes for the VPN client pool or use demand‑dial routing policies. Alternatively, use PowerShell on clients: Add-VpnConnectionRoute -ConnectionName “CorpVPN” -DestinationPrefix 10.0.0.0/8 -PassThru.

Split‑DNS techniques

There are multiple reliable ways to implement split‑DNS with SSTP. Choose based on infrastructure complexity and client OS behavior.

1. Push DNS servers and DNS suffix via PPP (recommended for Windows)

This is the simplest approach for Windows clients: configure RRAS to push internal DNS servers and the DNS suffix (e.g., corp.example.com). When clients query a short name or a name with that suffix, the VPN interface resolver will try the corporate DNS first. Command‑line checks: run ipconfig /all to see DNS servers bound to the VPN adapter and Resolve-DnsName host.corp.example.com to verify resolution.

2. Use conditional forwarders on corporate DNS

On corporate DNS servers, configure conditional forwarders for partner or cloud domains that should be resolved internally and forwarded to the appropriate authoritative servers. This keeps your internal namespace authoritative while offloading external resolution.

3. Local DNS proxy on the VPN gateway (dnsmasq/unbound)

If your SSTP endpoint is on Linux or appliance (SoftEther, pfSense), run a local DNS resolver that conditionally forwards queries for internal domains to internal DNS servers and forwards other queries to public resolvers. For example, dnsmasq supports conditional forwarding: server=/corp.example.com/10.1.1.10. Then point VPN clients to the gateway’s DNS address.

4. Client‑side DNS policies and DNS over HTTPS (DoH)

Modern Windows supports DNS policies and encrypted DNS. You can configure the client to use DoH resolver hosted inside the VPN or force DNS queries to the VPN interface. Use registry or Group Policy to lock down DNS settings if necessary. Be wary: consumer DoH clients (browsers) might bypass system DNS; control via enterprise policies.

Hardening and preventing DNS leaks

DNS leakage occurs when queries intended for internal resolvers are sent to public DNS. To prevent this:

• Implement firewall rules on the client network to block outbound UDP/TCP port 53 except via the VPN interface. On Windows, use Windows Firewall with Advanced Security to deny DNS to non‑VPN profiles.
• On the VPN gateway, implement iptables/nft rules or pf rules to NAT/redirect DNS hitting the gateway so that even if a client attempts to use an external resolver, it gets forced to the internal resolver.
• Educate users and lock down browser DoH settings via enterprise Group Policy to disable third‑party DoH or force it to an internal DoH endpoint.
• Enforce DNSSEC validation on resolvers where possible to protect integrity.

Troubleshooting tips and tools

Diagnosing split‑DNS issues requires checking both network and client DNS stacks. Useful commands and steps:

• On the client: ipconfig /all to confirm the VPN adapter’s DNS servers and DNS suffixes.
• Use Resolve-DnsName hostname -Server 10.1.1.10 to test direct queries to your internal DNS server.
• Use nslookup to inspect which server responds and whether the query goes over the VPN interface.
• On the server/gateway: capture traffic with tcpdump or Wireshark, e.g., tcpdump -i any port 53, to see whether DNS requests are arriving from the VPN subnet.
• Check RRAS logs and Event Viewer for IPCP/DNS option negotiation issues.
• Validate routing: route print (Windows) or ip route (Linux) to ensure destination prefixes for internal networks are sent via the VPN adapter.

Operational best practices

To run SSTP with split‑DNS in production reliably:

• Document DNS policies: Maintain a clear mapping of which domains should resolve internally and which should be public.
• Redundancy: Deploy at least two DNS resolvers reachable via the VPN and configure clients to receive both.
• Monitoring: Monitor DNS server health and query patterns. Set alerts for resolution failures or abnormal query spikes that may indicate misconfiguration or exfiltration attempts.
• Capacity planning: Ensure the VPN gateway and DNS servers can handle peak concurrent sessions and DNS QPS from remote users.
• Policy enforcement: Use Group Policy or MDM to lock VPN and DNS client settings and prevent users from changing DNS behavior that could cause leaks.
• Testing: Periodically test from different client OS versions and networks (home NAT, cellular) to detect behavior differences.

Example: configuring a Windows SSTP client via PowerShell

Quick example commands for a Windows client that will use split tunneling but receive internal DNS servers:

1) Create the VPN connection: Add-VpnConnection -Name “CorpVPN” -ServerAddress vpn.corp.example.com -TunnelType SSTP -AuthenticationMethod Eap -RememberCredential

2) Enable split tunneling client‑side: Set-VpnConnection -Name “CorpVPN” -SplitTunneling $true

3) Add a route for internal network via the VPN: Add-VpnConnectionRoute -ConnectionName “CorpVPN” -DestinationPrefix 10.0.0.0/8 -NextHop 0.0.0.0

After connecting, verify: ipconfig /all should show the VPN adapter’s DNS servers that were pushed by the SSTP server.

Common pitfalls

• Assuming browser DoH will follow system DNS—some browsers can bypass and send queries to external DoH providers, causing leaks.
• Not specifying DNS suffixes: short name lookups can fail if the correct suffix isn’t pushed or configured.
• Client firewall rules that block DNS to the VPN adapter while allowing public DNS out the default route.
• Certificate trust issues preventing SSTP from establishing, leading clients to fallback to alternative VPN methods with different DNS behavior.

Implementing split‑DNS with SSTP is a practical way to balance security and performance for remote users. The most robust solutions combine correct PPP DNS option settings, conditional forwarding at the DNS layer, client policy enforcement, and network‑level controls to block leaks. Regular monitoring, careful testing across client platforms, and clear documentation will keep the environment reliable and secure.

For additional implementation guides, example configs, and VPN service reviews, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.