I have never seen that before in my life. Something could be corrupting the VPN Profile. It is stored in a text file in the program files/cisco vpn/profiles folder.

Windows updates? Were the client configurations pushed to the laptops or installed individually? What's the common denominator here?

Burt

The client configurations were installed individually (this takes less than 2 minutes).  The systems do not have the same updates applied (we run heterogeneous so one event cannot take down all equipment).  This problem has been occurring for many months, so it was not caused by a new update.  And because at least one machine is up-to-the-minute, it was also not caused by an unpatched old update.

So let ME ask:  What's the common denominator here?  I sure can't see it.

I have done some searches on google and on cisco network professional forums and can't seem to locate anyone with the same issue.

So you put the info back into the clients, and they are able to connect or not? Does it lose the info right away, or are they able to connect once, close it, reopen it and the info is gone? Does this only happen on laptops or anyone configured to connect to said VPN? Do you also use Windows VPN for a different VPN connection?

Burt

Typing in the info immediately restores function and clients can then connect.  They can connect forever afterwards and usually work for weeks or months until the 'bad thing' happens and it is lost again.  This happens on both laptops and home desktop units.

This has happened on machines which have other cisco VPN entries listed (our gets lost, others are unaffected) as well as ones where we're the only entry.  Some of the machines have other VPN clients installed, most do not.  There seems to be no pattern.

There must be some EVENT that causes this state, but I haven't seen it mentioned anywhere on the interwebs.  Our working hypothesis is that an unsuccessful vpn connect attempt in a certain environment (due to heavy firewalling) brings on a state where the client is instructed to delete or modify the entry.  But I cannot find any reference to this state.

I work for a company supporting just over 2,000 users running a custom windows xp image that is the same across all machines and we have this exact same issue.

A user will call the helpdesk indicating his VPN no longer works.  It isn't working because the hostname portion of the cisco vpn configuration file (we just call it the pcf file for short) is gone.

Our fix has been to have users execute either winbatch scripts or .bat files that pull down the pcf file from an ftp site and copy it over the one missing information.

We have had this problem since the cisco vpn client has been deployed.

Thank you.  This workaround makes perfect sense and I am going to at least have the config file available so I can apply it more quickly on demand.

I also appreciate your input so I don't think that I'm going crazy.  Everyone I've described this to has looked at me like I'm nuts.  Thank goodness it's not just me.

So the bottom line: the Cisco VPN client has a bug that deletes the host address of the peer in some circumstance(s).  The circumstance(s) is not known, but re-entering the address is required.

Weird...

Burt

professorguy,

I would really like to compare our issues/environments.  This has been an issue for my department for quite some time and seeing as how uncommon the problem appears to be I would like to see what our issues have in common.

I couldn't find a way to PM on this site.  Can you please send me an email? I'll try and mask it here to protect myself from even more spam then I already get lol.

nathan("dot")quintanilla("at")champ("hyphen")tech("dot")com

This can occur when when the Cisco VPN client crashes or the system reboots unexpectedly when the client is connected.

The best solution is to keep backup copies of your .pcf files or update the broken pcf file with information from another pcf file.

I thought of a work around the other day.  You could deploy a small script file written in VBS or scripting language of your choice that runs at startup on the machine, compares the file size of the current pcf file, and if it is not correct, replaces it with a known good file.

This might not prevent everyone from getting the error, however it would definitely push down the time to resolution by making the fix "reboot your computer".

I guess you could even have a running process that checked every 5 minutes or so for the same thing, however no matter how you do it, its a potential work around.

vpnprog---they seem to have multiple versions of the client---it crashing with all versions on various computers may not be very likely at all...
Rebooting? I would think that not only the vpn connection entries perhaps get corrupted, but they'd probably notice..."Oh yeah---when this happens, the server reboots right before..."

Burt

Oh how odd... I just happen to run across this thread and I am glad I am not the only one that has experienced this same issue with some of my end-users.

On occasion I receive a call stating the same problem as you guys are having..."VPN can't connect due to host information missing".
Sure enough when I login to thier system remotely I notice that the profile still exists but the host name and/or the password info are gone.

On one user I had created a backup profile just in case one got corrupted and low and behold thier system BSOD and on reboot both profiles had thier host info removed. Although this is the only user that had reported a BSOD and was using Vista at the time.

Other than that I don't see any common link between the users that have reported this problem. All of my users are using either the latest version or one version prior of the Cisco VPN software.

I guess I will keep monitoring this thread in case someone finds a solution or cause to the problem.

-- Glad to know my users are not to blame...although it would've been easier to fix if it was them! --

Cisco's official response was for us to try it using the latest version of the VPN.  I asked our telecomms guy to tell them we know its happening to the latest version as well.

As a simpler workaround, I am setting the PCF files to Read Only (not on the Security tab, but just the general preferences pane) on our fileserver, and have verified that that attribute remains set after the file is copied to the client.  This handles any new builds or one-off clients whose pcf's become corrupt.

A GPO to set RO on c:\"program files\cisco systems\vpn client\Profiles\*.pcf" will also be rolled out to existing clients.  I had approached it from the automated backup and re-roll side, but our clients may have profiles for networks other than ours which wouldn't get handled in that case.

Cisco is aware of the issue and are targetting an upcoming release with a fix from what I understand.

I just wanted to comment that I have recently deployed a Cisco ASA-5510 for VPN use and have heard this problem reported by 2 users.  Have also seen no correlation to it occurring.  

Glad to see someone else having this issue as it was very confusing!  I have simply provided the PCF for these people and shown them how to import it...

 

We solved this problem by changing the .pcf file in Cisco Systems\VPN Client\Profiles to "Read only".

This seems to work fine at least with us, client doesn't lose the hostname etc. anymore.

Regards,

Antti

I have had this issue for a while as well.  I was looking for an officia answer for my VP f infrastructure but yu all have seen the same thing.  Blows out when the system shuts down wrong or the client is forced closed.  We use certs and sometimes the host name will be lost and the authentication will switch to use IPsec group.  I just tell my people how to get in and fix it themselves but I like the read only idea on the file.  I think I will start doing this.

Hello all,
I've also met this Error 5 on some clients due to profile corruption.
This bug is supposed to be fixed in VPN Client version 5.03.0560 (Current version as of today is 5.04.0300)

IMO The Read-only attribute on pcf file is good trick, but it prevents the IPSec backup servers list to be updated at each new conenction; which may be very useful.
 

I just had a user report this problem and ran across this thread. I think they're using an older version of the client, but I'm not sure. I'm going to copy over the PCF again and set it to read only. That should work just fine for us.

JR30

you stated that This bug is supposed to be fixed in VPN Client version 5.03.0560...

Do you have the release notes that state this.  I believe that this is the case beacause I manually upgraded to this version but I can't find the release notes to prove that this will fix the problem so tuys who push out the software won't update the version used in SMS.
 

Hello,  I work for a company supporting about 200 laptops, and I too have been having this issue on a number of them.  I had been convinced that the user was doing something to corrupt the .PCF file, but then it happened to me.  I turned the laptop on, open the VPN client and tried to connect, and recieved the error we are talking about.  I noticed the hostname was missing.  STRANGE.  I usually just send them an email that has the .pcf file attached and host to install the new configuration file by accessing the email through OWA.  Just to give you some info on my situation:

2 Cisco ASA 5510 firewalls
All machines are running the 5.0.01.0600 client.
They are all Windows XP imaged, with the client included in the image.

We have 200 machines, and I would say this has happened to about 15 of them, over the past year.

I have not opened a ticket with Cisco yet, thought I would post here first.  

Hi lixperry
Sorry for late answer I did not check this thread since a while.
There is more than one bug about this profile issue.
One of them is CSCSo94244 that is mentioned in 5.0.04.0300 as stated in the Readme file :

Resolved Issues:
5.0.04.0300:
CSCso94244 Profile file (pcf) is getting corrupted.

This has been an issue since......as long as I can remember (includes Cisco's latest release).

I've found that several factors may have an effect.
1. Shutdown or logoff while connected
2. Proxy settings attempted during connection
3. Misconfiguration (most commonly split tunneling)
4. Loss of connectivity

WIN geared but applicable to all OS:
Save good profiles to 'C:\Tools\Profiles'. If the user gets an error, have them run your script, which copies the good profile to 'C:\PF\....Profiles'. Eliminates issues while pulling the profile from remote locations.

I ran into an issue with this as well. The issue was that the pcf connections I have were all working fine, but the information in those files could not be viewed. If I clicked
modify - the connection details were all the same and unreadable.

I had to set the vpngui.exe to be the default program for PCF files the problem was related to Windows PowerShell took over as default somewhere along the line. After resetting the default app to run these files to cisco - problem fixed.

Hope this helps someone else!

Anyone who has a problem with this:

What are you connecting to, i.e. ASA, router, etc.?

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!