Within the DART CLI, you can display the client's unique device identifier (UDID). For example, with Windows, go to the folder containing dartcli.exe (C:\Program Files\Cisco\Cisco Secure Client) and enter dartcli.exe -u or dartclie.exe -udid.

If you have an install or uninstall failure with Cisco Secure Client, you need to collect logs, because the DART collection does not have diagnostics for this.

Run the msiexec command in the same directory where you unzipped Cisco Secure Client files:

• For install failures, enter

  C:\temp>msiexec \i cisco-secure-client-win-version-predeploy-k9.msi \lvx c:\Temp\ac-install.log?

  where c:\temp\ac-install.log? can be a filename of your choice.
• For uninstall failures, enter

  c:\temp>msiexec \x cisco-secure-client-win-version-predeploy-k9.msi /lvx c:\Temp\ac-uninstall.log?

  where c:\temp\ac-uninstall.log? can be a filename of your choice.

Note	For uninstall failures, you should use the MSI specific to the version currently installed.

You can alter the same commands above to capture information about any module on Windows which is not installing or uninstalling correctly.

The logs are retained in the following files:

• Windows—\Windows\Inf\setupapi.app.log or \Windows\Inf\setupapi.dev.log

  Note	In Windows, you must make the hidden files visible.

  Because the deployment is manual, you can choose to download the installer file on the web portal and assign your own log filename.

  .

  If an upgrade was pushed from the gateway, the log file is in the following location:

  %WINDIR%\TEMP\cisco-secure-client-win-<version>-core-vpn-webdeploy-k9-install-yyyyyyyyyyyyyy.log.

  Obtain the most recent file for the version of the client you want to install. The xxx varies depending on the version, and the yyyyyyyyyyyyyy specifies the date and time of the install.

• macOS (10.12 and later)—the logging database; use Console app or log command to query logs for VPN, DART, or Umbrella

• macOS (legacy file based log)—/var/log/system.log for all other modules

• Linux Ubuntu—/var/log/syslog

• Linux Red Hat—/var/log/messages

Problem: Cisco Secure Client will not establish initial connection, or you get unexpected results when you click Disconnect on the Cisco Secure Client window.

Solution: Check the following:

• You can experience intermittent connectivity issues because the network or WiFi adapter drivers are ooutdated. Upgrade those drivers and retry.

• If you are using Citrix Advanced Gateway Client Version 2.2.1, remove the Citrix Advanced Gateway Client until the CtxLsp.dll issue is resolved by Citrix.

• If you are using AT&T Communication Manager Version 6.2 or 6.7 with an AT&T Sierra Wireless 875 card, follow these steps to correct the problem:

  1. Disable acceleration on the Aircard.
  2. Launch AT&T communication manager > Tools > Settings > Acceleration > Startup.
  3. Type manual.
  4. Click Stop.

• Obtain the config file from the Secure Firewall ASA to look for signs of a connection failure:

  • From the Secure Firewall ASA console, type write net x.x.x.x:ASA-Config.txt, where x.x.x.x is the IP address of the TFTP server on the network.

  • From the Secure Firewall ASA console, type show running-config. Cut and paste the config into a text editor and save.

• View the Secure Firewall ASA event logs:

  1. At the Secure Firewall ASA console, add the following lines to look at the ssl, webvpn, anyconnect, and auth events:

     
     config terminal
     logging enable
     logging timestamp
     logging class auth console debugging
     logging class webvpn console debugging
     logging class ssl console debugging
     logging class anyconnect console debugging
     

  2. Attempt connection to Cisco Secure Client, and when the connect error occurs, cut and paste the log information from the console into a text editor and save.

  3. Type no logging enable to disable logging.

• Obtain the Cisco Secure Client log from the client computer using the Windows Event Viewer.

  1. Choose Start > Run and type eventvwr.msc /s.
  2. Locate the Cisco Secure Client in the Applications and Services Logs (of Windows 7) and choose Save Log File As...
  3. Assign a filename, for example, CiscoSecureClientLog.evt. You must use the .evt file format.

• Modify the Windows Diagnostic Debug Utility.

  1. Attach the vpnagent.exe process as shown in the WinDbg documentation.
  2. Determine if there is a conflict with the IPv6/IPv4 IP address assignments. Look in the event logs for any idenfied conflicts.

  3. If a conflict was identified, add additional routing debugs to the registry of the client computer being used. These conflicts may appear in the Cisco Secure Client event logs as follows:

     
     Function: CRouteMgr:modifyRoutingTable Return code: 0xFE06000E File: .\VpnMgr.cpp Line:1122
     Description: ROUTEMGR_ERROR_ROUTE_TABLE_VERIFICATION_FAILED.
     Termination reason code 27: Unable to successfully verify all routing table modifications are correct.
     
     Function: CChangeRouteTable::VerifyRouteTable Return code: 0xFE070007
     File: .\RouteMgr.cpp Line: 615 Description: ROUTETABLE_ERROR_NOT_INITIALIZED
     gr.cpp Line: 615 Description: ROUTETABLE_ERROR_NOT_INITIALIZED
     

  4. Enable route debugging on a one-time basis for a connection by adding a specific registry entry (Windows) or file (Linux and macOS).

     • On 32-bit Windows, the DWORD registry value must be HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\Cisco Secure Client\DebugRoutesEnabled


     • On 64-bit Windows, the DWORD registry value must be HKEY_LOCAL_MACHINE\Software\WOW6432node\Cisco\Cisco Secure Client\DebugRoutesEnabled 


     • On Linux or macOS, create a file in the following path using the sudo touch command: /opt/cisco/secureclient/vpn/debugroutes

     Note

     The key or file is deleted when the tunnel connection is started. The value of the key or content of the file is not important as the existence of the key or file is sufficient to enable debugging. Start a VPN connection. When this key or file is found, two route debug text files are created in the system temp directory (usually C:\Windows\Temp on Windows and /opt/cisco/secureclient/vpn on macOS or Linux). The two files (debug_routechangesv4.txt4 and debug_routechangesv6.txt) are overwritten if they already exist.

Problem: Cisco Secure Client cannot send data to the private network once connected.

Solution: Check the following:

• If you are using AT&T Communication Manager Version 6.2 or 6.7 with an AT&T Sierra Wireless 875 card, follow these steps to correct the problem:

  1. Disable acceleration on the Aircard.
  2. Launch AT&T communication manager > Tools > Settings > Acceleration > Startup.
  3. Type manual.
  4. Click Stop.

• Obtain the output of the show vpn-sessiondb detail anyconnect filter name <username> command. If the output specifies Filter Name: XXXXX, get the output for the show access-list XXXXX command as well. Verify that the ACL is not blocking the intended traffic flow.

• Obtain the DART file or the output from Cisco Secure Client > Statistics > Details > Export (AnyConnect-ExportedStats.txt). Observe the statistics, interfaces, and routing table.

• Check the Secure Firewall ASA config file for NAT statements. If NAT is enabled, you must exempt data returning to the client from network address translation. For example, to NAT exempt the IP addresses from the Cisco Secure Client pool, the following code would be used:

  
  access-list in_nat0_out extended permit ip any 10.136.246.0 255.255.255.0
  ip local pool IPPool1 10.136.246.1-10.136.246.254 mask 255.252.0.0
  nat (inside) 0 access-list in_nat0_out
  

• Verify whether the tunneled default gateway is enabled for the setup. The traditional default gateway is the gateway of last resort for non-decrypted traffic:

  
  route outside 0.0.209.165.200.225
  route inside 0 0 10.0.4.2 tunneled
  

  If a VPN client needs to access a resource that is not in the routing table of the VPN gateway, packets are routed by the standard default gateway. The VPN gateway does not need to have the whole internal routing table. If you use a tunneled keyword, the route handles decrypted traffic coming from IPsec/SSL VPN connection. Standard traffic routes to 209.165.200.225 as a last resort, while traffic coming from the VPN routes to 10.0.4.2 and is decrypted.

• Collect a text dump of ipconfig /all and a route print output before and after establishing a tunnel with Cisco Secure Client.

• Perform a network packet capture on the client or enable a capture on the Secure Firewall ASA.

  Note

  If some applications (such as Microsoft Outlook) do not operate with the tunnel, ping a known device in the network with a scaling set of pings to see what size gets accepted (for example, ping -| 500, ping -| 1000, ping -| 1500, and ping -| 2000). The ping results provide clues to the fragmentation issues in the network. Then you can configure a special group for users who might experience fragmentation and set the anyconnect mtu for this group to 1200. You can also copy the Set MTU.exe utility from the old IPsec client and force the physical adapter MTU to 1300. Upon reboot, see if you notice a difference.

Problem: You receive an “Unable to Proceed, Cannot Connect to the VPN Service” message. The VPN service for Cisco Secure Client is not running.

Solution: Determine if another application conflicted with the service. See Determine What Conflicted With Service, page 11-7.

Problem: If you recently updated the Microsoft certclass.inf file, the following message is encountered when trying to establish a VPN connection:

The VPN client driver has encountered an error.

If you check the C:\WINDOWS\setupapi.log, you can see the following error:

#W239 The driver signing class list “C:\WINDOWS\INF\certclass.inf” was missing or invalid. Error 0xfffffbf8: Unknown Error. Assuming all device classes are subject to driver signing policy.

Solution: Check which updates have recently been installed by entering C:\>systeminfo at the command prompt or checking the C:\WINDOWS\WindowsUpdate.log. Follow the instructions to repair the VPN driver.

Problem: VPNVA.sys driver crashes.

Solution: Find any intermediate drivers that are bound to the Cisco Secure Client Virtual Adapter and uncheck them.

If the Network Access Manager fails to recognize your wired adapter, try unplugging your network cable and reinserting it. If this does not work, you may have a link issue. The Network Access Manager may not be able to determine the correct link state of your adapter. Check the Connection Properties of your NIC driver. You may have a "Wait for Link" option in the Advanced Panel. When the setting is On, the wired NIC driver initialization code waits for auto negotiation to complete and then determines if a link is present.

Problem: You received a “the system has recovered from a serious error” message after a reboot.

Solution: Gather the .log and .dmp generated files from the %temp% directory (such as C:\DOCUME~1\jsmith\LOCALS~1\Temp). Copy the files or back them up. See How to Back Up .log or .dmp Files, page 11-9.

Problem: When Cisco Secure Client attempts to establish a connection, it authenticates successfully and builds the ssl session, but then it crashes in the vpndownloader if using LSP or NOD32 AV.

Solution: Remove the Internet Monitor component in version 2.7 and upgrade to version 3.0 of ESET NOD32 AV.

Problem: If you are using an AT&T Dialer, the client operating system sometimes experiences a blue screen, which causes the creation of a mini dump file.

Solution: Upgrade to the latest 7.6.2 AT&T Global Network Client.

Problem: A security alert window appears in Microsoft Internet Explorer with the following text:

Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate. The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.

Solution: This alert may appear when connecting to a Secure Firewall ASA that is is not recognized as a trusted site. To prevent this alert, install a trusted root certificate on a client. See Install Trusted Root Certificates on a Client, page 11-10.

Problem: A “Web Site Certified by an Unknown Authority” alert window may appear in the browser. The upper half of the Security Alert window shows the following text:

Unable to verify the identity of <Hostname_or_IP_address> as a trusted site.

Solution: This security alert may appear when connecting to a Secure Firewall ASA that is not recognized as a trusted site. To prevent this alert, install a trusted root certificate on a client. See Install Trusted Root Certificates on a Client, page 11-10.

Problem: When wireless suppression is enabled on an Odyssey client, the wireless connection drops if a wired connection is introduced. With wireless suppression disabled, the wireless operates as expected.

Solution: Configure the Odyssey Client, page 11-11.

Problem: When Kaspersky 6.0.3 is installed (even if disabled), Cisco Secure Client connections to the Secure Firewall ASA fail right after CSTP state = CONNECTED. The following message appears:

SVC message: t/s=3/16: Failed to fully establish a connection to the secure gateway (proxy authentication, handshake, bad cert, etc.).

Solution: Uninstall Kaspersky and refer to their forums for additional updates.

Problem: When using McAfee Firewall 5, a UDP DTLS connection cannot be established.

Solution: In the McAfee Firewall central console, choose Advanced Tasks > Advanced options and Logging and uncheck the Block incoming fragments automatically checkbox in McAfee Firewall.

Problem: If you are using RRAS, the following termination error is returned to the event log when Cisco Secure Client attempts to establish a connection to the host device:

Termination reason code 29 [Routing and Remote Access service is running]
The Windows service “Routing and Remote Access” is incompatible with the Cisco Secure Client.

Solution: Disable the RRAS service.

Problem: The connection fails due to lack of credentials.

Solution: The third-party load balancer has no insight into the load on the Secure Firewall ASA devices. Because the load balance functionality in the ASA is intelligent enough to evenly distribute the VPN load across the devices, we recommend using the internal Secure Firewall ASA load balancing instead.

If you are receiving a failure while installing, uninstalling, or upgrading Cisco Secure Client, we do not recommend modifying the Windows Installer registry keys directly, because it can lead to undesired consequences. Microsoft-provided tools can troubleshoot installer issues after proper root cause is determined.

Problem: Cisco Secure Client fails to download and produces the following error message:

“Cisco AnyConnect VPN Client Downloader has encountered a problem and needs to close.”

Solution: Upload the patch update to version 1.2.1.38 to resolve all dll issues.

With the deprecation of IE11, Secure Client embedded browser defaults to WebView2, as long as the runtime is installed. If you need to revert back to the legacy embedded browser control, add a DWORD registry value UseLegacyEmbeddedBrowser set to 1 to the following Windows registry key:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Cisco\Cisco Secure Client

Problem: If you are using Bonjour Printing Services, the Cisco Secure Client event logs indicate a failure to identify the IP forwarding table.

Solution: Disable the BonJour Printing Service by typing net stop “bonjour service” at the command prompt. A new version of mDNSResponder (1.0.5.11) has been produced by Apple. To resolve this issue, a new version of Bonjour is bundled with iTunes and made available as a separate download from the Apple web site.

Problem: An error indicates that the version of TUN is already installed on this system and is incompatible with the Cisco Secure Client.

Solution: Uninstall the Viscosity OpenVPN Client.

Problem: If an LSP module is present on the client, a Winsock catalog conflict may occur.

Solution: Uninstall the LSP module.

Problem: Slow data throughput may occur with the use of NOD32 Antivirus V4.0.468 x64 using Windows.

Solution: Disable SSL protocol scanning. See Disable SSL Protocol Scanning.

Problem: If you are using a EVDO wireless card and Venturi driver while a client disconnect occurred, the event log reports the following:

%ASA-5-722037: Group <Group-Name> User <User-Name> IP <IP-Address> SVC closing connection: DPD failure.

Solution:

• Check the Application, System, and Cisco Secure Client event logs for a relating disconnect event and determine if a NIC card reset was applied at the same time.

• Ensure that the Venturi driver is up to date. Disable Use Rules Engine in the 6.7 version of the AT&T Communications Manager.

Problem: If you are connecting with a DSL router, DTLS traffic may fail even if successfully negotiated.

Solution: Connect to a Linksys router with factory settings. This setting allows a stable DTLS session and no interruption in pings. Add a rule to allow DTLS return traffic.

Problem: When attempting to retrieve operating system information on the computer’s network used to make the SSL connection, the Cisco Secure Client log may indicate a failure to fully establish a connection to the secure gateway.

Solution:

• If you are uninstalling the Integrity Agent and then installing Cisco Secure Client, enable TCP/IP.

• Ensure that if you disable SmartDefense on Integrity agent installation, TCP/IP is checked.

• If third-party software is intercepting or otherwise blocking the operating system API calls while retrieving network interface information, check for any suspect AV, FW, AS, and such.

• Confirm that only one instance of the Cisco Secure Client adapter appears in the Device Manager. If there is only one instance, authenticate with Cisco Secure Client, and after 5 seconds, manually enable the adapter from the Device Manager.

• If any suspect drivers have been enabled within the Cisco Secure Client adapter, disable them by unchecking them in the Connection window of Cisco Secure Client.

Problem: When using Cisco Secure Client on some Virtual Machine Network Service devices, performance issues have resulted.

Solution: Uncheck the binding for all IM devices within the Cisco Secure Client virtual adapter. The application dsagent.exe resides in C:\Windows\System\dgagent. Although it does not appear in the process list, you can see it by opening sockets with TCPview (sysinternals). When you terminate this process, normal operation of Cisco Secure Client returns.