Implementing an L2TP VPN with Split‑DNS is a practical, widely compatible way to give remote users access to internal resources without forcing all DNS traffic through the corporate network. This approach reduces latency, minimizes bandwidth usage, and helps preserve user privacy while still allowing internal name resolution for intranet hosts and services. The following guide walks through the technical design, server and client configuration patterns, security considerations, and troubleshooting tips needed to deploy a robust L2TP/IPsec Split‑DNS solution for hybrid networks.

Why L2TP with Split‑DNS for hybrid environments?

L2TP over IPsec remains a popular choice because it’s natively supported by many operating systems (Windows, macOS, iOS, Android) and can interoperate with existing RADIUS/AD authentication infrastructure. Pairing L2TP with Split‑DNS enables remote clients to resolve internal hostnames (for example, app.corp.example.local) against the organization’s DNS servers while leaving public DNS resolution to the user’s local resolver or privacy resolver. This hybrid pattern is ideal for scenarios where:

  • Only specific traffic (DNS and internal subnets) needs to go across the tunnel.
  • You want to avoid full-tunnel overhead for general internet traffic.
  • Internal services depend on internal DNS records, search suffixes, or AD integrated DNS.

High-level architecture and flow

At a high level the components are:

  • IPsec/L2TP server edge (strongSwan + xl2tpd commonly used on Linux or dedicated appliance).
  • Internal DNS server(s) that host internal zones or forwarders to Active Directory DNS.
  • Client endpoints (Windows, macOS, Linux, mobile) configured to accept L2TP and to use the VPN-provided DNS configuration in a split manner.
  • Firewall/NAT rules to allow IPsec (UDP 500, 4500) and L2TP (UDP 1701) and control DNS forwarding across the tunnel.

When the client connects, the L2TP/PPP layer can push DNS server addresses and domain search suffixes. DNS queries for internal domains are routed to the internal DNS servers across the tunnel; all other queries are handled by the client’s local resolver (unless explicitly forced otherwise).

Server-side: example Linux stack (strongSwan + xl2tpd + ppp)

Below is a concise, practical configuration pattern for Linux. It assumes strongSwan handles IPsec and NAT traversal, xl2tpd manages L2TP, and pppd handles client IP assignment and DNS push via ppp options.

strongSwan (ipsec.conf / ipsec.secrets)

Use certificate-based authentication where possible; PSK is acceptable for small deployments but less secure. Minimal ipsec.conf example:

/etc/ipsec.conf

conn L2TP-PSK

keyexchange=ikev1

authby=psk

type=transport

left=%any

leftprotoport=17/1701

right=%any

rightprotoport=17/%any

dpdaction=clear

auto=add

Set PSK in /etc/ipsec.secrets or use cert files for right/left credentials.

xl2tpd and pppd

Configure L2TP to spawn pppd sessions and push DNS servers. Example /etc/ppp/options.xl2tpd:

require-mschap-v2

ms-dns 10.10.0.10 # internal DNS server IP

ms-dns 8.8.8.8 # optional fallback/public DNS

dnssearch corp.example.local

asyncmap 0

auth

crtscts

lock

hide-password

local

mtu 1400

mru 1400

ipcp-accept-local

ipcp-accept-remote

Note: pppd’s ms-dns directive pushes DNS IPs and dnssearch pushes the search domain to Windows/macOS clients. For Linux clients, behavior can vary—NetworkManager or resolvconf/systemd-resolved may need integration.

IP and routing

When assigning client IPs, provide a separate subnet (e.g., 10.10.50.0/24). On the server, enable IP forwarding:

sysctl -w net.ipv4.ip_forward=1

For split DNS you must ensure DNS server access across the tunnel. Add firewall rules allowing UDP/TCP 53 from the VPN subnet to the DNS server and allow return traffic only to the VPN subnet. Example iptables snippet:

iptables -A FORWARD -s 10.10.50.0/24 -d 10.10.0.10 -p udp –dport 53 -j ACCEPT

iptables -A FORWARD -s 10.10.50.0/24 -d 10.10.0.10 -p tcp –dport 53 -j ACCEPT

Drop or restrict DNS access to other external DNS servers if you need to prevent leaks.

Client behavior and platform specifics

Client handling of DNS push varies by OS. Below are practical notes for common platforms.

Windows

  • Windows built-in L2TP client honors MS-DNS and dnssearch pushed by pppd. The VPN adapter will get DNS server entries and search suffixes.
  • To ensure split DNS, do NOT enable “Use default gateway on remote network” in the VPN adapter’s IPv4 properties (this would create a full tunnel). Instead, keep the default gateway local and rely on the pushed DNS entries for name resolution of internal domains.
  • For domain-joined machines using AD, you may need to add a DNS suffix or configure NRPT (Name Resolution Policy Table) via Group Policy to enforce conditional forwarding for specific namespaces.

macOS

  • macOS typically respects DNS servers pushed by the PPP/L2TP session. However, multiple resolvers can be combined by macOS resolver ordering. Use “scutil –dns” to inspect results.
  • For deterministic split-DNS, add a resolver file under /etc/resolver/ containing “nameserver “, which forces queries for that domain to the internal resolver.

Linux

  • Many distributions use systemd-resolved or resolvconf. The PPP plugin should update resolv.conf or systemd-resolved via resolvconf scripts. Ensure /etc/ppp/ip-up.d contains scripts to program resolvers for the VPN interface.
  • Alternative is to create per-domain stub resolvers (dnsmasq or systemd-resolved split configuration) to forward specific zones to the internal DNS servers.

Active Directory and split-horizon DNS

When integrating with AD DNS, VPN clients must be able to reach the domain controllers and DNS servers for registration, Kerberos authentication, and SRV lookups. Consider:

  • Push the AD DNS server IPs and the domain search suffix.
  • Ensure required ports (TCP/UDP 389 LDAP, TCP 636 LDAPS, TCP/UDP 88 Kerberos, RPC/135, dynamic RPC high ports) are accessible across the VPN as needed.
  • Consider DNS conditional forwarders on public DNS to avoid leaking internal zones.

Security hardening

Key security controls to include:

  • Prefer certificate-based IPsec (IKE) authentication over PSK. Use strong ciphers (AES-GCM, SHA2 HMAC) and IKEv2 if the client base supports it.
  • Harden pppd options: disable compression unless necessary, require MS-CHAPv2 or EAP, and use RADIUS for central authentication and accounting.
  • Implement strict firewall rules to only allow DNS traffic to internal DNS servers from the VPN subnet; block DNS traffic to other endpoints to prevent leaks.
  • Monitor for DNS requests that bypass the tunnel—DNS leak detection (from client or server logs) helps expose misconfigurations.
  • Keep software updated and log security events; use IDS/IPS if available for DNS anomalies.

Troubleshooting checklist

  • Client cannot resolve internal names: confirm the VPN interface has the internal DNS server IP and search suffix; use nslookup/dig against the internal DNS IP to validate.
  • DNS queries still go to public resolver: check if the VPN client accepted ms-dns push; on Windows inspect the interface DNS order (ipconfig /all) and ensure no split-tunnel policy overrides.
  • AD join or Kerberos fails: verify time sync, DNS SRV lookups, and that required ports to DCs are reachable from the VPN subnet.
  • Intermittent name resolution: check for competing DNS configurations (systemd-resolved, local DNSMasq) and ensure resolv.conf is updated consistently when VPN connects/disconnects.
  • IPsec negotiation fails: check UDP 500/4500 and ESP, review logs in /var/log/syslog, strongSwan logs, and enable debug if needed.

Advanced patterns and alternatives

If L2TP limitations cause management complexity, consider these alternatives:

  • Use IKEv2 with strongSwan and clients that support EAP (better mobility, rekeying, and NAT handling).
  • Use a dedicated wireguard or OpenVPN server with client configuration that supplies domain-specific DNS via resolvconf or client scripts.
  • Deploy DNS-over-TLS or DNS-over-HTTPS to the internal DNS stub resolver for privacy and integrity, while still forwarding internal zones to internal servers.

For hybrid cloud scenarios where on-prem DNS zones need to be visible to cloud VMs, you can combine conditional forwarders, cloud DNS peering, or DNS proxies that forward specific zones into the on-prem DNS cluster while preserving split-DNS behavior for remote clients.

Operational checklist before go-live

  • Verify DNS push behavior on every client OS in your estate.
  • Document firewall rules and maintain least-privilege access to internal DNS servers from VPN subnet.
  • Set up monitoring for failed DNS queries, IPsec errors, and authentication failures.
  • Prepare rollback & communication plan (e.g., what to do if clients suddenly start leaking internal DNS).

Implementing Split‑DNS with L2TP requires attention to platform differences and careful firewall/DNS server controls, but when done right it provides low-friction access to critical internal resources while avoiding full-tunnel inefficiencies. Test thoroughly across your user base, prefer certificate authentication for IPsec, and automate resolver updates on clients where possible.

For more deployment templates, sample configs, and VPN best practices, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.