Cisco ASA VPN with split-dns on a Windows VPN client

ciscocisco-asadnssplit-tunnelingvpn

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. For Cisco ASA, the operative command that claims to achieve this is split-dns.

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). 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. 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. 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.

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?

Best Answer

Experiment

There is a lot of conflicting information about what actually happens on a Windows client when using split-dns. So much that I decided to gather some evidence and see where it points. I set up a simultaneous packet capture on both the VPN-connected Windows client and the ASA to which that client is connected. Here is a diagram of the test setup:

With the packet captures running, I initiated DNS resolution on the client. To do so, I pressed enter on srv1.internal.example.com in Google Chrome. Here are the resulting packet captures adjusted to sync their clocks and merged together.

Packets with IDs starting with "C" are from the Windows [C]lient.
Packets starting with "A" are from the [A]SA.

enter image description here

Analysis

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:

8.8.8.8 - the DNS Server associated with the Wifi Adapter (packet C69)
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 C78)
10.10.10.4 - the second DNS Server associated with the VPN Adapter (packet C81)

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. 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. These DNS queries ultimately succeed.

Answers to the original questions

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?

Based 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.

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?

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. In fact those requests are serviced by the internal DNS server.

I'm not sure exactly how this is accomplished, and there doesn't seem to be any documentation from Cisco that speaks to this. I accept that there is some amount of sorcery that the VPN client performs on the Windows end to achieve a functioning split DNS.

Notes on Adapter Binding Order

I tinkered with the oft-cited adapter binding order. Here is what I found. 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.

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. Those requests seem to be dropped entirely by the VPN Client (presumably because they don't match the internal domain). This then results in a Windows timeout (or a series of them) until, eventually, Windows attempts DNS resolution using the non-VPN adapter. This creates a noticeable and irritating delay when browsing.

Based on this, it seems that in split DNS configurations the VPN adapter should not be the highest priority.

Related Solutions

Cisco ASA double NAT with DNS translation

Answering my own question to help future googlers. I spent about 3 hours on the phone with TAC; we finally got to the root cause of the issue.

The solution is to add a special NAT entry, which matches the IP address in the DNS A-Record when it arrives on the INSIDE interface.

object network DNS_NAT_masd1
 description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
 host 1.195.18.182
 nat (DMZ,INSIDE) static 10.195.18.182

When I asked for a pointer to documentation that describes why DNS translation works this way, the TAC lead said that he didn't know of any that described this behavior. The TAC lead also mentioned that with more code, the ASA would know to automatically translate the DNS A-Record without explicitly adding object network DNS_NAT_masd1; however, that is not how the dns keyword for ASA NAT works today. For reasons that still are not completely clear yet, the ASA requires the DNS A-Record IP to match the <proxy_addr> in the NAT statement, using syntax similar to this...

object network obj-EXAMPLE
 description NAT object explicitly for translating DNS A-Records
 host <proxy_addr>
 nat (<REAL_INTF>,<PROXY_INTF>) static <real_addr> dns

The difficulty is that this configuration is exactly backwards for what you need to do if you're going to nat regular "data plane" IP traffic through the firewall.

This is the whole configuration that works...

object network DMZ_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
 host 10.195.18.182
 description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
 host 1.195.18.182
 description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
!
object network DMZ_NAT_masd1
 nat (DMZ,INSIDE) static 192.168.11.101
object network INSIDE_NAT_masd1
 nat (INSIDE,DMZ) static 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
 nat (DMZ,INSIDE) static 10.195.18.182 dns

Cisco ASA5505 Clientless VPN/CIFS Configuration Questions

After a long period of experimentation and follow-up with Cisco, I've got the following answers:

There is no recycle bin equivalent when deleting CIFS files from a Windows server via the clientless VPN.
There is no way to enable any kind of confirmation dialogue for file deletions at this point in time. So people can be trying to click the "favourite" button, be off by a millimetre, and accidentally delete with no confirmation and no trash to recover from. :-( They've put in the ability to turn on confirmations as a feature request, but there's no timeline on when it might be implemented. So guess we won't be using this feature, which is sad.
I added our nbns server to the Cisco config, and now clicking the Browse entire network button shows me the domain. However, when I click on the domain, it says "Failed to retrieve servers". A had a support tech look at this, and he said the config all looks fine, and he found a few other instances of this for other users. He said he'd investigate and get back to me.

While waiting, I disabled file browsing. A few days later, when he wanted me to show him the issue, I turned it back on and it was working! (There's still a second domain showing in there that isn't on my nbns server...still no idea what the deal is with that. But the real domain is working.) So I don't know if the browsing just basically needed a kick in the pants after I added the nbns server config? No idea. But it's okay now.

Having some links that use the clientless VPN and some that don't is in fact possible through content-rewrite rules (http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/asdm64/configuration_guide/asdm_64_config/vpn_clientless_ssl.html#wp2389515)

"By default, the security appliance rewrites, or transforms, all clientless traffic. You might not want some applications and web resources (for example, public websites) to go through the ASA. The ASA therefore lets you create rewrite rules that let users browse certain sites and applications without going through the ASA. This is similar to split-tunneling in an IPSec VPN connection."

However - and I have confirmation of this from a Cisco support rep to back up my test results - this does not work in combination with SSO. If you're using the rewrite rules you cannot send parameters of any kind.