OpenVPN DNS leak fix for Windows and Linux

The OpenVPN DNS leak fix that works is not one setting, because the leak is not one failure. OpenVPN pushes a resolver to your client, and your operating system is free to ignore it. Windows ignores it one way and systemd-resolved ignores it another, so the same profile can leak on one machine and behave on the next. Everything below is specific to OpenVPN. For what a DNS leak is and why it matters, read DNS leak protection first.

The symptom is precise and the person reporting it usually describes it better than any vendor page. From Arch Linux BBS thread 275478, titled "Openvpn dns leakeage", reproduced with the original spelling:

"Unfortunatelly after all, I accessed https://dnsleaktest.com to test if I'm connect to internet through vpn and if I'm facing any DNS leakeage. In fact, I'm succesfully connected through VPN, but unsuccesfully having DNS leakeage issues. When I run the test, the hostname and ISP listed are still from the untrusted network."

Note what is and is not broken there. The tunnel is up, tun0 exists, routes are installed and traffic is flowing. Only name resolution is going somewhere else. That distinction is the whole diagnosis, because it rules out every routing fix immediately.

OpenVPN does not resolve names. It hands your client a resolver address through dhcp-option DNS 10.8.0.1 and expects the operating system to apply it. On Windows the client can write that address onto the tunnel adapter directly. On Linux and macOS the directive is inert data until an up script acts on it, so a profile that leaks on Ubuntu may work untouched on Windows.

Three configuration states make it worse, and they are worth checking before any fix.

route-nopull is in the profile. This directive accepts pushed options except routes and DHCP options, and DNS arrives as a DHCP option. Setting it therefore discards the pushed resolver along with the pushed routes, which is a side effect people rarely intend. If you only wanted to keep your own default gateway, use pull-filter ignore "redirect-gateway" and leave the DNS push alone.

No up script is configured. The dhcp-option DNS line is present, the client logs it, and nothing on the system ever reads it.

The resolver is unreachable through the tunnel. The address applies correctly and every query times out, which presents as no internet rather than as a leak.

block-outside-dns and what it does

block-outside-dns installs Windows Filtering Platform rules that block DNS to any resolver other than the ones on the VPN adapter. It is one line in the profile:

block-outside-dns

Two properties matter. It is Windows-only, and every other platform either refuses it or logs that it ignored it. It blocks rather than redirects, so it needs a working resolver on the tunnel adapter beside it or you will have no resolution at all rather than leaked resolution.

PulseVPN profiles do not carry this line. No .ovpn file PulseVPN issues contains block-outside-dns, so on Windows you add it yourself. Open the profile in a text editor, put the directive on its own line, save, and re-import. Nothing else in the file needs touching.

Then confirm the resolver before you rely on the block. Connect, run ipconfig /all, and read the DNS servers listed against the OpenVPN adapter. An address there means the directive has something to allow. An empty list there means you have blocked every resolver and left none, which presents as no internet rather than as a leak.

For clients too old to implement the directive there is a separate route. The ValdikSS/openvpn-fix-dns-leak-plugin repository ships a plugin DLL loaded from the config, and it ranks near the top of this query precisely because it was the only answer for years. Prefer the directive on any current client and treat the plugin as a fallback for a client you cannot upgrade.

When the client reports it as an unrecognized option

A client that does not implement the directive refuses the profile and names it. Keenetic's support article documents the string exactly:

Unrecognised option or missing or extra parameter(s) in configuration: (line 6): block-outside-dns (2.4.6)

That message means your client is not Windows OpenVPN, or is a build that predates the directive. Router firmware, NAS packages and some mobile clients all produce it. Do not treat it as a bug in the profile.

Two documented fixes exist, both from Keenetic's own article. Comment the line out with a leading #. Or leave it and add pull-filter ignore 'block-outside-dns' so a server-pushed copy is discarded rather than fatal. Choose the second on a client that connects to several servers, because it survives the server changing its push list.

A warning is a different case from a refusal. Viscosity reports Warning: The block-outside-dns option has been ignored and states that its own DNS handling makes the directive unnecessary. A client that names the option and continues has read it and declined it deliberately, so use that client's DNS setting instead of fighting the log line.

When block-outside-dns is set and the leak continues

The directive is set, the client is current, and the test still returns your ISP. Work through these in order.

Confirm the adapter actually received a resolver. Run ipconfig /all and read the DNS servers listed against the OpenVPN adapter, not against the physical NIC. An empty list there means the push never arrived or was filtered.

Check for route-nopull in the profile, since it discards the DNS push as described above.

Check whether the browser is resolving on its own. DNS over HTTPS in the browser bypasses the operating system resolver entirely, so Windows Filtering Platform rules never see the query. Disable it in the browser and retest before concluding the tunnel is at fault.

Check for a second resolver source. A router-supplied resolver, a security suite with its own DNS proxy, or a manually pinned resolver on the physical adapter can all answer first.

For the directive reference and the other flags named on this page, see block-outside-dns and other OpenVPN flags.

systemd-resolved and per-link resolvers

systemd-resolved keeps a DNS configuration per network link and decides per query which link to ask. The default behaviour is the leak. The update-systemd-resolved project states it directly: "By default, systemd-resolved will send all DNS queries to at least one DNS server on every link configured with DNS servers." The first valid reply wins.

Read that twice. Applying the VPN resolver to tun0 does not stop systemd-resolved asking your Ethernet link as well. The tunnel resolver and the ISP resolver race, and your ISP frequently wins because it is closer. This is filed upstream as systemd/systemd issue 7182, "systemd-resolved causes dns leaks when connected via vpn", which is worth knowing because it means you are not misconfigured.

The fix is to make the tunnel link authoritative for the entire namespace rather than merely present in it. That is what a routing domain of . does.

update-resolv-conf and the up and down scripts

Two helper scripts are in common use, and they solve different generations of the problem.

update-resolv-conf rewrites /etc/resolv.conf from the pushed options. It historically shipped with the openvpn package on Debian and Ubuntu at /etc/openvpn/update-resolv-conf. On a system where systemd-resolved owns /etc/resolv.conf through a symlink, rewriting that file is the wrong layer and can appear to work while queries still race. Check whether your own installation still carries the script before you point a profile at it.

update-systemd-resolved talks to systemd-resolved over DBus instead, which is the correct layer on any system using it. Its README gives the invocation as:

--script-security 2
--up /usr/local/libexec/openvpn/update-systemd-resolved --up-restart
--down /usr/local/libexec/openvpn/update-systemd-resolved --down-pre

The path depends on how the script was installed, so check yours before copying that. A path that does not exist produces a script failure rather than a DNS failure, which sends you looking in the wrong place.

Add the routing domain to close the race. The README describes the effect precisely: "A DOMAIN-ROUTE option for . (single period) will instruct systemd-resolved to route the entire DNS name-space through to the DNS servers configured for this connection." In the profile that is one line:

dhcp-option DOMAIN-ROUTE .

Set script-security 2 deliberately and understand what it permits. It allows OpenVPN to execute user-defined scripts, which is what makes the up and down hooks work at all. Only point those hooks at scripts you control, because a script path in a profile you downloaded runs with the privileges OpenVPN holds.

Confirming with resolvectl

Do not confirm a Linux DNS fix in a browser. Confirm it at the resolver.

Run resolvectl status and read the per-link blocks. The tun0 link should list the VPN resolver, and your physical link should either list nothing or be excluded by the routing domain.

Run resolvectl query example.com and read which link answered. That output names the interface, which is the single most direct evidence available on Linux.

Run resolvectl status tun0 alone when the full output is long. A routing domain of ~. on that link is what tells you the namespace redirect took effect.

Retest after a reconnect, not only after the first connect. A down script that fails leaves stale per-link configuration behind, and the next session inherits it.

A browser leak test observes what your browser resolved. It does not observe what your system would resolve, and it cannot see a query that never left. Treat it as one signal among four.

The last row is the only conclusive one, and it is the method rather than the remedy. For how to run it and how to test the reconnect window where most real leaks occur, see how to test a VPN kill switch.

A kill switch blocks traffic when the tunnel goes down. A DNS leak happens while the tunnel is up. Those are different failures with different remedies. A firewall rule that permits outbound traffic on tun0 will happily permit a query already routed onto tun0 toward the wrong resolver.

The overlap is real but narrow. A kill switch that blocks port 53 on every interface except the tunnel does prevent the racing-resolver case on Linux. It also stops an application pinned to a hardcoded resolver from reaching it. It does nothing about DNS over HTTPS in a browser, because that traffic is port 443 and indistinguishable from the rest of it.

Build the kill switch for the disconnect case and fix DNS at the resolver. See kill switch setup for the first half.

For the general resolver picture across protocols, see DNS leak protection. For the profile itself, see using your OpenVPN profile. For failures where the tunnel is the problem rather than the resolver, see connection troubleshooting.