Cisco Secure Connect - DNS Troubleshooting

Remote VPN Access DNS Configuration

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.

Navigate to Secure Connect > Remote Access > DNS and configure internal DNS resolver and default domain.

End Device DNS Configuration

Verify that the clients are configured with the right DNS server IP address.

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'
• verify IP address and reachability

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 

Internet access will not be affect when the DNS server you configured is not reachable as it will failover-over back to the local DNS resolver.

Split DNS mode 

With ‘Split’ DNS Secure Client only allows internal DNS queries via the VPN interface, and only allows external DNS queries via the LAN/physical interface. 

Notice: Split DNS mode is only available when select "Only send traffic going to these destinations" (Split-Include) under Traffic Steering.

These are the benefits of Split DNS mode:

• 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 Secure Connect -> Remote Access -> DNS are resolved down the VPN: 

On Windows, Secure Client 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 Secure Client 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). If DNS servers defined are not reachable from local machine, you would likely not have access to the Internet due to the unaccessible of DNS resolver.
 

No servers could be reached

UDP port 443 is used for DNS communication between client and Umbrella DNS Resolvers. Execute nslookup -type=txt debug.opendns.com -port=443 to verify client server connectivity.

"no servers could be reached" indicates that UDP port 443 is not allowed though the organization network upstream to the Umbrella resolvers. Check any local firewalls that may be blocking this traffic.

network orgid 0

Network orgid should be the number for the umbrella organization. If this number is reported as zero it means that DNS packet was received by the Umbrella DNS resolver, but it was not identified as it belongs to any organization. This is exception in case of Remote Access users.  Remote Access user using Secure Client Umbrella Module is identified by its profile and can be seen in Umbrella Dashboard > Deployments > Roaming Computers.

Verify following when dealing with branch users:

• There is no upstream interception of DNS packets causing the DNS packet rewrites (firewall, ISP, etc)
• Verify if there is MX Auto VPN exclusion with network identifier configured OR
• Verify API DNS integration with MX.

Please reference to Manage DNS Policies document for configuration verification.

DNS API integration was working before but not any more

During provisioning of Secure Connect it is required to exchange 3 API keys between Umbrella and Meraki Dashboards. One of the API keys is network key which is also used for DNS API integration. In some instances network key was not saved and it was required to regenerate a new one. In this case, for all Meraki networks that had DNS API integration, replacement of API key has to be done manually.

Navigate to Network-wide > General > Cisco Umbrella Account > new credentials and update the API key and secret. Note that this has to be done per each network that has DNS integration already enabled. 

In future API releases this will not be required.

Remote client not protected 

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 or 208.67.220.220 as a DNS server for the Remote Access client, but this is for resolution only and the client receives no “policy” or filtering.

• To enforce a DNS policy Secure Client should have Umbrella Module and its profile installed.

Step by step procedure is described in Umbrella Roaming Client document.