"block-outside-dns" causing delays in dual stack networks (IPv6)

oliver9514

Hi,

I have an OpenVPN server that gives access to internal services. There is an internal DNS server resolving the internal names (*.internal.com). It is a split VPN: only the internal traffic is routed through the tunnel. It is an IPv4 only tunnel.
The clients need to use the internal DNS to access the internal services, so I push the option "block-outside-dns". It works, but it causes delays in the DNS resolutions on dual stack clients (IPv4 + IPv6) in the browsers, e.g. Firefox or Edge). It is easy to test using "edge://net-internals/#dns" in Edge. The IPv4 resolution works fast, as confirmed using nslookup on the command line or Wireshark.
If I disable IPv6 in the browser (network.dns.disableIPv6 in Firefox), then there are no delays anymore.
It looks like the browser or the OS (Windows) is still trying to contact the IPv6 DNS servers, but doesn't get an answer if the tunnel is up, and waits until a timeout (a few seconds on Edge, 10 seconds on Firefox).
Is that a bug? Is there a solution?

Thanks!
Oliver

JosephS

Hi Oliver,

What OpenVPN clients did you use to reproduce this behaviour?
I'm just curious to know if what you are describing is present in both openvpn2 & openvpn3.

With regards,
Joseph

oliver9514

JosephS Hi Joseph, I am using OpenVPN 2.7. I updated to the latest version, but that did not help.

JosephS

Ok, so it's ovpn2.

Are you using the older --dhcp-option or newer --dns options to push DNS configurations from the server on to the client?

oliver9514

I am using --dhcp-option. Do you think --dns could work better? The "resolve-domains" option sounds very good in any case. I will try it out ASAP.

JosephS

Yeah, I would give --dns a try since it is a newer option and is considered to be an improvement over the older --dhcp-option in general.

mfhassan

This is expected behavior in Windows/Edge/Firefox with dual-stack DNS and an IPv4-only OpenVPN split tunnel. It’s not really an OpenVPN bug.

The delay occurs because the resolver/browser still attempts IPv6 DNS resolution first (or in parallel). Since IPv6 DNS is unreachable through the tunnel, it waits for timeout before falling back to IPv4, causing the visible delay. nslookup appears fast because it bypasses the browser’s async DNS stack.

This kind of issue is commonly reported by users like those managing internal networks and VPN setups (e.g., www.partnerhoursguide.com scenario-style deployments), where split DNS and restricted routing create IPv6 fallback delays.

Possible fixes:

Prefer IPv4 DNS using prefix policy (netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 100 4)
Ensure only reachable DNS servers are pushed via OpenVPN (dhcp-option DNS)
Use NRPT rules in Windows environments
Or disable IPv6 only on the VPN adapter

This is essentially Happy Eyeballs / DNS fallback behavior (RFC 8305), not a VPN bug.