#Cisco anyconnect 4.3 dns not working series#
This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). Putting the VPN adapter highest in the binding order seems to result in Windows sending DNS requests only to the DNS servers on the VPN adapter initially. The adapter order seems to have no impact on the efficacy of the VPN Client's ability to intercept and translate DNS queries for internal domains. I tinkered with the oft-cited adapter binding order.
I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS. I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. In fact those requests are serviced by the internal DNS server. The fancy part that was missing is that the VPN client performs a sort of network address translation to make it appear to Windows that DNS queries for the internal domain are being serviced by the public DNS server to which Windows sent its request. If Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers?īased on the above evidence, the VPN client seems to intercept DNS queries that match the domain configured using the split-dns value command on non-VPN adapters.Īm I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter? The responses from the DNS server for those translated queries are in A97 and A106 which are themselves then translated to external addresses again in packets C74 and C84, respectively. What is most revealing is that the two DNS queries apparently sent to 8.8.8.8 appear at the ASA in packets A95 and A105 with source and destination IPs translated from external addresses to internal addresses. 10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet C81).8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C78).10.10.10.3 - the first DNS Server associated with the VPN Adapter (packet C70).8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C69).In orange, we can see four separate DNS queries that are trying to be made by Windows/Chrome: The destinations of the four DNS queries are as follows: Packets starting with "A" are from the SA. Packets with IDs starting with "C" are from the Windows lient. Here are the resulting packet captures adjusted to sync their clocks and merged together. To do so, I pressed enter on in Google Chrome. With the packet captures running, I initiated DNS resolution on the client. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. So much that I decided to gather some evidence and see where it points. There is a lot of conflicting information about what actually happens on a Windows client when using split-dns. So, if Windows opts to send DNS queries for internal domains to adapters other than the VPN adapter, how can the VPN client ensure all DNS queries for internal domains are tunneled to the internal DNS servers? Am I missing something here? Is there something fancy going on that somehow allows the VPN client to intercept DNS queries that Windows sends to the wrong adapter? If so, how, exactly, does that work? Furthermore, it seems that Windows might even choose to send a DNS query for an internal domain to the physical adapter which only has public DNS servers associated with it. In fact, Windows will attempt the same DNS query on a different adapter if it doesn't receive a response from the first one within one second. The method that Windows uses to decide which network adapter and DNS server to use cannot by itself enforce that all internal DNS queries are sent to the the VPN adapter and that all public DNS queries are sent to the physical adapter.
When you establish a remote access VPN connection using a Windows machine, the VPN connection shows itself as a separate network adapter (at least for the Cisco clients I have experience with). For Cisco ASA, the operative command that claims to achieve this is split-dns. Split DNS ostensibly allows a remote device accessing a LAN using VPN to direct DNS queries for internal domain names to internal DNS servers while queries for public domain names are directed to public DNS servers local to the remote device.