November 8, 2012 at 02:12VPN connection using Cisco VPN Client under Windows 8 x64 (almost solved)
Hello!
Despite the fact that the Windows 8 compatibility center claims full compatibility of the Cisco VPN Client with the new OS, it was possible to get this client to work only by non-trivial actions and, alas, for many cases, except mine.
I hope, however, that the information will be useful and, perhaps, a collective mind will help solve the problem to the end.
So, given: a VPN built on Cisco equipment and the need to connect to it under 64-bit Windows 8 Professional. First, install the latest available version of Cisco VPN Client 5.0.07.0440. Installation takes place without any complications. We import your favorite .pcf with connection settings and try to connect. Then we have problems:
This problem is solved by fixing the key value in the registry, for this:
After updating the registry, a reboot is not required. So, the virtual adapter is now safely located, and if authentication is performed using the Shared Key (does not require a client certificate), the problems have been settled on this.
If authentication is performed using a certificate, we have the following:
It is understood that the certificate (which does not require a private key on a separate device of the eToken type) is normally uploaded to the user certificate store (User Storage). At the same time, we have the following message in the client’s log: “Could not load certificate [certificate description] from store Microsoft User Certificate. Reason: store empty. " That is, despite the presence of a certificate in the store, the VPN Client does not see it.
There were two ways to solve this problem:
We proceed to the next level: now we have key authentication using e-token (Alladin). We have a program that comes with a key (eToken PKI Client), which, when a USB token is connected to the machine, automatically puts the certificate on the token into the user certificate store (that's why I solved problem number two using the second method). When trying to connect to a VPN in this configuration, we get the following error:
In the client’s log you can see the message “Failed to generate signature: signature generation failed” and other even less informative formulations. Unfortunately, this is a dead end: log messages do not shed light on the essence of the problem, which direction to dig further is not known.
I hope I’m not alone in this matter and someone will be more smart and lucky.
UPD: As an alternative option for connecting, you can use the Shrew Soft VPN Client, which does not have problems when running in Windows 8 (an article on installing and configuring this program already skipped on the hub). The program has one minus - it does not know how to work with certificates from Windows certificate stores (certificates need to be downloaded from a file when setting up the connection), which is also not suitable for the case with the key on eToken.
Despite the fact that the Windows 8 compatibility center claims full compatibility of the Cisco VPN Client with the new OS, it was possible to get this client to work only by non-trivial actions and, alas, for many cases, except mine.
I hope, however, that the information will be useful and, perhaps, a collective mind will help solve the problem to the end.
So, given: a VPN built on Cisco equipment and the need to connect to it under 64-bit Windows 8 Professional. First, install the latest available version of Cisco VPN Client 5.0.07.0440. Installation takes place without any complications. We import your favorite .pcf with connection settings and try to connect. Then we have problems:
Problem number one: "Reason 442: Failed to enable Virtual Adapter" error
This problem is solved by fixing the key value in the registry, for this:
- Open the registry editor (type “regedit” in the search bar, run the found application);
- We find the branch HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ CVirtA;
- Find the parameter DisplayName;
- The value of this parameter contains something like "oem4.inf,% CVirtA_Desc%; Cisco Systems VPN Adapter for 64-bit Windows". You must change this value, leaving only the "Cisco Systems VPN Adapter for 64-bit Windows."
After updating the registry, a reboot is not required. So, the virtual adapter is now safely located, and if authentication is performed using the Shared Key (does not require a client certificate), the problems have been settled on this.
If authentication is performed using a certificate, we have the following:
Problem number two: "Reason 403: Unable to contact security gateway"
It is understood that the certificate (which does not require a private key on a separate device of the eToken type) is normally uploaded to the user certificate store (User Storage). At the same time, we have the following message in the client’s log: “Could not load certificate [certificate description] from store Microsoft User Certificate. Reason: store empty. " That is, despite the presence of a certificate in the store, the VPN Client does not see it.
There were two ways to solve this problem:
- Move the certificate from the User Store to the Local Computer Store;
- Change Service Settings for Cisco Systems, Inc. VPN Service ”on the“ Log On ”tab, forcing the service to start under the user account (the same account under which we entered the system ourselves and are trying to connect).
We proceed to the next level: now we have key authentication using e-token (Alladin). We have a program that comes with a key (eToken PKI Client), which, when a USB token is connected to the machine, automatically puts the certificate on the token into the user certificate store (that's why I solved problem number two using the second method). When trying to connect to a VPN in this configuration, we get the following error:
Problem number three (unsolved): "Reason 401: An unrecognized error occured while establishing the VPN connection"
In the client’s log you can see the message “Failed to generate signature: signature generation failed” and other even less informative formulations. Unfortunately, this is a dead end: log messages do not shed light on the essence of the problem, which direction to dig further is not known.
I hope I’m not alone in this matter and someone will be more smart and lucky.
UPD: As an alternative option for connecting, you can use the Shrew Soft VPN Client, which does not have problems when running in Windows 8 (an article on installing and configuring this program already skipped on the hub). The program has one minus - it does not know how to work with certificates from Windows certificate stores (certificates need to be downloaded from a file when setting up the connection), which is also not suitable for the case with the key on eToken.