When clients connect via SSTP but hostnames fail to resolve, it’s one of the most common and frustrating issues network administrators and developers face. This article provides a practical, step-by-step troubleshooting guide tailored for site owners, enterprise administrators, and developers. It covers both client-side and server-side checks, diagnostic commands, and configuration fixes to help you restore reliable DNS resolution over SSTP VPN connections.

Understanding the problem: why DNS breaks over SSTP

SSTP (Secure Socket Tunneling Protocol) encapsulates PPP traffic inside an SSL/TLS tunnel over TCP port 443. Because SSTP uses a PPP interface and may change the client’s routing and DNS settings at connection time, DNS problems can arise for several reasons:

  • Client does not receive or apply DNS server settings pushed by the VPN server (PPP/DHCP issues).
  • DNS requests are routed incorrectly—sent via the client’s physical interface instead of the VPN tunnel (routing/split-tunnel issues).
  • Firewall or packet inspection blocking DNS (UDP/TCP 53) or interfering with TCP-over-TCP (SSTP encapsulation).
  • Incorrect server-side DNS forwarding, conditional forwarding, or DNS server availability.
  • DNS suffixes, search lists, or domain policies are missing, causing single-label lookups to fail.
  • Client OS-specific bugs (e.g., Windows DNS client cache, interface metrics, or DNS over HTTPS interactions).

Preparation: collect diagnostic information

Before changing anything, gather the following from a representative affected client and from the SSTP server:

  • Client OS and version (Windows 10/11, Server OS, Linux distro).
  • Output of ipconfig /all (Windows) or ip addr, resolvectl status (Linux).
  • Output of route print (Windows) or ip route (Linux).
  • Results of DNS tests: nslookup, dig, and ping to DNS server IP.
  • VPN server logs (RRAS, SoftEther, Stunnel, or other SSTP software).
  • Firewall logs for port 53 and TCP/443.

Step 1 — Verify the SSTP tunnel and IP configuration

Start by confirming the SSTP tunnel is established and the client has a VPN-assigned IP and DNS addresses:

  • Windows: run ipconfig /all. Look for the PPP adapter corresponding to the SSTP connection. Verify the assigned IPv4 address, DNS servers, and DNS suffix.
  • Linux: check ip addr and the SSTP client status (e.g., sstpc or NetworkManager logs). Inspect /etc/resolv.conf or systemd-resolved (resolvectl status).
  • If the DNS server fields are empty or point to the client’s ISP, the VPN server did not push DNS settings properly.

Troubleshooting hints

  • If the PPP adapter has no DNS servers, inspect the VPN server’s PPP settings. For Microsoft RRAS, check the IPv4 Address Assignment and DNS settings in the server’s properties.
  • For Linux SSTP server implementations, ensure you have PPP configuration scripts (e.g., /etc/ppp/options, ) that push DNS (using ms-dns or push options).

Step 2 — Test DNS reachability across the tunnel

Use direct IP queries and name lookups to determine if DNS requests can reach the server and get responses:

  • Try pinging the VPN DNS server IP: ping <dns-ip>. If ICMP is blocked, try tcping <dns-ip> 53 or use nmap -p 53 <dns-ip>.
  • Use nslookup <hostname> <dns-ip> or dig @<dns-ip> <hostname> to query the DNS server directly. This bypasses the client resolver cache and reveals whether the DNS server can respond.
  • If direct queries succeed but normal lookups fail, the issue is likely the client resolver configuration or route selection.

Step 3 — Check routing and split tunneling

DNS traffic may be routed out the wrong interface if split tunneling is enabled or interface metrics are misconfigured.

  • On Windows, run route print and inspect the routes and interface metrics. A default route with lower metric on the physical adapter can cause DNS/server traffic to bypass the tunnel.
  • Ensure the VPN connection is configured to “Use default gateway on remote network” if you want all traffic to go through the tunnel (classic full-tunnel behavior).
  • Alternatively, if you require split-tunneling, add explicit static routes for DNS servers and internal subnets so DNS goes via the VPN interface.

Fixes

  • Set proper interface metrics: on Windows, under the network adapter IPv4 properties > Advanced > uncheck automatic metric and set a lower metric for the VPN adapter.
  • Use Group Policy or connection scripts to push routes to clients at connection time (e.g., route add commands in ip-up scripts on Linux PPP).

Step 4 — Verify DNS search suffix and domain policies

Single-label hostnames rely on DNS search suffixes. If these are missing, fully qualified domain names (FQDNs) are needed.

  • Check the DNS suffix in ipconfig /all. If the VPN should provide a DNS suffix (e.g., corp.example.local), ensure the VPN server pushes it.
  • For Windows domain-joined machines, Group Policy can configure DNS suffix search lists. Confirm policies apply after connection (run gpresult /h gp.html or gpupdate /force).

Step 5 — Inspect DNS server and forwarding configuration

Even if the client is configured correctly, the DNS server at the other end might be unable to resolve certain records or may not accept queries from the VPN subnet.

  • On the DNS server, check access control lists (ACLs), recursion settings, and conditional forwarders. Ensure the DNS server will answer queries from the VPN pool.
  • If internal names require forwarding to an authoritative internal DNS, confirm forwarding rules are in place. Check logs for failed queries and timeouts.

Step 6 — Client-side resolver and cache issues

Client resolver caches or the OS DNS client service can misbehave.

  • On Windows, flush the DNS cache: ipconfig /flushdns, and restart the DNS Client service if needed: net stop dnscache && net start dnscache.
  • Check netsh interface ipv4 show dns to confirm which DNS servers are bound to which interfaces.
  • Disable problematic features temporarily (e.g., DNS over HTTPS or third-party DNS apps) that might override system DNS settings.

Step 7 — Firewall, DPI, and MTU considerations

Network devices may block or alter DNS traffic. Also, SSTP’s TCP-over-TCP nature can expose MTU/path-MTU issues.

  • Verify that firewalls allow UDP and TCP port 53 between VPN clients and DNS servers. Some environments use DNS only over UDP, others also allow TCP for larger responses.
  • Deep packet inspection or TLS interception appliances may interfere with SSTP behavior, indirectly impacting DNS if reassembly fails. Check logs for dropped TCP segments or session resets.
  • MTU issues can cause truncated DNS-over-TCP responses. Try lowering MTU on the client VPN interface (or set MSS clamping on routers) to test.

Advanced diagnostics: packet captures and logs

If the above steps don’t reveal the culprit, capture traffic:

  • On the client, capture traffic with Wireshark while performing lookups. Filter by DNS (port 53) and by the VPN virtual adapter’s IP. Look for DNS queries leaving the wrong interface or for no DNS traffic at all.
  • Capture on the server side to confirm whether queries reach it and whether it replies. Compare timestamps to detect dropped replies or asymmetric routing.
  • Examine server logs (RRAS event logs, DNS server logs) for authentication or permission errors and for any PPP negotiation warnings.

Platform-specific notes

Windows SSTP clients

Windows clients commonly use the built-in SSTP WAN Miniport. Watch for:

  • Automatic metric overrides: Windows may set metrics dynamically—explicitly configure metrics if required.
  • Enterprise features: Windows 10/11 may default to DNS over HTTPS or use the “Secure DNS” feature—ensure it doesn’t bypass VPN DNS unless intended.

Linux and macOS clients

Linux SSTP clients (e.g., sstp-client or network-manager-sstp) often rely on pppd scripts to push DNS settings. Ensure your /etc/ppp/ip-up scripts call resolvconf or update systemd-resolved.

macOS SSTP support requires third-party clients. Ensure those clients update the macOS resolver via the appropriate APIs.

Prevention and best practices

  • Push DNS and suffix at VPN negotiation: Configure your SSTP/PPP server to advertise DNS server IPs and DNS suffixes during PPP negotiation.
  • Use explicit routes for DNS servers: When using split tunneling, ensure DNS server IPs are routed via the tunnel.
  • Monitor DNS server health: Keep DNS servers reachable, patched, and monitored for query volume and latency.
  • Document client configurations: Use configuration profiles or Group Policy for consistent behavior across enterprise clients.
  • Test from multiple OSes: Validate VPN behavior from Windows, Linux, and macOS to detect platform-specific anomalies.

When to escalate to server or network teams

After client-side checks, escalate if you find:

  • Server isn’t pushing DNS settings (server-side PPP configuration issue).
  • DNS server rejects queries from the VPN subnet (ACL/conditionals required).
  • Firewall or DPI devices are dropping DNS or breaking TCP streams for SSTP.
  • Asymmetric routing or provider-level issues that require network team intervention.

Summary: DNS resolution failures over SSTP typically result from misapplied DNS settings, routing/split-tunneling misconfiguration, firewall/DPI interference, or DNS server-side problems. Use a systematic approach: verify the tunnel and IP/DNS assignment, test direct DNS queries, inspect routes and interface metrics, review server-side DNS and PPP settings, and capture packets if necessary. Applying these steps will resolve most SSTP DNS issues encountered by site administrators and developers.

For further resources and guides about managing VPNs and DNS in enterprise environments, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.