[Windows] DNS resolution fails (ping fails, nslookup works) with DCO enabled on 2.7.2 using redirect-gateway (original) (raw)

Describe the bug

After updating the OpenVPN Windows client to version 2.7.2 (and 2.7.3), DNS resolution via the Windows DNS Client service breaks when connecting to a full-tunnel VPN (redirect-gateway).

Specifically, nslookup can successfully resolve internal and external hostnames (using the VPN's DNS server), but standard applications and the ping command fail to resolve external domain names (e.g., ping google.com returns "could not find host"). Pinging external IP addresses directly (e.g., ping 8.8.8.8) works fine.

When adding disable-dco to the client configuration or downgrading to version 2.6.20/2.7.1, the issue disappears completely and everything works as expected.

To Reproduce

Steps to reproduce the behavior:

1. Setup an OpenVPN Community Server pushing a DNS server and routing all traffic.
2. Install OpenVPN Windows Client 2.7.2.
3. Use a client config with redirect-gateway def1 (fullroute).
4. Connect to the VPN (DCO is enabled by default).
5. Open CMD and run:
   • nslookup google.com -> Works (resolves via VPN DNS).
   • ping 8.8.8.8 -> Works.
   • ping google.com -> Fails ("Ping request could not find host").
6. Browsers and other Windows apps cannot resolve any hostnames.

Expected behavior

Windows DNS Client should correctly route DNS requests through the DCO interface and resolve hostnames, just like it does when DCO is disabled (disable-dco) or in previous versions (2.7.1).

System Information

• OS: Windows 11
• OpenVPN Client Version: 2.7.2 (also tested 2.7.3)
• OpenVPN Server Version: 2.7.2

Troubleshooting already performed

• Disabling IPv6 on the DCO adapter -> did not help.
• Using block-outside-dns -> did not help.
• Running ipconfig /flushdns and register-dns -> did not help.
• Verified that the server is successfully pushing the correct DNS settings (push "dhcp-option DNS ...").
• Setting disable-dco resolves the issue immediately.

Additional Context

It looks like the Windows System DNS service UDP responses are either being dropped by the DCO driver/WFP filters, or the system metrics are incorrectly assigned when DCO is active. This prevents the Windows DNS Cache service from receiving the replies, whereas user-space DNS queries (nslookup) bypass this and succeed.