Guest

Cisco AnyConnect Secure Mobility Client

VPN, DNS Queries, and Operating System/Platform Variants FAQ

Hierarchical Navigation

Document ID: 116016

Updated: Jan 28, 2014

Contributed by Cisco TAC Engineers.

   Download PDF
   Print

Introduction

This document describes how different operations support systems (OSS) handle domain name system (DNS) queries and their affect on domain name resolution with AnyConnect.

What are the differences in the ways different OSS platforms handle DNS queries, and how does that affect domain name resolution with AnyConnect and split or full tunneling?

Split versus Standard DNS

When you use split-include tunneling, you have three options for DNS:

  1. Split-DNS -  DNS queries that match the domain names configured on the Cisco Adaptive Security Appliance (ASA) go through the tunnel, for example, to the DNS servers defined on the ASA, and others do not.

  2. Tunnel-all-DNS -  only DNS traffic to the DNS servers defined on the ASA is allowed. This setting is configured in the group policy.

  3. Standard DNS - all DNS queries go through the DNS servers defined by the ASA and, in the case of a negative response, might also go to the DNS servers configured on the physical adapter.

Note: The split-tunnel-all-dns command was first implemented in ASA Version 8.2(5). Before this version, you could only do split-dns or standard dns.

In all cases, the DNS queries defined to go through the tunnel go to any DNS servers defined on the ASA. In particular, if there are no DNS servers defined on the ASA, then the DNS settings are blank for the tunnel. This also means that, ideally, if you do not have split-DNS defined, then all DNS queries are sent to the DNS server defined by the ASA. However, in reality, the behaviors described in this document can be different, dependent on the operating system.

Note: Avoid using NSLookup when you test the name resolution on the client. Instead, rely on a browser or use ping. This is because NSLookup does not rely on the operating system (OS) DNS resolver, and therefore, AnyConnect does not force the DNS request via a certain interface. It only allows it or rejects it, according to the split-DNS configuration. In order to force the DNS resolver to try an acceptable DNS server for that request, it is important that split-DNS testing is only performed with applications that rely on the native DNS resolver for domain name resolution. For example, all applications except NSLookup, Dig, and similar applications, which handle DNS resolution by themselves.

True Versus Best Effort Split-DNS

AnyConnect Release 2.4 supports Split-DNS Fallback (best effort split-DNS), which is not the true split-DNS found in the legacy IPSec client. If the request matches a split-DNS domain, AnyConnect allows the request to be tunneled in to the ASA. If the server cannot resolve the host name, the DNS resolver continues and sends the same query to the DNS server mapped to the physical interface. On the other hand, if the request does not match any of the split-DNS domains, AnyConnect does not tunnel it in to the ASA. Instead, it builds a DNS response so that the DNS resolver falls back and sends the query to the DNS server mapped to the physical interface. That is why this feature is not called split-DNS, but DNS fallback for split tunneling. In other words, not only does AnyConnect assure that only requests which target split-DNS domains are tunneled in, it also relies on the client OS DNS resolver's behavior for host name resolution.

This raises security concerns due to potential private domain name leak. For example, the native DNS client can send a query for a private domain name to a public DNS server, specifically when the VPN DNS name server could not resolve the DNS query.

Refer to bug CSCtn14578, currently resolved on Microsoft (MS) Windows only, as of Version 3.0.4235. The solution implements true split-DNS; it strictly queries the configured domain names that match and are allowed to the VPN DNS servers. All other queries are only allowed to other DNS servers, such as those configured on the physical adapter(s).

“Tunnel all” and “Tunnel all DNS”

When split tunneling is disabled (the tunnel-all configuration), DNS traffic is allowed strictly via the tunnel. Similarly, when the tunnel all DNS configuration, which sends all DNS lookups through the tunnel, is configured in the group policy, along with some type of split tunneling, DNS traffic is allowed strictly via the tunnel.

This is consistent across platforms, with these caveats on MS Windows:

When any of tunnel-all or tunnel all DNS is configured, AnyConnect allows DNS traffic strictly to the DNS servers configured on the secure gateway (applied to the VPN adapter). This is a security enhancement implemented along with the previously mentioned true split-DNS solution.

If this proves problematic in certain scenarios (for example, DNS update/registration requests need to be sent to non-VPN DNS servers), the two-step workaround is:

  1. If the current configuration is tunnel-all: enable split-exclude tunneling, any bogus one host split-exclude network works, such as a link-local address.
  2. Ensure that tunnel all DNS is not configured in the group policy.

DNS Performance Issue Resolved in AnyConnect Version 3.0.4325

This MS Windows-specific issue is mostly prevalent under these conditions:

  • Home router setup: this where the DNS and DHCP servers are assigned the same IP address (AnyConnect creates a necessary route to the DHCP server);
  • A large number of DNS domains are in the group policy;
  • Tunnel-all configuration;
  • Name resolution performed by a non-qualified host name, which implies that the resolver needs to try a number of DNS suffixes on all available DNS servers until the one relevant to the queried host name is attempted.

The issue is due to the native DNS client that attempts to send DNS queries via the physical adapter, of which AnyConnect blocks (given the tunnel-all configuration). This leads to a name resolution delay. From customer experience, this delay is sometimes significant, especially for a large number of DNS suffixes pushed by the headend, since the DNS client needs to walk through all of them (and all available DNS servers) until it receives a positive response.

This problem is resolved in Version 3.0.4325 (combination of Cisco bug ID CSCtq02141 and CSCtn14578, along with the introduction of the previously-mentioned true split-DNS solution).

However, if an upgrade cannot be implemented, then the possible workarounds are:

  • Enable split-exclude tunneling for one bogus IP Address, which allows local DNS requests to flow through the physical adapter. You can use an address from the linklocal subnet 169.254.0.0/16 because it is unlikely that any device sends traffic to one of those IP addresses over the VPN. After you enable the split exclude, remember to enable local LAN access on the client profile or on the client itself, and disable tunnel all DNS. On the ASA, the configuration changes are listed here:

    access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
     group-policy gp_access-14 attributes
     split-tunnel-policy excludespecified
     split-tunnel-network-list value acl_linklocal_169.254.1.1
     split-tunnel-all-dns disable
    exit


    On the client profile, you only need to add this line:

    <LocalLanAccess UserControllable="true">true</LocalLanAccess>


    You can also enable this on a per-client basis in the AnyConnect client GUI. Navigate to the AnyConnect Preference menu, and check the Enable local LAN access option.

  • Use the fully qualified domain names (FQDNs) instead of the unqualified host names for the name resolutions.

  • Use a different IP address for the DNS server on the physical interface.

How Does Each Operating System Deal with DNS?

There is a difference in the way different OSs handle DNS searches when used with split tunneling (without split-DNS) for AnyConnect.

MS Windows

On MS Windows, DNS settings are per-interface. This means that, if split tunneling is used, DNS queries can fall back to the physical adaptor's DNS servers if the query failed on the VPN tunnel adaptor. If split tunneling without split-DNS is defined, then both internal and external DNS resolution works because it falls back to the external DNS servers.

Macintosh

With the Macintosh (MAC), the DNS settings are global. Thus, if split tunneling is used, but split-DNS is not used, it is not possible for DNS queries to go to DNS servers outside of the tunnel. You can only resolve internally, not externally. This is documented in the Cisco bug IDs CSCtf20226 and CSCtz86314. In both cases, this workaround should resolve the issue:

  • Specify a external DNS server IP address under the group-policy and use FQDN for internal DNS queries.
  • If external names are resolvable via the tunnel, disable split DNS by removing the DNS names configured in the group policy, under Advanced > Split Tunneling. This requires using FQDN for internal DNS queries.

The split-DNS case has been resolved in AnyConnect 3.1, with these caveats:

  • Split-DNS must be enabled for both IP protocols (requires ASA v9.0 or later).


    • OR

  • Split-DNS must be enabled for one IP protocol.

       and
      
    • (If ASA has Version 9.0 or later: client bypass protocol for the other IP protocol, i.e., no address pool and Client Bypass Protocol enabled in the group policy.

      •    or

    • If ASA is earlier than Version 9.0: no address pool configured for the other IP protocol; this implies that this other IP protocol is IPv6.)

Note: AnyConnect does not change the resolv.conf file direct on MAC OS X, but rather changes OS X-specific DNS settings. OS X keeps resolv.conf up-to-date for compatibility reasons. Use the scutil --dns command to look at DNS settings on OS X.

iPhone

The iPhone is the complete opposite of the MAC, and it is not the same as MS Windows. If split tunneling is defined but split-DNS is not defined, then DNS queries go out through the global DNS server defined. For example, split-DNS domain entries are mandatory for internal resolution. This behavior is documented in Cisco bug ID CSCtq09624 and is fixed in the latest 2.5.4038 Version for the iOS AnyConnect client.

Note: Be aware iPhone DNS queries ignore .local domains, documented in Cisco bug ID CSCts89292. Apple engineers confirm that the issue is caused by the functionality of the OS. This is the designed behavior, and Apple confirms there is no change for it.

Related Information

Updated: Jan 28, 2014
Document ID: 116016