OpalSpan

VPN connected, internal names failing: diagnose Windows split DNS before resetting anything

By Ready IT ApS

Published

The VPN says connected. An internal server is reachable by IP, yet its hostname fails. Public websites still work. For an IT support provider, this is a useful distinction: the tunnel may be carrying traffic while Windows sends a particular DNS question to the wrong resolver.

Start by comparing the same fully qualified name through normal Windows DNS resolution and directly against the approved internal DNS server. If the direct query succeeds but the normal query fails, investigate resolver selection and namespace policy. If both fail, investigate the DNS server, its records and the path to it. A network reset does not make that distinction and can disturb an otherwise working support connection.

This guide covers the Windows DNS client on supported Windows 11 releases and VPN clients that integrate with it. As of 13 October 2026, Windows 11 25H2 and 26H2 are supported for Home/Pro, as is 26H1 on its designated new-device hardware; 24H2 Home/Pro has reached end of updates, while Enterprise/Education has a different lifecycle. Check the current Microsoft release table for the device’s edition. Third-party VPN clients may implement their own DNS handling: record the exact client and version before applying its vendor’s configuration.

A real support question, not a universal fix

The Server Fault question “DNS Server Search order in Windows 10 and VPNs” describes an internal name failing while the VPN DNS server responds to ping and public names resolve. A 2025 OpenConnect question reports the same broad symptom on a different VPN stack.

Those reports establish that the failure pattern appears in more than one environment. They do not establish search volume, a common root cause or a fix for your client. The investigation below is original guidance grounded in Microsoft’s DNS and VPN documentation, not a reproduction of forum answers or server configuration snippets.

1. Agree on one name and the expected resolver

Obtain a known-good internal fully qualified domain name (FQDN), the approved internal DNS server IP and the intended VPN namespace from the customer’s network owner. Do not guess them from a similar customer. An IP connection is also not equivalent to an application working by name: HTTPS certificates, authentication and service discovery can depend on the hostname.

The following values are fictional placeholders. Replace them before querying; keep real customer names and diagnostic outputs in the customer’s approved support record. Run the commands on the affected Windows endpoint with the VPN connected, in PowerShell with the Windows DnsClient and NetTCPIP modules available. Windows PowerShell 5.1 includes these modules; if your PowerShell 7 session cannot load them, use Windows PowerShell for these checks rather than installing an unrelated DNS package. Follow local permissions; do not elevate merely to bypass device policy.

$name = 'files.corp.example'
$dns = '10.20.30.53'

Resolve-DnsName -Name $name -Type A -DnsOnly -NoHostsFile
Resolve-DnsName -Name $name -Type A -DnsOnly -NoHostsFile -Server $dns

These are diagnostic queries, not configuration changes. They generate network traffic and can populate the DNS cache. -DnsOnly excludes LLMNR/NetBIOS fallback; -NoHostsFile excludes a local hosts-file entry. Neither guarantees a fresh uncached answer. Preserve the complete result or error, including returned addresses and time observed. Do not add private names to a public resolver as a troubleshooting experiment.

Interpret the pair before changing anything:

  • Direct query succeeds; normal query fails: the server can answer this record over this path. Resolver selection, a conflicting namespace rule or cached failure is the next suspect. This does not prove the application uses Windows DNS.
  • Both time out: inspect the route to the DNS server and whether it accepts queries from the VPN address range. Ping success proves neither UDP nor TCP DNS is allowed.
  • Direct query returns NXDOMAIN: the server answered that the queried name does not exist. Check the spelling, zone and record with the DNS owner; that is different from a timeout. A negative answer is not a reason to expect another DNS server to be queried.
  • Both return the expected address: move to the application’s actual hostname, proxy and connection path. The captured DNS result alone does not prove the service works.

The example queries IPv4 address records deliberately. If the service uses IPv6, repeat with -Type AAAA and inspect the corresponding IPv6 route. An absent AAAA record is not automatically a defect; disabling IPv6 is not the diagnosis.

2. Read the adapter, namespace policy and route together

Get-DnsClientServerAddress |
    Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ServerAddresses -AutoSize

Get-DnsClient |
    Format-Table InterfaceAlias, InterfaceIndex, ConnectionSpecificSuffix -AutoSize

Get-DnsClientGlobalSetting | Format-List SuffixSearchList, UseSuffixSearchList, UseDevolution

Get-NetIPInterface |
    Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ConnectionState, InterfaceMetric -AutoSize

Get-DnsClientNrptPolicy -Effective |
    Format-List Namespace, NameServers

Find-NetRoute -RemoteIPAddress $dns | Format-List

Identify the active VPN interface by its actual alias and index; a virtual adapter’s presence does not establish that the tunnel is active. Compare its DNS servers with the profile the network owner intended. Find-NetRoute shows the selected local address and route to the resolver, not whether a DNS packet gets through. A corporate resolver reached through the home-LAN route instead of the intended tunnel is a routing problem to resolve before DNS policy tuning. Overlapping customer and home subnets deserve particular attention.

Microsoft’s VPN name-resolution documentation describes namespace matching in the Name Resolution Policy Table (NRPT). Without a matching rule, interface preference and suffix handling become relevant. The effective policy matters more than a remembered setting in an old profile export.

For the chosen FQDN, look for a matching namespace and the expected NameServers. Check for a more-specific conflicting rule. No output from Get-DnsClientNrptPolicy -Effective means no effective entries were returned, not that split DNS cannot exist: some VPN clients use another implementation.

A low interface metric is not a namespace policy. Making the VPN “first” can send unrelated queries toward a corporate resolver and still leave a client-specific problem unresolved. Inspect IPv4 and IPv6 separately instead of changing every adapter to the same metric.

3. Separate short-name failure from split-DNS failure

If files.corp.example resolves but files does not, compare the connection-specific suffix and the suffix search list with the customer’s intended naming convention. A search suffix completes a short name. A split-DNS rule selects a resolver for a namespace. They solve different parts of the problem.

Test the short name only if it is an intended customer workflow:

Resolve-DnsName -Name 'files' -Type A -DnsOnly -NoHostsFile

A successful FQDN query is already useful: it narrows the failure away from the record and toward short-name expansion. Prefer the FQDN for a temporary application test where supported. Do not deploy hosts-file entries as a fleet-wide workaround; they create a separate static naming authority and can conceal later record changes.

4. Correct the owning VPN profile, not every network setting

Keep the original profile values and an approved rollback before changing them. If the device is managed, make the correction through the VPN policy owner. Local changes may be overwritten and do not repair the configuration delivered to other devices.

For an Intune Windows VPN profile using Microsoft’s documented DNS-rule settings, the focused correction is:

  1. Open the existing profile’s DNS/name-resolution settings and identify the rule intended for the customer’s internal namespace.
  2. Set that rule’s Name to the exact intended namespace and Servers to the approved internal DNS server addresses. For example, a suffix namespace such as .corp.example and resolver 10.20.30.53 illustrate the relationship; use the namespace form required by the actual profile and vendor, not these fictional values.
  3. If only short names fail, correct the VPN DNS suffix/search configuration to the approved suffix instead of broadening the DNS rule.
  4. If the route to the resolver is wrong, correct only the profile route covering that resolver or approved corporate subnet. DNS rules cannot deliver packets over a missing route.
  5. Test the corrected profile on one authorized affected endpoint before widening assignment. Follow the provider’s supported profile-update process; retain the previous policy for rollback.

Microsoft maps the DNS rule to DomainNameInformationList and the suffix to DnsSuffix in VPNv2 CSP. That mapping is not a promise that an OpenConnect, OpenVPN or other third-party client’s server accepts those settings. Use that client’s current documentation and verify what Windows actually receives after connecting. Do not transplant a forum’s server options into a different VPN stack.

Keep the intended split-DNS boundary. An all-names rule, replacing the Wi-Fi DNS servers with a public resolver, disabling endpoint protections, or a Winsock/network reset is not a scoped correction. If direct queries time out, ask the network/DNS owner to inspect the specific permitted VPN-to-DNS path and server query policy; do not disable a firewall to find out.

5. Verify after reconnect, then leave a usable handback

Reconnect only in an agreed window: the VPN may be the path carrying your current support session. Have a recovery route before dropping it. Once the corrected profile is active, rerun the adapter/policy/route checks and the two FQDN queries. If cached results could mask the outcome, inspect the cache first:

Resolve-DnsName -Name $name -Type A -CacheOnly

Use the approved cache-expiry or cache-clearing procedure only when needed after preserving evidence. Clearing the entire client cache affects other names too; it is not proof of a profile repair. Record whether each result was cache-only, ordinary DNS or directed to a specific server.

Acceptance is more than a green VPN icon:

  • The internal FQDN resolves through normal Windows DNS to the approved address, and the application works using its intended hostname.
  • The short name works if it is a required workflow; otherwise record that it was not tested or is unsupported by the naming convention.
  • An approved public name still resolves through the intended policy. Public resolution alone does not prove private queries never leave the tunnel; use approved resolver logs or narrowly scoped tracing if leakage is the actual acceptance requirement.
  • After an authorized disconnect/reconnect, the intended rule is restored. Outside the VPN, behavior matches the customer’s policy: persistent rules and connection-only rules need different expectations.

Record the device OS/client version, VPN profile, observation time, exact failing name, direct-versus-normal result, selected route, effective rule, changed setting, previous value and verification limits. “Internal FQDN works; short names still fail” is a useful handback. “DNS fixed” loses the next technician’s starting point.

Delegate the evidence collection without losing the boundary

With an authorized connected device, OpalSpan Mech can carry out scoped technical work in a browser conversation and keep the findings and proposed next step together. Ask it to compare the affected FQDN, approved resolver, effective policy and route before proposing a change. Specify that it must not reset networking, disconnect the support path or change a managed profile without the appropriate authority. The result may be a supported correction or a precise blocker for the network owner, not a guaranteed repair.

Your external assistant can instead operate OpalSpan Agent CLI under the same user permissions; the technician directs and reviews rather than manually operating the CLI. OpalSpan supports Windows and Linux; macOS is a technical preview, in active development. This Windows DNS procedure is not a claim of identical commands or VPN behavior on those platforms.

See how OpalSpan fits your support work.

Technical references

Sources checked 13 October 2026. Microsoft’s VPN name-resolution page reports an update on 8 October 2026; the PowerShell references below report May 2025 updates. Older forum reports identify a problem, not current support guarantees.