One AnyConnect User Cannot Resolve Internal Hostnames While VPN Is Connected

Capture the behavior instead of assuming which DNS server is being used. A packet capture on both the VPN adapter and the physical network adapter can show where the internal DNS queries are going. Check for UDP or TCP port 53, and also DNS-over-TLS or DNS-over-HTTPS traffic that could bypass the VPN’s DNS configuration. `nslookup` is useful, but it does not always reflect how every application performs name resolution.

Try to isolate whether the problem follows the user or the computer. Have the user sign in from another machine, or have another user test the affected laptop. If the issue stays with the laptop, check for security software, proxy or traffic-redirection tools, network filter drivers, other VPN clients, and a mismatched AnyConnect version. Removing and reinstalling AnyConnect after clearing its old configuration may help; rebuilding the machine may be reasonable if it is the only affected client.

An overlapping home subnet is worth checking, but it is less likely here because the internal systems are reachable by IP address. If the problem is limited to name resolution, focus first on the VPN adapter’s DNS servers and suffix configuration rather than routing.

Start by comparing `ipconfig /all` on the affected laptop with a working VPN client while AnyConnect is connected. Check the AnyConnect virtual adapter, DNS server addresses, DNS suffix/search list, routing, and adapter order. Also compare the AnyConnect profile and client logs. Since internal resources work by IP and other users resolve the same names, the internal DNS service is probably fine; the affected machine is likely selecting or applying DNS settings differently.