You set up OpenVPN, your IP address shows the VPN server's location, and you assume you're invisible. Then you run a DNS leak test and see your ISP's resolver staring back at you. That single gap hands your browsing history to your ISP, your government, or anyone monitoring the network, completely bypassing the tunnel you just paid for. DNS leaks in OpenVPN are one of the most common and most under-diagnosed privacy failures in consumer and enterprise VPN setups alike, and the fix requires more than just clicking a "DNS leak protection" toggle in a GUI client.

What a DNS Leak Actually Is

When you type a domain name into your browser, your operating system sends a DNS query to a resolver before the HTTPS connection ever opens. In a properly configured VPN, that query should travel encrypted inside the tunnel to a DNS server the VPN operator controls. A DNS leak occurs when that query exits outside the tunnel, reaching your ISP's or your router's DNS server instead. Your VPN traffic is encrypted, but your DNS traffic is not, and it reveals every hostname you look up in plain text.

This is distinct from a WebRTC leak (which exposes your local IP) and an IPv6 leak (which bypasses the tunnel entirely). DNS leaks are subtler because the connection still appears to work fine, your geo-spoofed IP is shown on most leak tests, but a proper DNS check unmasks you immediately.

Why DNS Leaks Happen in OpenVPN

OpenVPN is a layer-3 tunnel. It does not automatically take ownership of your system's DNS configuration unless you explicitly tell it to. Several conditions cause queries to escape:

  • No push-dns directive: If the server config does not push a DNS address to the client, the client keeps using whatever resolver it had before connecting, typically the one handed out by DHCP from your router.
  • Windows Smart Multi-Homed Name Resolution: Windows 8 and later send DNS queries to all available interfaces simultaneously and use whichever responds fastest. This is the single biggest cause of DNS leaks on Windows.
  • Split tunneling without DNS routing: When only a subset of routes are pushed through the tunnel, the default DNS resolver may sit on an excluded route, so queries go around the tunnel.
  • IPv6 DNS not blocked: If OpenVPN tunnels only IPv4 and your network has IPv6 connectivity, the OS may send AAAA queries over the native IPv6 path.
  • systemd-resolved or resolvconf conflicts: On Linux, these services may not hand DNS control to OpenVPN's scripts, leaving the pre-VPN resolver active.

How to Detect a DNS Leak Right Now

Before making any changes, confirm you have a leak. Connect to your OpenVPN server, then run the following from a terminal:

nslookup whoami.akamai.net nslookup myip.opendns.com resolver1.opendns.com

If the IP returned belongs to your ISP rather than your VPN provider's ASN, you have a leak. On the command line you can also run:

# Linux / macOS cat /etc/resolv.conf # Windows (PowerShell) Get-DnsClientServerAddress | Select-Object InterfaceAlias, ServerAddresses

Check whether the listed nameservers are ones you configured for the VPN or whether they still point to your router (192.168.x.x) or your ISP. You can also cross-reference by using the DNS Lookup tool while connected to the VPN and comparing the authoritative resolver that answered your query.

Fix 1: Push DNS in the OpenVPN Server Config

The most fundamental fix is ensuring your OpenVPN server tells clients which DNS server to use. Open your server configuration file (commonly /etc/openvpn/server.conf) and add:

push "dhcp-option DNS 10.8.0.1" push "dhcp-option DNS 9.9.9.9"

Replace 10.8.0.1 with your VPN server's internal DNS if you run one, or use a trusted public resolver like Quad9 (9.9.9.9) or Cloudflare (1.1.1.1). Restart the OpenVPN service:

# Linux systemd sudo systemctl restart openvpn@server # Or if using a named config sudo systemctl restart openvpn

On the client side, if you manage your own .ovpn profile, verify those pushed directives are being applied by running ipconfig /all on Windows or cat /etc/resolv.conf on Linux immediately after connecting.

Fix 2: Add block-outside-dns to the Client Config (Windows)

Windows's Smart Multi-Homed Name Resolution is the root cause of most Windows DNS leaks. OpenVPN 2.3.9 and later include a built-in firewall-based fix. Add this single line to your client .ovpn file:

block-outside-dns

This directive installs a temporary Windows Firewall rule at connection time that blocks all DNS traffic on all adapters except the TAP/TUN interface. It is removed when the VPN disconnects. This is the correct and complete fix for Windows and eliminates Smart Multi-Homed resolution without requiring registry edits.

If you are using the OpenVPN GUI on Windows, ensure you are running version 2.4 or later. Earlier versions do not ship the wfp.dll needed for this feature. Check with:

openvpn --version

Fix 3: Prevent DNS Leaks on Linux with systemd-resolved

Modern Ubuntu, Fedora, and Debian systems use systemd-resolved. OpenVPN's default up and down scripts do not always update the resolved configuration correctly, leaving the pre-VPN stub resolver (127.0.0.53) in charge.

The most reliable approach is to use the update-systemd-resolved script. Install it:

sudo apt install openvpn-systemd-resolved # Debian/Ubuntu # or install from: https://github.com/jonathanio/update-systemd-resolved

Then add these lines to your client .ovpn file:

script-security 2 up /etc/openvpn/update-systemd-resolved down /etc/openvpn/update-systemd-resolved down-pre

After connecting, verify the DNS server changed:

systemd-resolve --status | grep -A 5 "DNS Servers"

The output should show your VPN-pushed DNS address, not your router's IP.

Fix 4: Block IPv6 DNS to Prevent IPv6 Leaks

If OpenVPN does not tunnel IPv6 but your network is dual-stack, the operating system will send AAAA queries over native IPv6, bypassing the VPN entirely. The clean fix is to push a route that kills IPv6 outside the tunnel, or to disable IPv6 on the physical adapter while the VPN is active.

Add this to your server config to route IPv6 through the tunnel (requires tun-ipv6 and a configured IPv6 pool), or alternatively block all IPv6 on the client:

# In client .ovpn to kill native IPv6: route-ipv6 ::/0 ::1 net_gateway pull-filter ignore "route-ipv6"

On Linux, a faster approach is to disable IPv6 on the physical interface temporarily:

sudo sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 # Replace eth0 with your actual interface name (ip link show)

On Windows, disable IPv6 on the physical NIC via Device Manager or:

# PowerShell (run as Administrator) Disable-NetAdapterBinding -Name "Ethernet" -ComponentID ms_tcpip6

Fix 5: Redirect All Traffic Through the Tunnel

Split tunneling is convenient but it's also the architectural source of leaks when your DNS server lives on an excluded route. The safest configuration redirects the entire default route through the VPN. Add to your server config:

push "redirect-gateway def1 bypass-dhcp"

The def1 flag adds two /1 routes (0.0.0.0/1 and 128.0.0.0/1) which supersede the default gateway without replacing it, so DHCP and local network traffic still work. Combined with a pushed DNS directive, this is the gold-standard no-leak configuration.

Verifying the Fix End-to-End

After applying changes, reconnect the VPN and perform a structured verification:

  1. Check your public IP has changed to the VPN server's IP using any IP lookup service.
  2. Check which DNS resolvers are answering your queries. On Windows: ipconfig /all. On Linux: resolvectl status or cat /etc/resolv.conf.
  3. Run a DNS query for a known domain and confirm the answering server belongs to your VPN provider's or your chosen resolver's ASN, not your ISP.
  4. Check for IPv6 leaks by visiting an IPv6-specific test endpoint or running curl -6 ifconfig.me. If it returns an address, your IPv6 is not tunneled.
💡 After applying your DNS leak fixes, use the DNS Propagation Checker to query your domain from multiple global vantage points and confirm the resolvers responding are the ones you intended, not your ISP's infrastructure.

Router-Level DNS Leak Prevention

If you run OpenVPN on a router (DD-WRT, OpenWrt, Tomato, Asus Merlin), the DNS leak risk is different. Your router is the resolver for every device on the LAN, so if the router's WAN-facing DNS query exits outside the tunnel, every device leaks simultaneously.

Access your router admin panel:

  • Asus (Merlin): http://asusrouter.com or 192.168.1.1
  • Netgear: http://routerlogin.net or 192.168.1.1
  • TP-Link: http://tplinkwifi.net or 192.168.0.1
  • D-Link / generic: 192.168.0.1

On Asus Merlin routers with the built-in VPN client, navigate to VPN > VPN Client > your profile > Advanced Settings and set Accept DNS Configuration to Exclusive. This forces all LAN DNS through the VPN tunnel and blocks the WAN DNS. On DD-WRT, set the NVRAM variable vpn_client_dns and ensure dnsmasq forwards to the VPN-pushed DNS address only.

Preventing DNS Leaks on macOS

macOS handles DNS per-interface and does not have a single global resolver file like Linux. OpenVPN's pushed DNS may apply only to the tun interface and macOS may still query the en0 (Wi-Fi) resolver for background traffic. The fix is to use the Tunnelblick client (which has a built-in DNS leak prevention mode) or to use a custom up script that overwrites the global DNS via networksetup:

# Example up script fragment networksetup -setdnsservers Wi-Fi 10.8.0.1 networksetup -setdnsservers "USB 10/100/1000 LAN" 10.8.0.1

Tunnelblick users should enable Use DNS and WINS from server in the connection settings and set the configuration to route all traffic through the VPN. The Tunnelblick documentation refers to this as "Set nameserver (3.1)", which uses a macOS-compatible DNS override script maintained by the Tunnelblick project.

Ongoing DNS Leak Monitoring

A one-time fix is not enough. ISP DHCP renewals, network switches (moving from Wi-Fi to Ethernet), and OS updates can silently reintroduce leaks. Build leak checking into your workflow:

  • Run a command-line DNS leak check every time you connect to a new network.
  • On Linux, write a small shell script that verifies resolv.conf points to your VPN DNS before opening a browser.
  • On Windows, use the OpenVPN GUI's event log to confirm block-outside-dns is applied at each connection.
  • Consider a kill-switch firewall rule that drops all traffic if the VPN interface goes down, preventing fallback to the unprotected DNS path.

DNS leaks are fixable, but they require deliberate configuration at every layer: the server pushing the correct resolver, the client enforcing exclusive use of that resolver, IPv6 fully blocked or tunneled, and the OS cooperating rather than routing queries around your tunnel. The five fixes above, applied together, close every common leak vector in a standard OpenVPN deployment.