Skip to main content
Cisco Meraki

Cisco+ Secure Connect Troubleshooting

Anyconnect Errors

Issue/Error
Possible Cause
Resolution
Any issues with establishing a VPN connection    
  • On the VPN client, review the  Message History 

  • Dart package 

“Establishing VPN”… and eventually the connection fails  Likely SSL vpn is getting blocked via an upstream device.  To double check, have the user run DART 
  • If possible, try an alternate network connection 

  • Have the user run DART.  Review the log file within the Secure Mobility Client directory for timeout messages after “Establishing VPN” messages 

Graphical user interface, text, application

Description automatically generated

SAML IDP not configured for the Umbrella org 

Configure a SAML IDP ( SAML Configuration Guide
Valid user account but not a user that is authorized for the service  
  • Check the SAML configuration on the IDP 

  • Check the Identity Provider’s user and group permissions set for the account in question 

This error occurs when logged onto a computer remotely using RDP (Remote Desktop)  AnyConnect blocks this by default but this can be optionally allowed in (Deployments > Remote Access > Settings > Client Configuration"Tunnel 
"I can't access my local network services while I'm connected"  Local LAN access not enabled
  • Check whether local lan is enabled under Traffic Steering
  • On Anyconnect, check preferences tab to see if “local LAN if enabled” is checked

 

Network Tunnel

Issue/Error  
Possible Cause  
Resolution 

Tunnel Status is “unestablished” 

 

Check tunnel configuration 

Network Tunnel Configuration 

 

 

Cannot Reach this page

  • “Cannot Reach this page” error in AnyConnect pop-up window indicates that the client can’t access Umbrella’s SAML Gatway (gateway.id.swg.umbrella.com:443), login broker (login-broker.svc.latitude.umbrella.com:443) or the customers’ configured IdP URL.  Ensure all these destinations are allowed on the local network firewall. 

 

Single sign-on AnyConnect token verification failure

  • This error message occurs when the User is not provisioned in Umbrella’s (Deployments > Users & Groups) and Assigned selected in (Deployments > Remote Access > Settings > Assign Users & Groups).  This error essentially means the user is denied access to the VPN. 
     
     

 

UPN is not Configured

  • Umbrella branded “UPN is not configured” error.  A generic error provided when Umbrella receives an unexpected response from the Identity Provider.  Typically this happens when the IdP does not return a “Name ID” claim containing the users User Principal name (eg. User@domain.tld) .  This commonly occurs with Microsoft ADFS - a manual “claims map” must be created to enable this. 

  • Umbrella branded “Signature validation failed” error.  This happens when the certificate of the IdP has expired or been re-generated.  The admin must download a new copy of the IdP metadata and import it into ‘Deployments > SAML Configuration’ in the Umbrella Dashboard. 

 

Other errors or login failures in the Identity Provider indicate a problem with the setup in the IdP.   

 

Auditing Remote Access 

Reports in ‘Reporting > Remote Access Logs’ help identify which SAML User is logged on to which VPN pool address.  It shows the date/time of connect disconnect events along with a reason for the event (Eg. User Disconnected, Max time exceeded) 

 

 

 

Network Tunnel Setup 

 

  • Reference Guides for Network Tunnel setup are found in Umbrella Network Tunnel docs.  This guide can be followed for creating either Secure Internet or Private Access tunnels. 

  • The docs focus on Secure Internet Tunnels, where all internet traffic is routed through the tunnel. 

  • For Private Access, tweak the Traffic Selector or Policy Based Routing configuration to route only the desired traffic via the tunnel.  Typically this would include the VPN pool destination ranges (configured in Deployments > Remote Access) 

  • If a tunnel is showing as “Not Established” (Deployments > Network Tunnels page) check the device has been configured using our supported IPsec paramters.   

  • If a tunnel is showing as “Inactive” ensure traffic is being generated which should be routed down the VPN.   

  • Be aware of Known Limitations with SLVPN tunnels.  In particular, we do not support path MTU discovery, and we only support one child SA per IPsec tunnel. 

  • Tunnels can be created on devices with are behind NAT, but there are specific requirements for the device that initiates the tunnel.   The device must support sending the VPN Peer ID in a specific format (“User FQDN” format).  Cisco ASA devices are not capable of this and cannot be used behind NAT 

  • For other troubleshooting, use the IPsec logs: 

  • From the network device initiating the tunnel 

  • From SLVPN DataDog (Link to TBA) 

 

 

Multiple Tunnels 

To configure an office for both Private Access (Allowing remote users in) and Secure Internet Access (for users physically in the office) you currently need TWO tunnels.  You cannot do this with a single tunnel.  Creating multiple tunnels from the same device is possible, but there are restrictions listed here.. 

 

  • Customers with Cisco ASA/FTD will need multiple public IP addresses to make multiple tunnels.  This is due to the previously mentioned limitation on how Cisco ASA sends the VPN Peer ID 

  • Other devices may be able to use a “User FQDN” as the peer ID address instead of their public IP. 

 

The customer will need to carefully configure their traffic selectors... 

 

  • Traffic destined for the VPN Pool is sent via the Private Access Tunnel 

  • Traffic destined for other (internet) destinations is sent via the Secure Internet tunnel 

 

 

Private Access 

Once a tunnel is established, the only configuration area to check in Umbrella is... 

 

  • The “Traffic Selector” associated with the tunnel in (Deployments > Network Tunnels) on the Umbrella Dashboard.  This must define the IP range(s) used on the private/office network 

  • The “Traffic” selector on the network device which initiates the tunnel.  This must include traffic where source=private IP range and destination=VPN Pool IP range. 

  • Umbrella Cloud Firewall and web filtering do not apply to private access traffic.  However, on-premise firewall rules still need to be accounted for. 

 

 

 

 

SIG 

No additional configuration is needed to for our Cloud Firewall and Secure Web Gateway to start processing requests.  This will happen automatically for both Remote Access users, and users connected to a Secure Internet tunnel. 

 

However, to enforce content or security blocks users need to follow these guides: 

https://docs.umbrella.com/umbrella-user-guide/docs/manage-firewall 

https://docs.umbrella.com/umbrella-user-guide/docs/manage-web-policies 

 

As a basic test of Secure Internet Gateway users can... 

 

  • The information on this page (such as org ID, origin ID) can be decoded in Umbrella’s internal BFG tool 

  • Alternatively, use an “IP test” site such as www.whatsmyip.org.  This can be used to test that internet traffic is egressing from Umbrella’s network 146.112.0.0/16 or 155.190.0.0/18 

 

Administrators can check the reporting in ‘Reporting > Activity Search’ to confirm that URL traffic and IP packets are being logged by our Secure Web Gateway and cloud firewall.  The below example shows the logging of a Firewall packet and a SWG URL request: 

 

 

A Web policy tester is available in the Umbrella Dashboard if content is unexpectedly blocked or allowed: 

https://docs.umbrella.com/umbrella-user-guide/docs/test-a-web-policy 

 

 

SIG Identities 

In CDFW/SWG policies and reporting are based on Identities.  All Remote Access users get the same identity (eg. Remote Access orgid:12345) by default.  When configuring a CDFW/SWG policy you can select this identity to make a policy which applies to your whole RA organization.   

Therefore it is not possible (using an out of the box configuration) to make policies for individual users, or see usernames in reports. 

  • SWG User-based identification of web traffic can theretically be added by enabling SAML in SWG Web Policies or using our AnyConnect SWG module.     

  • Firewall User-based identification is not possible in SIG or Frontizo 

 

.   

 

Client VPN Configuration / Split Tunneling 

This is all configured on the “Traffic Steering” tab in the Remote Access settings.   Sometimes it is necessary to exclude a destination from the tunnel for performance reasons or because of a conflict with Umbrella SIG. 

 

  • Steer traffic INSIDE the secure tunnel defines a list of addresses to be tunneled, and everything else is sent Direct to internet 

  •  Steer traffic OUTSIDE the secure tunnel defines a list of addresses to be sent direct to internet, and everything else is tunneled 

 

When steering INSIDE you must include all the IP ranges used on the customers’ private / office networks, along with anything else you wish to route through SIG. 

 

 

 

 

When steering OUTSIDE you effectively use this as an exclusion list of things that you don’t want to send down the tunnel. 

 

 

 

 

The user can confirm what settings have been delivered by clicking the Settings icon in the AC client UI.  This confirms the basics about whether Split Tunneling is in use. 

 

 

 

The “Route Details” tab can be used to learn which routes are secured (via tunnel) and non-secured (direct). 

 

 

 

In the case of “dynamic” (Domain based) tunnel exclusions/inclusions, AnyConnect automatically learns the IP address of these domains by sniffing network traffic.   The IP addresses will show in the Route Details page when learned.  More details: 

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215383-asa-anyconnect-dynamic-split-tunneling.html 

 

 

More details about the VPN configuration payload can be found in “Cisco AnyConnect Secure Mobility Client” event logs (Windows).  For example, Event ID 2080 shows the “Host” configuration payload including Private (include) and Public (exclude) networks.   

 

 

 

You can check the routing is correct by displaying the route table: 

 

 

 

Note – At time of writing dynamic (domain based) exclusions do not seem to be working. 

 

 

DNS 

When Private Access is used the customer almost definitely needs to add the address of one of their internal DNS servers for DNS (eg. Internal IP).  This is for when customer has an internal domain (eg. Something.local) which they need VPN clients to resolve. 

 

 

 

On a Windows client you can check the configured DNS using ipconfig /all 

 

 

 

Internal DNS 

 

Importantly the specified DNS server must be able to resolve ALL internal domains.  If the customer has multiple DNS servers and multiple DNS zones (eg. Zone1.local > 192.168.1.1, zone2.local > 192.168.2.1) there is no conditional forwarding available (within the Umbrella system) to forward those queries accordingly.  The customer will need to implement conditional forwarding on their primary DNS server.  You can test that the primary DNS server can resolve the necessary domains with simple nslookup commands: 

 

nslookup host.zone1.local 192.168.1.1 

nslookup host.zone2.local 192.168.2.1 

 

Failover  

 

It is possible to specify a secondary DNS server for failover purposes.  Most operating systems will only use the secondary if the primary is not responding, or is responding slowly.  The primary DNS server is still expected to be able to resolve everything you need. 

 

 

 

 

 

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 enforce a DNS policy by installing our Umbrella AnyConnect Roaming Module. 

 

User Provisioning 

Best to link to the Umbrella Docs: 

  • Was this article helpful?