Domain Name System (DNS) leaks are a common privacy and operational risk when using L2TP/IPsec VPNs. Even if your packets are tunneled, a misconfigured client or server can still resolve hostnames using the user’s local ISP DNS servers — exposing browsing patterns and potentially bypassing geofencing or corporate controls. This guide provides a practical, step-by-step approach to diagnose and eliminate DNS leaks in L2TP deployments, with specific configuration examples and commands for server and client platforms.

Why DNS leaks occur with L2TP/IPsec

Before diving into fixes, it’s important to understand common root causes:

  • Client resolver behavior: Operating systems often retain a list of legacy resolvers (from DHCP, Wi‑Fi, or system configuration) and may continue to query them even when a VPN is active.
  • Split tunneling / routing issues: If the VPN isn’t configured to route all traffic (for example, default gateway not pushed), DNS may be routed outside the tunnel.
  • resolv.conf or systemd-resolved conflicts: On Linux, different resolver services can overwrite DNS settings when interfaces change.
  • IPv6 leakage: L2TP/IPsec sessions are often IPv4-only; IPv6 requests can go out via the native interface.
  • Firewall/NAT rules: Unprotected UDP/TCP 53 from the client can be allowed out to the ISP DNS.

High-level remediation plan

The approach we recommend follows four phases:

  • Detect: Reproduce and capture DNS queries to confirm leakage.
  • Push / enforce: Configure the VPN server to provide DNS and enforce routing of DNS traffic through the tunnel.
  • Lockdown client: Harden client OS resolver behavior and disable non-VPN DNS paths (including IPv6).
  • Firewall & verify: Use firewall rules to block or redirect external DNS and then test again.

Phase 1 — Detect and reproduce the leak

Start by confirming a leak with active monitoring.

TCPDump and packet captures

On the client or a monitoring device, run tcpdump to observe DNS flows:

sudo tcpdump -n -i eth0 port 53 or port 5353

Replace eth0 with the local interface name (not the VPN interface) to watch for DNS queries leaving the native adapter. Look for UDP/53 or TCP/53 traffic destined to IPs that are not the VPN DNS server.

Online DNS leak tests

While less authoritative than captures, external services can show which resolvers see your queries. Use them only after capturing traffic locally for forensic evidence.

Phase 2 — Configure the L2TP/IPsec server to push DNS

Make the VPN server authoritative for client DNS settings so the client has a valid resolver inside the tunnel.

pppd options (xl2tpd and other L2TP servers)

Add MS-DNS entries to your PPP options (server-side) to push DNS to clients:

/etc/ppp/options.xl2tpd (sample entries):

ms-dns 10.8.0.1

Where 10.8.0.1 is a DNS server reachable via the VPN (often the gateway or a dedicated resolver on the VPN subnet).

strongSwan / Libreswan IPsec considerations

IPsec components don’t handle DNS push directly; they provide the IPsec tunnel. L2TP/pppd must supply DNS information. Ensure your IP pool and PPP options match and that the DNS server is routable over the pppX interface.

Provide an in‑tunnel DNS service

  • Run a local DNS resolver such as dnsmasq or unbound bound to the VPN interface address (e.g., 10.8.0.1).
  • Use conditional forwarding if you need corporate internal zones to be resolved differently.

Phase 3 — Client hardening (Windows, macOS, Linux)

Clients behave differently; follow these platform-specific steps to ensure DNS uses the tunnel resolver.

Windows (7/10/11 and Server)

  • In the VPN connection properties, go to Networking → IPv4 → Properties → Advanced and enable Use default gateway on remote network to force full tunnel routing.
  • Disable IPv6 on the adapter or at least unbind IPv6 DNS if you don’t provide IPv6 DNS over the VPN.
  • If Windows still uses local resolvers due to DNS caching behavior, set the VPN connection metric lower than local adapters’ metrics or use Group Policy to push DNS settings.
  • PowerShell capture: Get-DnsClientServerAddress -InterfaceAlias "VPN" to verify assigned servers.

macOS

  • Use scutil --dns to inspect resolver order. The VPN DNS should appear above local resolvers.
  • If it does not, set the service order in System Preferences → Network so the VPN service has precedence, or use networksetup -setdnsservers "VPN Name" 10.8.0.1.
  • Consider disabling “Set DNS servers automatically” for Wi‑Fi while connected to the VPN via a script.

Linux (NetworkManager / systemd-resolved)

  • For NetworkManager, edit the connection and set IPv4 → DNS → Ignore automatically to prevent DHCP DNS from overriding. Then set the VPN DNS manually.
  • If using systemd-resolved, you can bind the VPN DNS to the link: resolvectl dns ppp0 10.8.0.1.
  • Alternatively, set dns=none in NetworkManager and run dnsmasq/unbound locally bound to 127.0.0.1; forward VPN DNS via your resolver.
  • Be cautious: some distributions overwrite /etc/resolv.conf. Use chattr +i on /etc/resolv.conf if appropriate, but prefer systemd-resolved configuration to avoid side effects.

Phase 4 — Firewall-based enforcement on client and server

Even with correct DNS settings, extra safeguards are recommended: block or redirect non‑VPN DNS queries so leaks cannot occur.

Blocking external DNS at the client

Use local firewall rules to block or redirect UDP/TCP 53 to the VPN resolver. Example iptables rules to permit only DNS via ppp0 (replace ppp0 with your VPN interface):

sudo iptables -I OUTPUT ! -o ppp0 -p udp --dport 53 -j DROP
sudo iptables -I OUTPUT ! -o ppp0 -p tcp --dport 53 -j DROP

These rules drop DNS queries leaving through any non‑VPN interface. If you prefer redirection (DNAT) to a local resolver:

sudo iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 10.8.0.1:53

Server-side NAT and DNS firewall

On the VPN gateway, ensure that DNS from VPN clients is accepted only if destined to your resolver. Examples:

sudo iptables -A FORWARD -i ppp+ -p udp --dport 53 -d 10.8.0.1 -j ACCEPT
sudo iptables -A FORWARD -i ppp+ -p udp --dport 53 -j DROP

Also block outbound DNS from the gateway to external DNS servers for VPN client IP ranges if you want strict enforcement.

Policy routing to ensure DNS goes via the tunnel

If you have complex routing or multiple interfaces, enforce DNS traffic policy routing so queries from client IPs use the VPN routing table. Example:

On Linux client:

ip rule add from 10.8.0.20/32 table 200
ip route add default via 10.8.0.1 dev ppp0 table 200

This ensures traffic originating from the client’s VPN endpoint uses the VPN gateway.

IPv6: the often‑forgotten vector

Many L2TP setups do not carry IPv6, and OSes may prefer IPv6 DNS or send AAAA queries over the native network. Recommended actions:

  • Disable IPv6 on the client or at least prevent IPv6 DNS queries through native interfaces.
  • Block UDP/TCP 53 over IPv6 on the client: ip6tables rules analogous to the IPv4 rules above.
  • If you need IPv6, provide IPv6 addresses and DNS over the VPN and ensure proper routing.

Verification and continuous monitoring

After enforcement, retest with tcpdump. To validate, run:

sudo tcpdump -n -i any port 53

Ensure all captured DNS packets are addressed to your VPN DNS server or localhost resolver. Automate periodic checks and optionally log dropped DNS attempts to audit leaks:

sudo iptables -A OUTPUT ! -o ppp0 -p udp --dport 53 -j LOG --log-prefix "DNS_LEAK_DROP: "

Additional hardening and modern options

  • Use DNS-over-TLS or DNS-over-HTTPS for in-tunnel DNS to prevent on-path eavesdropping.
  • Consider using a split‑DNS server or conditional forwarders for internal names to avoid accidental exposure of internal queries to public resolvers.
  • Implement monitoring dashboards or SIEM alerts for repeated dropped DNS attempts that may indicate client misconfiguration or malware.

Quick checklist for production rollout

  • Configure server-side ms-dns options and run an in-tunnel resolver.
  • Ensure “Use default gateway on remote network” or equivalent full-tunnel routing is enforced where appropriate.
  • Harden the client resolver: NetworkManager/systemd-resolved or OS-native settings.
  • Apply firewall rules on the client to drop or redirect non-VPN DNS traffic, and on the server to accept only in-tunnel DNS.
  • Block IPv6 DNS leaks or provide IPv6 support in the VPN.
  • Capture and verify with tcpdump and schedule periodic tests.

DNS leaks are preventable with a combination of proper server configuration, client policy, and robust firewalling. The most reliable defense is to make the VPN server the authoritative resolver for clients and to block any outbound DNS that bypasses the tunnel. For complex environments, add policy routing and logging for visibility.

For related deployment guides, configuration snippets, and managed dedicated IP options, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.