Skip to main content
Cisco Meraki

Cisco+ Secure Connect DNS Troubleshooting

 

For Customers with Private Access, there is a need to include the Private DNS server IPs in the Private network configurations. This will ensure internal domains are being resolved by the VPN clients.

 

 

Verify that the clients are configured with the right DNS server ip.

Windows:

  • Open the command prompt
  • run the command: 'ipconfig /all'
  • verify the IP address on the DNS Servers line 

 

macOS:

  • Open a terminal 
  • run the command: 'scutil --dns'

 

Multiple Internal DNS servers

It is important that the Primary DNS Server, which is specified in the configurations, can resolve all Internal domains considering conditional forwarding within Secure Connect is not available. In case a Customer has multiple DNS servers and zones, eg. Zone1.local > 192.168.1.1, zone2.local > 192.168.2.1, the primary DNS should do the conditional forwarding. To test the primary DNS can resolve the private domain, run the nslookup commands on the client machine:

nslookup [zone/private domain]

output: nslookup [zone/private domain] DNS IP

e.g

nslookup host.zone1.local 192.168.1.1 

nslookup host.zone2.local 192.168.2.1 

 

DNS Failover  

It is advisable that a secondary DNS server is configured for failover purposes. A client will failover to the secondary DNS server IP in case the primary is either not responding or taking longer than expected to respond to DNS queries. 

 

Default DNS mode 

 

In the default DNS mode, how queries are sent depend on the operating system.   

 

  • Modern windows operating systems will send DNS queries to the VPN interface and LAN/physical interface at the same time and just uses the fastest response.   

  • Older Windows OS and some other operating systems may try the VPN first and “failover” to the LAN/physical interface 

 

For the second scenario the performance of the “Private Access” VPN connections will impact DNS performance.   For best performance customers may consider using the ‘Split DNS’ mode.   

 

 

Split DNS mode 

 

With ‘Split’ DNS AnyConnect only allows internal DNS queries via the VPN interface, and only allows external DNS queries via the LAN/physical interface.  This is useful for these reasons... 

 

  • May offer better DNS performance for external DNS queries, whilst still maintaining internal DNS resolution 

  • Prevents DNS query information for your internal domains “leaking” outside the VPN 

  • Allows you to control the behavior when you have an external and internal copy of the same zone. 

 

Only domains defined on this page are resolved down the VPN: 

 

 

 

On Windows, AnyConnect actually blocks DNS queries that do not adhere to these rules and then relies on the Operating System failover to resolve the domain via the correct path.  This behavior can cause some confusing results on the client when using tools like ‘nslookup’ or ‘dig’, even when the client is working properly.  These tools only target a single server and have no concept of failover. 

 

In the example below, nslookup (using the default VPN server) appears to fail.  However, this is entirely normal because google.com is not allowed to be resolved via the VPN tunnel.  Other tools and web-browsers which use the Windows’ stub resolver work fine, because they failover to the physical interface. 

 

 

 

More information is available here: 
https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116016-technote-AnyConnect-00.html 

 

 

Tunnel All DNS Mode 

 

With ‘Tunnel All DNS’ all queries must be sent via the VPN interface.  This mode is only really advisable if you wanted to ensure no DNS leaked outside the VPN for security reasons.  The performance of the tunnel and private access will directly impact the performance of DNS.   

 

This works in a similar way to ‘Split DNS’ except anyconnect blocks all DNS traffic except via the VPN interface. 

 

In this mode, the Primary DNS server must be able to resolve ALL internal and external queries (eg. Recursion enabled). 
 

 

Umbrella DNS protection 

 

Umbrella DNS protection is available in the Secure Connect package but does not apply to Remote Access clients by default.   

 

  • It’s possible to use 208.67.222.222 as a DNS server for the RA client, but this is for resolution only and the client receives no “policy” or filtering 

  • It’s possible to enfore a DNS policy by installing our Umbrella AnyConnect Roaming Module. 

Here are some interesting things about...

  • Was this article helpful?