vpn split dns not working on windows 11

Not specified by the original author.

TL;DR

Split DNS on Windows 11 breaks when the VPN adapter is not the one answering internal queries: wrong adapter DNS order, missing Name Resolution Policy Table rules, or the VPN client not pushing them. Check which adapter answers the query first, then fix the NRPT or adapter settings.

The query

vpn split dns not working on windows 11

Use this when

• internal hostnames do not resolve while the VPN is connected
• nslookup gives the public answer for an internal name
• split DNS worked on Windows 10 but broke on 11

Not for

• full-tunnel VPNs where all DNS goes through the tunnel
• DNS working but traffic not routing (different problem)
• the VPN client not connecting at all

Steps

1. With the VPN connected, run nslookup for an internal hostname and note which server answers. Expected output: you see which DNS server handled the query
2. Check the VPN adapter's DNS servers in the adapter settings. Expected output: the corporate DNS servers listed on the VPN adapter
3. Check the Name Resolution Policy Table with Get-DnsClientNrptPolicy for rules covering the internal domain. Expected output: NRPT rules present or confirmed missing
4. If rules are missing, check the VPN client or profile settings that should push them. Expected output: the source of the missing rules identified
5. Confirm no third-party DNS or VPN-adjacent software is overriding resolution. Expected output: no conflicting resolver
6. Reconnect the VPN and retest the internal hostname. Expected output: the internal name resolves to the internal address

Provenance

Resolved from the public thread: https://vectle.com/posts/pstthJuYoBNa4Kji1U7hLdRQ

Resolved from the public thread: https://vectle.com/posts/pstthJuYoBNa4Kji1U7hLdRQ

Thread query: vpn split dns not working on windows 11

TL;DR: Split DNS on Windows 11 breaks when the VPN adapter is not the one answering internal queries: wrong adapter DNS order, missing Name Resolution Policy Table rules, or the VPN client not pushing them. Check which adapter answers the query first, then fix the NRPT or adapter settings.

Not specified by the original author.

TL;DR

Confirm the VPN client is using the corporate DNS servers (nslookup will show which server answered), then check the DNS suffix search list includes the internal domain. If the home router is answering, DNS is leaking outside the tunnel and the client must be set to force DNS through the tunnel.

The error

nslookup intranet: server can't find intranet: NXDOMAIN (while on VPN)

Steps

1. Run nslookup internalhostname and note which server answered. Expected: the corporate DNS server. If the home router (192.168.x.1) answered, DNS is leaking.
2. Check the VPN client's DNS settings: it must push the corporate DNS servers on connect. Expected: corporate servers listed first in the adapter settings.
3. Check the DNS suffix search list includes the internal domain (e.g. corp.example.com). Expected: present. Without it, short names like "intranet" never resolve.
4. Test the FQDN: nslookup intranet.corp.example.com. Expected: resolves. If FQDN works but short name does not, it is purely a suffix issue.
5. If DNS still leaks, enable "force all DNS through tunnel" (or the client's equivalent) and reconnect. Expected: corporate DNS answers everything. Some clients need this explicitly.

When to use

• Internal names fail over VPN, IPs work
• Short names fail but FQDNs work

When not to use

• Nothing resolves, internal or external (broader DNS/network issue)
• VPN not connected

Compatibility

• Any VPN client; Windows/macOS DNS settings

Variants

Split-DNS configured intentionally

Some orgs resolve only corp domains internally; confirm the intended behavior before "fixing" it.

Works for some users only

Compare client versions and profiles; the DNS push settings differ.

Why it happens

Name resolution follows the configured DNS servers and suffix list, not the tunnel. The tunnel carries packets, but if the client asks the wrong server, internal names do not exist as far as the client knows.

Edge cases

• Browsers with secure DNS (DoH) bypass the VPN DNS entirely; disable DoH on managed devices or allowlist the behavior.
• ipconfig /flushdns after fixing settings to clear stale negative entries.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ccNAtH3a0jBYhR7RA6G71w

Resolved from the public thread: https://vectle.com/posts/pst_ccNAtH3a0jBYhR7RA6G71w

Thread query: "dns not resolving internal hostnames over vpn"

TL;DR: Confirm the VPN client is using the corporate DNS servers (nslookup will show which server answered), then check the DNS suffix search list includes the internal domain. If the home router is answering, DNS is leaking outside the tunnel and the client must be set to force DNS through the tunnel.

Not specified by the original author.

TL;DR

Check whether it is DNS or routing: ping an internal server by IP. If IP works but names do not, it is a DNS problem (fix the VPN DNS servers). If IP fails too, check the client's route table for the tunnel routes and confirm split-tunnel includes the right subnets.

The error

(Connected to VPN, but intranet sites, file shares, or internal apps do not load.)

Steps

1. Ping an internal server by IP address. Expected: replies. If IP works, skip to step 3 (DNS issue). If IP fails, continue (routing issue).
2. Check the route table: Windows route print, macOS netstat -rn. Expected: tunnel interface has routes for internal subnets. Missing routes mean split-tunnel config or a client routing failure; reconnect and recheck.
3. Check DNS: nslookup internalhost and confirm which server answered. Expected: the corporate DNS server over the tunnel. If the home router answers, DNS is leaking outside the tunnel.
4. Verify the VPN client's DNS settings push the corporate servers. Expected: corporate DNS listed first. Some clients need "force all DNS through tunnel" enabled.
5. Test one internal app by IP and one by name, then check the internal firewall allows the VPN pool subnet. Expected: both work. VPN client subnets are sometimes missing from firewall rules after a pool change.

When to use

• VPN shows connected, internal resources unreachable
• Works by IP but not by name (or vice versa)

When not to use

• VPN will not connect at all
• Only one specific app fails (app issue, not VPN)

Compatibility

• Any VPN client (GlobalProtect, AnyConnect, Zscaler, WireGuard); split or full tunnel

Variants

Worked yesterday, broken today

DHCP or DNS change on the client network, or a firewall rule change. Check what changed.

Some subnets work, others do not

Split-tunnel include list is incomplete. The network team must add the missing subnets.

Why it happens

"Connected" only means the tunnel is up. Traffic still needs correct routes to enter the tunnel and correct DNS to find names. Either can break independently of the tunnel itself.

Edge cases

• IPv6: if the client prefers IPv6 and the tunnel is IPv4-only, names may resolve to unreachable IPv6 addresses.
• Local subnet overlap: the user's home 192.168.1.x colliding with corporate 192.168.1.x breaks routing; the fix is renumbering one side.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eL3kWK2c7cplz8vagCt1YQ

Resolved from the public thread: https://vectle.com/posts/pst_eL3kWK2c7cplz8vagCt1YQ

Thread query: vpn connects but no internal resources reachable

TL;DR: Check whether it is DNS or routing: ping an internal server by IP. If IP works but names do not, it is a DNS problem (fix the VPN DNS servers). If IP fails too, check the client's route table for the tunnel routes and confirm split-tunnel includes the right subnets.