Introduction This document answers frequently asked questions about Cisco's VPN Client solutions available on Mac OS X. The contents of this document have been moved, you should be able to find them here: VPN Clients For Mac OS X FAQ - Cisco Systems ... View more

  Q: The requirements for Trusted Network Detection (TND)/Always-On state that Anyconnect (AC) requires strict certificate checking, what is this?     http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/ac03vpn.html#wp1230383 A: Strict certificate checking means that AC will not establish a session if the certificate presented by the ASA cannot be verified.  The ASA's cert is presented to AC during the SSL negotiation part of the session establishment.  AC verifies that all the attributes of the received cert are valid and align with the AC Profile.  A good way to verify cert validity is to browse to the ASA's webvpn portal in your web browser.  If you don't see any warning messages than this certificate has been verified successfully.  But this isn't the only thing checked by AC, below are common problems surrounding strict cert checking.   Typical problems include: 1) Untrusted cert     Example       - ASA has self-signed certificate configured and this cert cannot be found in the CA Cert Store on the user's PC     Resolution    - Install a cert from a trusted third party CA or install the CA cert in the appropriate cert store of all client PCs.   2) Mismatched cert     Example       - AC/User browses to the IP addr of the ASA but the cert's Subject Name/Subject Alternative Name (SAN) contains the FQDN.      Resolution    - The HTTPS URL defined in the AC Profile and the cert's Subject Name/SAN must match.  Note that if the cert contains a SAN this will always take precedence over the subject name.  Important: This means the hostname defined in the server list section of the AC profile must match the cert SN/SAN!  Also worth noting: if you configure 'fqdn none' in the trustpoint the ASA won't insert a SAN attribute in the CSR.     3) Invalid cert     Example       - The certificate has expired.     Resolution    - The ASA admin must install a new certificate with a valid lifetime.     4) CRL not accessible     Example       - The CRL URL defined in the certificate attributes isn't resolveable or the CRL isn't accessible.     Resolution    - The CRL URL must be resolveable and the CRL must be available. Update DNS so this CRL's FQDN will resolve correctly on the internet.  Note: you should be able to browse to the URL defined in the cert attributes and pull down the CRL.     Q: I'm setting this up for the first time and I know that I have a configuration error in the AnyConnect Profile that is preventing me from connecting.  I've made a change to the profile but the PC is locked down and not passing any traffic out its NIC because TND was enabled in the previous profile pushed down.  How do I restore network access to this test machine in order to download the new profile from the ASA? A:  For testing you should be using a machine with administrative privileges.  The best way to recover from this state and start from scratch is to delete the AnyConnect Profile and Preferences XML files from the PC then uninstall AnyConnect.  This may require a reload of the PC, but after you log back in network connectivity will be restored and you'll be able to browse to the ASA.  Most of the time, however, by uninstalling the Profile and Preferences files and restarting the "Cisco AnyConnect Secure Mobility Agent" service in Windows (Control Panel > Admin Tools > Services) you can reinitialize the system.   Q: When I first downloaded the new profile I used weblaunch to establish my AC connection.  Now  that I have disconnected I can't reconnect, I continue to see an error indicating that AC cannot confirm it is connected to my secure gateway.  Even more confusing is the  fact that although I configured a "Fail Open" policy in the AC Profile  my computer doesn't have any network access.  What can I do? A:   First, make sure you've reviewed the question above regarding strict certificate checking - this is most likely causing your problem.  Second, the Fail Open versus Fail Closed policy is implemented after AC verifies a secure gateway and can successfully establish a connection to it.  In the case where AC cannot establish a connection to a secure gateway due to a local configuration issue, it already knows it's on an untrusted network (this is why it's attempting to initiate the connection) and so if the gateway isn't trusted it will deny all network connectivity until a gateway is trusted.  After AC can successfully build a tunnel to a trusted gateway it will Fail Open or Fail Closed depending upon the settings configured in the AC Profile.     Q: I'm troubleshooting to figure out what I'm still missing and in the AnyConnect Event Logs I am seeing a message stating that Enhanced Key Usage (EKU) is invalid.  What does this mean and is this causing my problem? A: This is a client-side message indicating that AnyConnect was unable to find a certificate in the local store to present to the ASA.  If you are not using certificate authentication you can safely ignore this message.  If you are using certificate authentication the client-side certificate's certificate must contain the EKU attribute for Client Authentication.     Q:  In the AC Profile I have disabled the ability for users to use the disconnect button, but users are still able to press "disconnect" and it will log them on/off of AnyConnect.  Should this be possible? A: This is expected behavior if the users is on a trusted network.  TND will not affect the users' ability to connect/disconnect on a trusted network, only when users are not on the trusted network should this button be grayed out.   Q:  Does the <TrustedDNSDomains> field in the AC Profile support wildcard characters? A: Yes, the asterick can be used.  For example, if you want to trust users on any network containing one of the many domains you own including companyA.com, companyAsupport.com, companyAinvestors.com, companyA.net, companyA.org, and customers.companyA.com, you could simply add the tag <TrustedDNSDomains>*companyA*</TrustedDNSDomains>.   Q:  What protocols are allowed outbound from a host when Always-On is in FAILED CLOSED mode and captive portal remediation is not permitted? A: ARP, DNS, DHCP, connectivity to the secure GW IP. Plus access to any other profile hosts in 3.0, in 3.1 dynamically defined SG list based on only to host you are actually connected to.   Q: Will Always On work through a Proxy? A: No. If a proxy is required to get to the internet, Always On will not support this. This includes any type proxy setting (wheter it's a PAC, a proxy set in browser, etc). This was designed to maintain security with the feature. Had we allowed this w Always On we would have needed to add a route to the proxy and if that were the case they could get anywhere, hence, bypassing always on access to only the ASA. With AlwaysOn configured, the Agent will always attempt to create the tunnel directly to the ASA and will not even attempt to connect to the proxy. Since we don't support connecting via a proxy, we at least try to connect directly rather than not try at all and just fail outright. If the Agent is unable to connect to the ASA, then the Agent will report to the user the connection is not possible because it must be made via a proxy which is not supported with AlwaysOn. So setting IgnoreProxy should not be necessary when AlwaysOn is enabled because the Agent will not attempt to connect via the proxy at all.   Q: Will Always-On work with Self-Signed Certificates? A: You can use self-signed certificates with Always-On. But, you have to be careful with the usage of the “Hostname” and “Host Address” fields in the server list: 1. If you only specify the Hostname field, and not the Host Address field, then the entry of the Hostname field will be compared with the certificate subject. If they do not match, and the Always-On feature is enabled, the VPN connection will fail. 2. If you specify both the Hostname field and the Host Address field, then the entry of the Host Address field will compared with the certificate subject. If they do not match, and the Always-On feature is enabled, the VPN connection will fail.   +++++ You can add the ASA certificate to the PCs Trusted Root store (see the last line from the Admin guide below). However, you may need to do that BEFORE Always-On is enabled or at least reboot after doing it. To add the Cert, open Internet Explorer and got to the ASA. You should get a message that there is a problem with the website’s certificate. Then follow the steps in this article, which describes the process but for a different product http://blogs.technet.com/b/sbs/archive/2007/04/10/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista.aspx http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/ac03vpn.html#wp1205144 •Always-on VPN requires a valid server certificate configured on the ASA; otherwise, it fails and logs an event indicating the certificate is invalid. Ensure your server certificates can pass strict mode if you configure always-on VPN. Always-on VPN supports only computers running Microsoft Windows 7, Vista, XP; and Mac OS X 10.6, 10.7 and 10.8. To prevent the download of an always-on VPN profile that locks a VPN connection to a rogue server, the AnyConnect client requires a valid, trusted server certificate to connect to a secure gateway. We strongly recommend purchasing a digital certificate from a certificate authority (CA) and enrolling it on the secure gateways. If you generate a self-signed certificate, users connecting receive a certificate warning. They can respond by configuring the browser to trust that certificate to avoid subsequent warnings.   Q: What are the checks done against certificates in case of always on? This can cause multiple problems with always on including failure to download updates - FILEDOWNLOADER_ERROR_UNTRUSTED_CERTIFICATE_WITH_ALWAYS_ON A: The checks are performed through WinInet library here's a non exhaustive list: - The certificate's trust chain verifies back to a trusted root - The certificate is not expired or not yet valid based on date - The host being used for the connection matches a CN entry in the Subject or a DNSName or IPAddress entry in the Subject Alternative Name entry within the certificate, as appropriate - If present, the certificate's Key Usage is appropriate for the required tasks (typically Digital Signature and Key Encipherment for SSL) - If present, the certificate's Enhanced Key Usage is appropriate for the required tasks (Server Authentication) - The certificate is not revoked ... View more