When working with OpenVPN configurations that employ both gateway redirection and custom DNS pushing, a common issue arises where DNS queries aren't properly routed through the VPN tunnel despite correct configuration. Here's what's happening under the hood:

# Typical problematic OpenVPN server config
push "dhcp-option DNS 192.168.1.2"
push "redirect-gateway def1"

On Windows systems (the behavior differs on Linux/Unix), the OS maintains a DNS resolution order that might prioritize your physical interface's DNS servers. Even though ipconfig /all shows the VPN-pushed DNS server, the resolution attempt might bypass it.

# What you see in ipconfig (simplified)
Ethernet adapter Ethernet:
   DNS Servers . . . . . . . . . . . : 8.8.8.8
                                       8.8.4.4

PPP adapter OpenVPN:
   DNS Servers . . . . . . . . . . . : 192.168.1.2

Here are several approaches to enforce proper DNS resolution:

Option 1: Registry Modification (Windows)

Adjust the DNS resolution order by modifying the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"InterfacePriorityMetric"=dword:00000001

Option 2: Script-Based Solution

Add this to your OpenVPN configuration file:

script-security 2
up "c:\\path\\to\\update-dns.cmd"
route-up "c:\\path\\to\\update-dns.cmd"

Where update-dns.cmd contains:

@echo off
for /f "tokens=3 delims=: " %%A in ('netsh interface ip show config name="OpenVPN" ^| findstr "DNS"') do (
    netsh interface ip set dns name="OpenVPN" static %%A primary validate=no
    netsh interface ip add dns name="OpenVPN" addr=%%A index=2 validate=no
)

Option 3: Alternative OpenVPN Configuration

Try this more aggressive DNS approach:

push "dhcp-option DNS 192.168.1.2"
push "dhcp-option DOMAIN internal.dom"
push "redirect-gateway def1 bypass-dhcp"
register-dns
block-outside-dns

After applying any solution, verify with:

nslookup somesite.internal.dom
ping somesite.internal.dom
tracert somesite.internal.dom

Check which DNS server is actually being used with:

nslookup
> server
> somesite.internal.dom

For advanced troubleshooting, use these PowerShell commands:

Get-DnsClient | Select-Object InterfaceAlias,InterfaceIndex | Sort-Object -Property InterfaceIndex
Get-DnsClientServerAddress | Select-Object InterfaceAlias,ServerAddresses

---

When OpenVPN's redirect-gateway def1 is combined with pushed DNS servers, Windows systems exhibit a peculiar behavior where:

1. The VPN connection receives the correct DNS server (192.168.1.2 in your case)
2. The DNS server appears in ipconfig output
3. Yet DNS queries bypass the VPN DNS for certain requests

Windows' DNS client service implements a "smart multi-homed name resolution" algorithm that:

• Queries all available DNS servers simultaneously
• Accepts the first positive response received
• Prioritizes interfaces with lower latency

Add these OpenVPN server configurations:

# Disable DNS fallback
push "block-outside-dns"
# For Windows 10/11 specific behavior
push "register-dns"
# Alternative method (legacy Windows)
push "dhcp-option DNS 192.168.1.2"
push "dhcp-option DOMAIN internal.dom"

For Windows clients, create a .reg file with:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"DisableParallelAandAAAA"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient]
"DisableSmartNameResolution"=dword:00000001

Check effective DNS settings with:

Get-DnsClientServerAddress -InterfaceAlias "*VPN*" | Select-Object -ExpandProperty ServerAddresses
Resolve-DnsName somesite.internal.dom -Server 192.168.1.2

Force VPN interface priority:

netsh interface ipv4 set interface "Ethernet" metric=50
netsh interface ipv4 set interface "VPN Connection" metric=10

Capture actual DNS traffic to verify paths:

# Windows:
netsh trace start scenario=NetConnection capture=yes tracefile=dns.etl
# After reproducing issue:
netsh trace stop

# Linux alternative:
sudo tcpdump -i tun0 port 53 -w vpn-dns.pcap