Windows 11 VPN connects but internal hostnames don't resolve because client DNS suffix isn't applied

Environment

Client: Windows 11 22H2 Enterprise. VPN: IKEv2 remote access and split-tunnel configuration via corporate ASA/Firepower appliance. VPN assigns internal DNS servers via DHCP and pushes search domain 'corp.example.com'.

Symptoms

After establishing the VPN, users can reach internal resources by IP but cannot resolve short hostnames (e.g., 'sql01') — only fully qualified names (sql01.corp.example.com) work. Applications that use unqualified hostnames fail to connect until user types FQDN.

Observations

ipconfig /all shows VPN adapter with the corporate DNS servers but the 'Connection-specific DNS Suffix' field is empty for the VPN adapter. nslookup queries use the VPN DNS server and resolve FQDNs but attempts to resolve unqualified names do not append the corporate suffix. Group Policy set DNS suffix search list for domain-joined machines but policy appears not to apply to the VPN adapter.

Already attempted

Flushed DNS (ipconfig /flushdns), disabled and re-enabled the VPN, tried enabling 'Use remote gateway' and disabling split tunneling (temporary test) — when full tunnel used, suffix applies and name resolution works. Created a manual connection-specific DNS suffix for the adapter in adapter properties (works locally but resets on reconnect). Tried adding suffix via netsh interface ip set dnssuffix, but behavior inconsistent between users.

Question

What are the reliable ways to ensure the VPN adapter receives and applies the corporate DNS suffix on Windows 11 with split tunneling? Are there registry or Group Policy settings that force the suffix to be appended for VPN interfaces without forcing full tunnel?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Group Policy DNS suffix settings not applied to virtual adapters or overridden by client-side VPN client configuration. 85%

VPN server not pushing DNS suffix to the client in split-tunnel mode or client ignoring the pushed suffix. 75%

Windows 11 network profile heuristics or adapter metric causing the primary DNS search list to be that of another interface, preventing suffix usage for VPN-resolved names. 70%

Summary

The VPN is successfully assigning DNS servers, but the connection-specific DNS suffix is not being applied to the virtual adapter in split-tunnel mode. Windows uses adapter DNS suffixes and search lists to resolve unqualified names; absence of the suffix explains why FQDNs work but short names do not. The fact that full-tunnel mode applies the suffix indicates the server can push configuration, but client/adapter settings or VPN client behavior during split-tunnel are preventing suffix application.

Suggested Fixes

Diagnostic step 1

On the client, run ipconfig /all immediately after VPN connect and capture the full output; confirm whether DNS servers are the VPN-provided ones and whether the Connection-specific DNS Suffix is populated.

Diagnostic step 2

Compare behavior between native Windows IKEv2 and any vendor VPN client (if both available). If the native client applies the suffix but vendor client does not, raise with the VPN vendor.

Diagnostic step 3

Temporarily enable full-tunnel VPN for one client to show the expected suffix being applied; capture ipconfig /all and compare with split-tunnel session to prove the difference to network/security team.