Skip to main content
Cisco Meraki Documentation

Cisco Secure Connect - DNS Troubleshooting

 

This article provides an overview of common DNS issues you may encounter with Cisco Secure Connect and troubleshooting steps you can take to resolve these common issues.

 

 

Remote user cannot resolve internal DNS

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

Screenshot 2024-07-11 at 11.28.42 PM.png 

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

Screenshot 2024-07-11 at 11.41.08 PM.png

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 where 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 

 

External DNS is not Resolving

Screenshot 2024-07-12 at 10.47.22 AM.png

Make sure that internal DNS has Forwarders configured to resolve external domains. This example is from Windows Server:

Screenshot 2024-07-12 at 10.52.04 AM.png

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. 

clipboard_e8837b87cc30c4245eee8702bdb0ee0fa.png 

DNS Resolution Mode 

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.

clipboard_e6c53fc7bcf601cee033fe877c7cad97d.png

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: 

clipboard_e655da3f400391f985495c2d4f65908f7.png 

 

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.
 

DNS Policy not Enforced

For DNS policy to be enforced Umbrella DNS Resolvers must receive the DNS requests and organizations identifiers must be configured.

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.

Screenshot 2024-07-12 at 1.22.57 PM.png

"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

Screenshot 2024-07-12 at 1.31.05 PM.png

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.

Screenshot 2024-07-12 at 2.13.25 PM.png

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.

 

Web Browser Reports Generic Error 

Screenshot 2024-07-12 at 2.18.09 PM.png

DNS requires Umbrella root Certificate to be installed on the client machine to impose the Umbrella blocked page. Secure Web Gateway can use Umbrella or customer provided custom certificate. 

Navigate to Umbrella dashboard > Deployments > Configuration > Root Certificate to download or upload the required certificate.  Once the certificate is installed manually or using MDM solution on the end devices, configured block page can be displayed.

 

Screenshot 2024-07-12 at 2.26.56 PM.png

DNS Policy Tester

To verify if policy has desired outcome use DNS Policy tester. Navigate to Secure Connect > DNS >  Policy Tester.

 

Screenshot 2024-07-12 at 2.38.11 PM.png

 

Similarly Web Policy tester can be used for Secure Web Gateway policies.