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:
- Setup an OpenVPN Community Server pushing a DNS server and routing all traffic.
- Install OpenVPN Windows Client
2.7.2.
- Use a client config with
redirect-gateway def1 (fullroute).
- Connect to the VPN (DCO is enabled by default).
- 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").
- 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.
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,
nslookupcan successfully resolve internal and external hostnames (using the VPN's DNS server), but standard applications and thepingcommand fail to resolve external domain names (e.g.,ping google.comreturns "could not find host"). Pinging external IP addresses directly (e.g.,ping 8.8.8.8) works fine.When adding
disable-dcoto 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:
2.7.2.redirect-gateway def1(fullroute).nslookup google.com-> Works (resolves via VPN DNS).ping 8.8.8.8-> Works.ping google.com-> Fails ("Ping request could not find host").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
Troubleshooting already performed
block-outside-dns-> did not help.ipconfig /flushdnsandregister-dns-> did not help.push "dhcp-option DNS ...").disable-dcoresolves 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.