Implementing split‑DNS alongside a PPTP VPN lets remote clients resolve internal hostnames via corporate DNS servers while keeping public name resolution local — a practical approach for organizations that want seamless access to intranet resources without forcing all Internet traffic through the VPN. Below is a detailed, hands‑by‑step technical guide covering server and client configuration, DNS forwarding options, routing and firewall considerations, and troubleshooting tips. The instructions assume familiarity with Linux server administration, basic Windows client settings, and general networking concepts.

Why split‑DNS with PPTP?

Split‑DNS (also known as split‑horizon or split‑DNS resolution) directs DNS queries for internal domains to internal DNS servers and sends public DNS queries to external resolvers. When used with PPTP VPNs, split‑DNS ensures that:

  • Internal names (e.g., host.corp.local) resolve to internal IPs via corporate DNS.
  • Public names (e.g., example.com) continue to be resolved by public resolvers or the client’s default DNS.
  • Only DNS queries for internal zones flow over the VPN, limiting exposure of client DNS traffic and reducing latency for external browsing.

High‑level architecture

The typical components are:

  • A Linux VPN server running pptpd or another PPTP implementation.
  • Internal DNS server(s) (Bind9, Windows DNS, dnsmasq) reachable from the VPN server.
  • Clients (Windows, macOS, Linux) connecting via PPTP and receiving DNS settings from the VPN server.
  • Firewall/NAT rules on the VPN server to route traffic between the VPN interface and the internal network.

Server prerequisites and network assumptions

Example addressing used in the steps below (adjust to your network):

  • Public interface: eth0 (public IP 198.51.100.10)
  • Internal network: 10.0.0.0/24, DNS server at 10.0.0.53
  • PPTP VPN network: 172.16.100.0/24

Ensure IP forwarding is enabled on the VPN server:

sysctl -w net.ipv4.ip_forward=1 and add net.ipv4.ip_forward=1 to /etc/sysctl.conf for persistence.

Installing and configuring pptpd (Linux)

On Debian/Ubuntu based systems:

apt update && apt install pptpd

Edit /etc/pptpd.conf to configure the local and remote IP ranges:

localip 198.51.100.10
remoteip 172.16.100.100-172.16.100.199

Configure authentication in /etc/ppp/chap-secrets using the format:

username pptpd password *

To push internal DNS servers to clients, add ms‑dns options in /etc/ppp/options.pptpd or /etc/ppp/chap-secrets via server options. Example in /etc/ppp/options.pptpd:

ms-dns 10.0.0.53

You can add multiple ms-dns lines to provide a primary/secondary internal DNS pair. Many PPTP clients (especially Windows) accept these Microsoft‑style DNS options and will set the VPN interface DNS accordingly.

Alternative: pushing DNS via PPP ip-up script

On non‑Windows clients or to gain more control, use the PPP ip-up hook to update resolver settings when the VPN connects. Create /etc/ppp/ip-up.d/00vpn-dns:

#!/bin/sh
# $1 is interface name (ppp0 usually)
VPN_DNS="10.0.0.53"
echo "nameserver $VPN_DNS" > /etc/resolv.conf.pptp.$1
mv /etc/resolv.conf.pptp.$1 /etc/resolv.conf

Make it executable: chmod +x /etc/ppp/ip-up.d/00vpn-dns. Implement a matching ip-down script to restore the previous resolver.

DNS server options for split‑DNS

There are several ways to implement split‑DNS behavior on the server side:

1) dnsmasq: domain-specific forwarding

dnsmasq can be used on the VPN server to forward specific domains to internal DNS servers while forwarding everything else to upstream resolvers. Example configuration in /etc/dnsmasq.d/split.conf:

server=/corp.local/10.0.0.53
server=8.8.8.8

Start dnsmasq and configure the PPP server to use the local dnsmasq (127.0.0.1 or the VPN server IP) as the DNS passed to clients. dnsmasq will then ensure queries for corp.local go to 10.0.0.53 while other queries go to 8.8.8.8.

2) Bind9 views or conditional forwarding

If you run Bind9, configure conditional forwarders or views that serve internal zones only to clients from the VPN prefix. A simple forward zone in named.conf.local:

zone "corp.local" { type forward; forwarders { 10.0.0.53; }; };

Then make the VPN server’s DNS (127.0.0.1) the resolver for VPN clients.

3) Windows DNS + RRAS

If the internal DNS is Windows Server, configure DNS conditional forwarders for specific zones and push the Windows DNS server address to VPN clients (via ms‑dns or DHCP options). RRAS can also be used to assign DNS on Windows‑to‑Windows setups.

Routing and firewall considerations

To allow VPN clients to reach internal services but not route all traffic via VPN, use selective routing and firewall rules:

  • Add routes on the client to reach internal subnets via the VPN. On Windows clients, uncheck “Use default gateway on remote network” in the VPN adapter IPv4 advanced settings. This enables split tunneling so only traffic destined for internal networks goes over the VPN.
  • On Linux clients, add a route: ip route add 10.0.0.0/24 via 172.16.100.1 (where 172.16.100.1 is the server endpoint seen by the client).
  • On the server, allow forwarding between the PPP interface and the internal network and lock down external forwarding. Example iptables rules:

# Allow VPN clients to access internal network
iptables -A FORWARD -i ppp+ -o eth1 -s 172.16.100.0/24 -d 10.0.0.0/24 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o ppp+ -s 10.0.0.0/24 -d 172.16.100.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Drop forwarding from VPN clients to the Internet (prevent full tunneling)
iptables -A FORWARD -i ppp+ -o eth0 -s 172.16.100.0/24 -j REJECT

Adjust interface names and policy to match your topology.

Windows client: enabling split‑DNS and DNS suffixes

On Windows clients, PPTP will typically accept the ms-dns values and set the VPN adapter DNS accordingly. To ensure queries for an internal domain go to the VPN DNS:

  • In the VPN adapter properties → IPv4 → Advanced → DNS, add the internal DNS server manually if ms‑dns fails.
  • Uncheck “Use default gateway on remote network” to enable split tunneling.
  • Add an internal DNS suffix or domain search list (Network Adapter → Advanced → DNS → Append these DNS suffixes) such as corp.local so shortnames are resolved against the internal DNS first.

Troubleshooting tips

  • Verify DNS received by client: on Windows use ipconfig /all and check the DNS server(s) for the VPN adapter.
  • Use nslookup host.corp.local and specify the VPN DNS server to see whether the internal server resolves correctly: nslookup host.corp.local 10.0.0.53.
  • Check pppd/pptpd logs at /var/log/syslog for PPP negotiation and ms‑dns pushes.
  • If clients do not accept ms‑dns, use the ip‑up script to programmatically modify /etc/resolv.conf or the Windows registry (Group Policy) to set the VPN adapter DNS.
  • Ensure firewall rules on internal DNS servers allow queries from the VPN subnet.

Security considerations

PPTP has well‑known security weaknesses (MPPE is better than plain PPTP but still outdated). If your environment requires high security, prefer modern VPN technologies (OpenVPN, WireGuard, or IPsec/IKEv2) and implement split‑DNS using secure tunnels or DNS over TLS for client‑side DNS privacy.

Other best practices:

  • Limit which subnets are reachable by VPN clients via firewall rules.
  • Use strong authentication (certificate‑based or strong secrets) and monitor VPN logins.
  • Keep DNS servers and VPN servers updated and minimize services exposed on the public IP.

Example end‑to‑end checklist

  • Enable IP forwarding on the VPN server.
  • Install and configure pptpd with localip and remoteip.
  • Push internal DNS via ms-dns or ip‑up scripts.
  • Run dnsmasq or Bind9 for conditional forwarding of internal zones.
  • Configure iptables to allow VPN internal traffic but prevent unrestricted Internet tunneling.
  • On clients, configure split tunneling and ensure the VPN adapter’s DNS and search suffix are set.
  • Test DNS resolution and connectivity to internal services, and review logs for issues.

Implementing split‑DNS with PPTP provides a practical way to combine convenience and targeted internal access. While PPTP is straightforward to set up and supported by many legacy clients, evaluate its security limitations for your use case and consider modern VPN alternatives for long‑term deployments. For more setup examples and curated configuration snippets, visit Dedicated‑IP‑VPN at https://dedicated-ip-vpn.com/.