Welcome to the Cisco Support Community Ask the Expert conversation. Learn from Cisco expert Rahul Govindanto how to configure and troubleshoot the various AnyConnect client features including features using Anyconnect xml profiles such as Start Before Logon (SBL), on-connect scripting, certificate authentication etc as well as specific features on the Adaptive Security Appliances (ASA) such as Cisco Secure Desktop (CSD) /Hostscan and Dynamic access policies (DAP).
Rahul Govindan has been an engineer with the Security Technical Assistance Center team in Bangalore for more than three years. He works on security technologies such as VPN, Cisco Adaptive Security Appliance firewalls, and authentication authorization & accounting. His particular expertise is in Secure Sockets Layer VPN and IP Security VPN technologies. He holds CCIE certification (#29948) in the Security domain.
Remember to use the rating system to let Rahul know if you have received an adequate response.
Rahul might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community discussion forum shortly after the event. This event is a continuation of the facebook forum and lasts through April 27 2012. Visit this forum often to view responses to your questions and the questions of other community members.
Hello Rahul Govindan,
please can you indicate when the BUG ID: CSCty32412 will be resolved (is there any specific release that resolve the problem) ?
Unfortunately, this bug has not been fixed so far at our end and I do not have an estimated date for a fix yet. But this bug is being worked upon on a very high priority as it a highly impacting one for anyconnect deployments.I shall provide you more information on this forum if I obtain any. In the meanwhile, I would suggest that you subscribe to the bug on the Bug Toolkit page so that you receive notifications on any changes in the state of the bug.
Thanks for the reply.
Another question related to cisco asa bugs: about the Cisco ASA 8.x and Dynamic access policies (DAP) with LDAP integration with Microsoft Active Directory
and the ability to permit remote access users access the resources that are defined for 2 different active directory groups at the same time:
please can you indicate me if the following Bug ID: CSCso24147 will be resolved/implemented (it's an
enhancement but other firewall vendor support already this fetaure) ?
Ah, this bug This has been a long standing enhancement at our end to have a recursive check for LDAP nested groups on the AD. Unfortunately, I do not have a timeline for the support for this enhancement. But I do know that this is one of the top priority bugs on the ASA teams list. I wish I had more information to provide you.
Looks like this bug has been resolved and the fixed images should be 8.2.5(29) and 8.4.4 both of which should be out shortly.
Hello Rahul Govindan,
about the SSL (anyconnect) feature on cisco ASA please can you answer to the following question:
1) The problem:
The Hacker's Choice SSL Denial of Service (thc-ssl-dos) tool.
Attackers can use this tool to exhaust resources on an SSL-enabled service, causing a Denial of Service of the targeted service.
The tool is a public Tool and not a Cisco one.
The researchers publish the tool and the technical details at http://www.thc.org/thc-ssl-dos THC released an SSL denial of service (DoS) tool that performs a resource starvation attack of SSL servers.
This problem affects all SSL implementations today. Vendors are aware of this problem since 2003 and the topic has been widely discussed within IETF. This tool also appears to leverage the known issue described in CVE-2011-1473.
Technical details can be found at:
The following blog also covers the effects of this attack:
An Intellishield alert has been published to document this at:
2) Cisco indicate:
"To mitigate the DoS condition administrators are advised to use SSL Accelerators within the network and disable the SSL Secure Renegotiation feature on affected servers."
It's work even without SSL renegotiation enabled, attackers can still use THC-SSL-DOS successfully against servers.
AND THE HOWTO MITIGATE with CISCO:
using CISCO IPS:
customers are asking me if
- Cisco ASA SSL is vulnerable to the attack ?
- Are there any configuration within Cisco ASA to mitigate the problem or it is necessary to deploy the CISCO IPS ?
I was looking more into this vulnerability that you mentioned all morning. From what I read, the tool can cause vulnerabilities when the ssl renegotitation is enabled . If I am not wrong, the ASA has disabled SSL renegotiation with a patch in the Openssl code due to an earlier TLS vulnerabilty noted. The bug ID is the following
CSCtd00697. Looks like the ASA running the 8.2(1.16) codes and above should not have this vulnerability for its SSLVPN services.
More information on this can be obtained here:
as indicated by http://www.thc.org/thc-ssl-dos/
It still works if SSL Renegotiation is not supported but requires some modifications and more bots before an effect can be seen.
People are asking us about the private release that works against servers
that do not support SSL renegotiation. We will not release it.
Meanwhile the good news is that openssl can be used to perform the same attack
It's not as elegant as the private thc-ssl-dos but works quite well indeed.
please can you check @ Cisco (maybe with PSIRT) if the IPS is needed ?
Thanks again for all the support.
I guess what they mean by an attack without SSL renegotiation is a normal TCP syn flood attack using SSL packets. I guess the primary target for this tool was meant for web servers with SSL renegotiation enabled and thats why the PSIRT response is for IPS devices inline to the servers that it was targetting. So far there is no vulnerability that has been noted by the PSIRT team for this tool on the ASA so my assumption would be that the ASA should not be vulnerable to these attacks. But again let me see if I can find some more info for you on this query.
I have problems configuring Anyconnect client 2.5 with Certificate in my ASA 5520 (8.2.1), I have succesfully configure the anyconnect without Certificate. We have an internal Windows 2003 CA server where we generate the identity certificate. As a CN we use the name of ASA. We also enroll client certificate from the same CA server and as a CN we use Laptop's number. The OU of the ASA and Laptop ceirtificate is the same.
We have also intalled root certificate on both devices. When we try to connect we have the message "Apr 20 2012 17:43:24: %ASA-4-313005: No matching connection for ICMP error message: icmp src outside:x.x.x.x dst identity:x.x.x.x(type 5, code 0) on outside interface. Original IP payload: tcp src x.x.x.x/443 dst x.x.x.x/54281". Can you help me? I can send you, if you want, the configuration in order to check it.
So just to re-state the problem: You are unable to connect to the ASA using Anyconnect with certificate authentication but you are able to do so with aaa authentication. A few more details,what is the message that pops up on the Anyconnect gui when you try connect and fails, say for example "Certificate Validation Failure"? Also, a test would be to see if you are facing the same failure when you try to connect to the ASA using a web brower (clientless login). From the config, it looks like you have configured the certificates right. Now in order to confirm if the right cert is getting selected for authentication, another help would be to run "debug cry ca 255" on the ASA when the client tries to connect. I think these tests would be a good way to start looking into the problem. Let me know what you see from these tests.
I have created 3 Connection profiles in the ASA, 2 with aaa authentication and 1 with aaa authentication and certificate. When i am trying to connect from laptop's Annyconnect client i see only the 2 connection profiles which are requiried only aaa authentication. So with anyconnect cilent i cannot see the connection profiloe with the certificate and aaa.
I had tried from the web browser and there i can saw the Connection Profile (aaa & certificate) and the error message that i was "Certificate Validation Failure".
Also i had run the command "debug cry ca 255" but the only message in the log files was the one i wrote in my original post. The only thing that i am not sure that i have tried is to enable the "debug cry ca 255" and try to connect from the web browser, i will try it again tommorow and i will inform you for the results.
Do you think that is useful to try something else?
When you say you don't see that aaa+cert tunnel group, do you mean that it is not present as a one of the options to select from a drop down list when connecting through AC client? Could you check if the tunnel-group has an Alias configured? If it does not have one, it will not show up as list of profiles to choose from.
Also it would be good to see any debugs that come across from the debug crypto ca output when you connect from the web page. Let me know if you have tested that.
Yes you are correct, the aaa+cert tunnel group, it is not presented as a one of the options to select from a drop down list when connecting through AC client while is presented when i am trying to connect through web.
Yes there is an Alias configured and the strange is that when i remove from ayuthenticationcertificate and try to connect with AC client the option was available in the drop down list.
In order to take the logs from command "debug cry ca 255" i have to enable "logging buffered debugging" am i correct? CPU usage of ASA is 20%, do you think that i will have a problem if i enable it?
I guess the reason you are not seeing the drop down yet is because you are failing certificate authentication and thus it never gets to the stage where it prompts you for the password. So I think the problem lies in the certificate authentcation stage for the connection. Could you post a snippet of your tunnel-group and group-policy to confirm?
The debug should only come up when the certificate is trying to authenticate so should not be too intensive to the ASA. You should probably see this message if it works:
CRYPTO_PKI: Certificate validation: Successful
This is the configuration
tunnel-group ANYCONNECT_GP_CERT type remote-access
tunnel-group ANYCONNECT_GP_CERT general-attributes
tunnel-group ANYCONNECT_GP_CERT webvpn-attributes
authentication aaa certificate
group-alias ANYCONNECT_GP_CERT enable
group-policy ANNYCONNECT_CP_CERT internal
group-policy ANNYCONNECT_CP_CERT attributes
vpn-tunnel-protocol svc webvpn
group-lock value ANYCONNECT_GP_CERT
address-pools value iPhoneGrp
Do i have to enable "logging buffered debugging" in order to see logs from command "debug cry ca 255"?
Config looks good. If you are on a terminal session, it should show up with terminal monitor enabled. You might just want to turn off logging monitor in case you have a large number of syslogs turning up.
please can you indicate when Cisco AnyConnect client allows native IPv6 VPN connections ?
As I kwon access to IPv6 resources is now done over a public IPv4 connection.
Native ipv6 connection support for Anyconnect should be from the 3.1 release onwards. This release should be available on CCO post July (tentative).
Perfect timing for me. I've recently had the Anyconnect SSL VPN pushed on me. I write down questions as they come up and when I have time I research them. This is a great opportunity to get some knocked off the list. The majority of my questions seem focused around dual-factor authentication using user certificates. I'd love to never use them again! Thank you for the time.
1. When we have multiple client authentication certificates installed in either the computer or user personal folder Anyconnect doesn't prompt for a certificate selection. If we hit the head-end through the browser we are prompted to select any of the client authentication certificates installed.
-Where and What do I modify in some xml file to enable certificate selection using the Anyconect client?
2. When using Windows 7 in a domain we've noticed when installing client authentication certificates into the a users personal folder can create problems. When the user is force to change their password (not when user initiated) the client certificate used in the dual-factor authentication fails. If this same certificate was installed in the machine personal certificate store, when passwords are forced to be changed the certificate continues to be accessible and used.
-Whats up with that? Have you seen any TAC cases like this?
3.So far I've been lucky and all the ASA's I've had to configure I've been able to use the local CA with signed certs. In the future I see this changing. When I use a Certificate Authority (say Thawte) they will issue an ID cert based off my public IP. Now when I go to generate the user certs, for dual-factor authentication will I still need to create a local ca to authenticate the users certs? Correct? Or do I issue client certs off the certificate issued from the Thawte Certificate?
4. Is their a debug document (with a signal flow chart (that would be sweet)) that shows every interaction when using dual-factor authentication with the local CA?
5. When you mentioned debug crypto ca 255. I began to wonder about the different levels when choosing debug. Should 255 be used with most debug commands?
6. When deploying Anyconnect to mobile devices (Android or Apple IOS) are their any gotchas one should look out for?
-an example from a recent experience I'll give is, when using an Apple device if your importing the ASA head-end ID cert. it has to be in der encoding. I eventually found this in a Cisco Doc and used openssl to convert it.
Those are all for now. Thanks for taking the time.
Thanks for your questions. Answers posted below:
1. Yes, you need a setting in the client profile to achieve this and it Automatic certificate Selection is enabled by default (you wont be prompted). In order to change this, check the Disable Automatic Certificate selection option under the Preferences (Part2) section on the ASDM profile editor. The xml tag for the same is
2. Frankly, I haven't seen this sort of issue before. But a few questions I do have. How did you know the password had to be changed, did any logs come up on the ASA? And at point during the connection did it fail, after you entered uname and passwd? And what aaa server did you use?
3. Now the CA servers for the client and server need not be the same for authentication. Each side does the validation of the peer certificate independently. So if you use Thwate for the ASAs certificate and local CA server for clients, the clients will be able to validate the ASA cert because it already has the Thwate root certs in its cert store (for most public CAs) and the ASA wil be able to validate the clients cert because it has the root cert that you created when you enabled the LOCAL CA feature. So this is most definately possible. Most common deployments have internal CAs generating client certs and a public cert for the ASA from a well known CA. In the case of SSL, Local CA server serves as a good substitute for internal CA server.
4. Unfortunately there isn't one. But I will soon be posting a doc on pki on CSC, where I will cover details on certificate and dual factor authentication also. For now this document will help to understand a bit more on the dual factor auth process
5. I had this question long ago So basically the levels are different for different commands. But in most cases the debug level 255 gives you the most detailed ( sometimes packet dumps ) . I would not recommend you to run 255 levels for all commands because in many case you probably would end up having too many debugs which doesn make sense. I would say a level of 11 should suffice in most cases (any value between 11-254 is the same level for most debugs)
6. You might want to check out the details on devices supported for Android, coz there are a few which aren't supported. Also there was an issue with certificates not visible on the apple Anyconnect store in a recent app release. But I believe that should be fixed in the latest release. So you might just want to make sure everyone is one the new release for Anyconnect. Othere than these, there is nothing that is a major standout in these devices for Anyconnect. But again, with changes made to devices and OS, there might be issues as some of these changes don't go well with the Anyconnect app.
Thanks for answering my questions. About question 2.
2. It was a situation where the customer needed it to work and they didn't care about me understanding why it wasn't working. I made it work as described, just installing the certs on the machine store. I have no logs, but I could probably reproduce problem. I'll run through the scenario.
I login to a laptop with a user account (say Newt). I setup the laptop with Anyconnect. The ID cert goes into users Trusted Root folder and the user certificate went into users Personal folder. They open Anyconnect and get their group pre-populated (because it has checked for the user cert) and they can log in. I close out Anyconnnect and logout. I login as admin and go to users I then force the user (Newt) to change their password on next login. I log out and login (as Newt) and the have to change the password on next login. I change the password and have the desktop. I then open Anyconnect. My group is not pre-populating indicating my user certificate is not being located from my personal folder. I try to login, but the prompt is just returned with no error message. If I went through the process and reinstalled the user cert with the OTP it works.
7. I've noticed Anyconnect 3.0 seems more independent than 2.5 when it comes to IE settings. For example if you don't have Use SSL 3.0, TLS 1.0, TLS 1.1 or TLS 1.2 selected in the Advanced Tab of IE you can still connect using TLSv1 if your running Anyconnect 3.0. If you were running Anyconnect 2.5 you get a message in Anyconnnect indicating “Connection attempt failed. Please try again.”
-is Anyconnect 3.0 completely independent of IE settings?
8. When you are working any Anyconnect problem connecting to the VPN head end and it's a couple of machines, but not the majority. How do you organize your troubleshooting? Are you best serve by mastering the understanding of what a good connection looks like in the event logs?
2. Now I am able to understand the issue better. But unfortunately I haven't seen this issue before .It would be interesting to see if the AC is able to access the user certificate store after the password change. A good way to start troubleshooting is we can disable auto Cert selection and if we are getting any certs back at all. Also another step would be to try the same with the machine store on the laptop and see if we are still not able to detect the cert. IMHO, even with passwd change, there should be no restriction in cert access on any store. If you still have access to the setup , it would be good to open up a TAC case on this issue.
7. Yes. I believe this behavior has changed with the bug CSCtk08899. During the vpn connection process, there are multiple ssl sessions open (you probably would have noticed multiple cert prompts when using untrusted certs) and one of the them is the one for vpn downloader where checks are made to see if there is any change in image/xml file etc. Now this connection required the IE settings that you mentioned and hence the failure. These settings are used as default as a part of the downloader process using Anyconnect connection with the 3.0 client (basically forces its use).
8. Good question. We do get a lot of issues where only few (sometimes even just one ) machines are affected. Now a good step always to go by with the DART of the working vs the non-working machine. In most cases, its usually when the end user installs certain applications or makes specific changes to the settings. The best way to understand what a good connection is to go through the Anyconnect files in the DART logs. The more you look into the steps that take place during a connection, the easier it is to figure out where exactly it is failing.
Thanks for stepping up to answer our questions it is a great services to us. We started using the AnyClient 3 client at the beginning of the year as part of SSL VPN and had no problem using our IP Communicators. We have migrated to AnyClient with certificate authenication and now the IP Communicator sit at Configuring IP. So far we can not find anything that would cause a certificate to break the IP phone stream. Do you have any ideas to point us in the correct direction?
Hmm sounds interesting. Ideally, the certificate authentication should not have anything to the ip communicator control flow. Now a good way to start would be collect Wireshark captures on the vpn adapter to see where exactly the connectioin is broken. Is there any usage of certificates with the CM and the ip communicator itself? I am looking more into the direction that maybe the wrong certificate is being used for the connection between client and CM. But that again is with the limited knowledge with the CIPC call flow. IMO comparing good vs bad captures are the way to go for this one. Have you done this already?