Why DNS Stops Working After OpenVPN Connects on Windows

The resolver still answers a ping while port 53 goes nowhere. Check whether block-outside-dns is filtering, then supply a resolver the tunnel can reach.

A ping to the office resolver still answers after OpenVPN connects, and every name lookup fails anyway. The address is reachable while the port is not, a combination that makes sense once you know Windows can filter DNS by adapter. With block-outside-dns in the profile, that filter is the first suspect and the route table is the wrong place to look. The two tests below separate the layers in seconds.

Reachable address, dead port

A successful ping proves the host is up and a path exists. It says nothing about permission to reach port 53, because the filter at issue works at a different layer and keys on the adapter. That is why the same machine can answer ICMP and refuse every query sent to the same address. Run both tests in the same session before changing any configuration.

ping <resolver-ip>
nslookup <name> <resolver-ip>

The pair is the diagnosis. Ordinary traffic to the subnet keeps working while name resolution dies, and people conclude the server is broken or that DNS was never pushed. Both explanations are expensive to chase, and the evidence points somewhere narrower. Confirm the pair before touching a setting.

The option is a filtering platform rule

The OpenVPN reference describes block-outside-dns as a Windows Filtering Platform restriction that stops applications reaching DNS on adapters outside the tunnel. It covers TCP and UDP port 53. Because the filter lives in WFP rather than in the ordinary firewall rule list, adding an allow rule elsewhere does not necessarily change the outcome. That is why the common advice to permit DNS keeps failing.

The setting can arrive from the imported profile or from the server, and the file you last edited is not proof of what the client loaded. Read the effective configuration and the connection log together. The option is also Windows-specific, and treating it as portable produces advice that does not apply.

Look for the client component that owns the restriction instead of adding more rules. The owner is the thing that can actually remove it.

A filter is not a resolver

Blocking traffic outside the tunnel does not install a working resolver inside it. The option removes a path and leaves the tunnel's DNS configuration to whoever set up the profile. A profile that never pushed a resolver now has none at all.

Work through three checks in order. First, which resolver the failing application actually uses. Second, whether the client applied the VPN DNS settings. Third, which interface carries traffic to that resolver.

  1. Resolver in use: compare Resolve-DnsName -Server <resolver-ip> <name> with the DNS servers listed by ipconfig /all.
  2. VPN DNS applied: inspect the tunnel adapter's DNS entries in the same ipconfig /all output.
  3. Interface used: Find-NetRoute -RemoteIPAddress <resolver-ip> names the outgoing interface for that destination.

A LAN resolver becomes unreachable by design under this policy even while other LAN traffic works. That is the option doing its job. If the design needs VPN DNS, fix the resolver registration and the tunnel path; if split DNS with local exceptions is required, the configuration owner has to express those exceptions in a supported way.

What the option does not cover

Port 53 is not the whole of name resolution. DNS over HTTPS and DNS over TLS use different transports, and some applications run their own resolver logic regardless of system settings. A browser can therefore resolve names while the command line cannot.

Treat that difference as a diagnostic rather than a contradiction. Compare the two before deciding the system resolver is broken.

Keep the conclusion narrow when you write it up. This option constrains one transport on one platform, and the rest of the resolution path is a separate design question with its own owner.

Check the state before and after disconnect

Run the same lookup during the connection and again after the owning client disconnects. The first should fail for an outside resolver while the tunnel is up, and the second should succeed once the filter is removed. If it still fails after disconnect, the filter was not cleaned up.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Restarting the client service or the machine usually clears a stale filter. That confirms the diagnosis without proving a permanent fix. Record what you saw, because a filter that survives a disconnect will do it again, and the record is what justifies a bug report.

Only after those checks does replacing the resolver or rebuilding the firewall policy make sense. Both are larger changes than the evidence supports.

Related articles