Cisco AnyConnect Client Error

The VPN client driver encountered an error. Please restart your computer or device, then try again

Let me save you sometimes off the bat. Ignore Cisco's advice in this error message. Don't bother restarting your device. It is unlikely to fix your issue, unless you are running XP.

Also, you can most probably safely ignore the fix that Cisco offers for the recorded bug CSCsm54689. Why? Simply because their solution is to disable the RRAS (Routing and Remote Access Service). On my Windows 7 box, this service was disabled already. For the fun of it (!!??), I actually enabled it, restarted the box, then disabled it and retested. No change, the same old frustrating error pops up (the VPN client driver encountered blah blah).

I even checked the "Cisco AnyConnect Secure Mobility Client Administrator Guide" Release 3.0, with the last update date of April 7th, 2014. This issue has been blamed on Microsoft updates on page 12-18 of the Guide. That's really an unfair sending the guys "chasing the wild goose" kind of action. So much so that at the end of their solution, they are embarrassingly admitting that this solution won't work and connection attempt will still fail, so just go ahead and open a case with Microsoft!!! I was so disparate that I went ahead and did the steps to no avail. I didn't bother opening a case with MS though. Read for yourselves: "Even though the steps taken above may indicate that the catalog is not corrupt, the key file(s) may still have been overwritten with an unsigned one. If the failure still occurs, open a case with Microsoft to determine why the driver signing database is being corrupted."

I also went through PeteNetLive solution. The first part of it is taken from the the Admin Guide mentioned above. Based on the notes in this site I ended up removing the client and reinstalling the AnyConnect latest version with a brand new version of Java VM. This cost me an hour or two and guess what? It didn't help either!!

But there is still hope. So, don't despair!

The Solution

Enventually I threw every thing at our great network engineer Ken. Including the message log shown below:

[7/25/2014 9:08:07 AM] Ready to connect.

[7/25/2014 9:08:14 AM] Contacting vpn.domain.blah.blah

[7/25/2014 9:08:27 AM] User credentials entered.

[7/25/2014 9:08:29 AM] Please respond to banner.

[7/25/2014 9:08:31 AM] User accepted banner.

[7/25/2014 9:08:31 AM] Establishing VPN session...

[7/25/2014 9:08:31 AM] Checking for profile updates...

[7/25/2014 9:08:31 AM] Checking for product updates...

[7/25/2014 9:08:31 AM] Checking for customization updates...

[7/25/2014 9:08:31 AM] Performing any required updates...

[7/25/2014 9:08:36 AM] Establishing VPN session...

[7/25/2014 9:08:36 AM] Establishing VPN - Initiating connection...

[7/25/2014 9:08:37 AM] Establishing VPN - Examining system...

[7/25/2014 9:08:37 AM] Establishing VPN - Activating VPN adapter...

[7/25/2014 9:08:37 AM] Disconnect in progress, please wait...

[7/25/2014 9:08:43 AM] Connection attempt has failed.

[7/25/2014 9:08:43 AM] Ready to connect.

Ken looked at this log for sometime. Then he checked the UAC settings. The slider was set at "Always Notify". He moved it to "Never Notify" and that fixed everything.

What? Hold on! But Why?

So why did this fix it? Ken believed the failing occurred on "Performing any required updates.." stage. You can see that in the log messages. Right? (well, I don't! But I took his words for it!).

Just to dig deeper, I set the slider on the UAC settings dialogbox back to "Always Notify", rebooted the laptop and retried the connection via AnyConnect. What would you expect? Should it connect or should it fail again? I expected it to fail. But... To my surprise, it didn't fail! It connected happily! 

My Theory

According to Ken, "the client was failing on Performing any required updates...". If that's the case, then it shouldn't fail if there is no updates to perform. As the slider was moved to "Never Notify" a few minutes prior to my test, all "the required updates" must have been applied and there was no new updates to perform. Hence, no failure occurred. Bingo!

I will leave the slider on the Always Notify for now. This hopefully (!!) will cause the client to fail next time if and when there are some updates from Cisco. I will let you know, when I get this error again. However, next time I will just run the client As Administrator. I think that's a better, safer and less impactful (is there such a word?) approach than setting the slider to "Never Notify" for good.  

One more point: This is certainly a bug, even Cisco admits to it. I think the software doesn't know how to work with UAC. Maybe that's due to a mix-up between the x86 and x64 libraries. This is probably why Cisco's solution to  CSCsm54689 works for some system (like XP for instance) and doesn't work for others (Windows 7). Whether that is (or is not) the cause, Cisco owes it their user base to fix this annoying bug and keep their documentation up to date.

 

   

Why MVC 4 Intranet Applications Throw Access Denied!

The Task/Issue:


Let's assume that you are logged-in to your company's domain. Your boss comes in your cube and asks you to create an intranet application for internal company use. She dictates the requirement but before she completes the first sentence, her cell phone rings and off she goes. You are the kind of go-get-it type that she likes. So you start your development process by simply firing up your VS and creating an MVC 4 application based on the Intranet template. You hit F5 for a quick test. Unexpectedly you get an access denied! That feels like a punch in the nose... If you, the developer get access denied to your own little creation, nobody else will be able access it. Is MS pulling your legs or what?


 The Questions:


Well, Windows Authentication is *disabled* by default in MVC application! More surprisingly, the Anonymous Authentication is *enabled* by default! This design is based on the understanding that the majority of developers who are creating Intranet application are not developing against an Active Directory Server sitting somewhere in you company’s premises or hosting cloud (I am *not* one of those… Wonder if you are!). Isn’t this a strange assumption? Why should one create an intranet app, if one doesn’t have an AD authentication service or a fire-walled environment?? Also, apart from creating a security hole in your app, what’s the point in enabling Anonymous Auth especially if it doesn’t allow you, the developer, in anyways? Nevertheless, using the approach mentioned in the following paragraph, your application be able to authenticate against the AD correctly.


The Fix:


Make sure the Intranet project is your active project by clicking its name in the Solution Explorer. Use the View > View Properties menu. Note the value of the "Windows Authentication" property. By default it is set to "Disabled". You need to set this value to "Enabled". Your company's AD does not normally allow "Anonymous Access". So you might as well set the value of this property to "Disabled" to ensure that your application is a little more secure. Hit F5 and you will note that the access denied is not thrown, instead your will see a greeting message on the top right corner of your application window. So you are in. So will everybody else with a company set of credential be able to log-in to your app magically (without filling a log-in form). Well, almost "magically"…


 IE Settings:


The behavior actually depends on two setting in the IE. Firstly, the http://Localhost must be identified as an intranet site. So please drop it in your intranet site using the "Internet Options" dialog box. Secondly, the User Authentication in the Intranet Security Should be set to “Automatic logon Only in Intranet Zone”. This setting can be configured via Internet Options, using “Local Intranet > Custom Level… > User Authentication > Logon”.  Then the “Magic” becomes more prevalent.