VPN Client Hangs at "Securing Communications Channel"

[d-garnett]

Cisco VPN Client 3.6

PIX FOS 6.3(1) - 3DES/AES activated

VPN Client connects and hangs at "securing communications channel". If I go ahead and send data (i.e., open up a command prompt and ping) to any network that is to protected, the messages disappear from the screen and the Yellow Lock goes down to the system tray as expected. It's fine once you send some data, but the "Securing Communications Channel" message will hang there indefinitely until you do.

I am pretty sure that it has to do with the VPN Client waiting on an IPSec SA to be built (Key Request) to a "defined protected" network before the Yellow Lock goes down to the system tray. Anyone seen this?

I am currently using a PIX to backup a 3000 for a bunch of Remote Access Clients. This does not occur with the 3000 but does with the PIX. The same networks to be protected are define on both devices.

--if i upgrade to client 4.0.x, it will not work at all--

[sachinraja]

hello..

as i can see, the SA negotiation in the PIX might have a problem here.. can you please check up with "debug crypto ipsec", "debug crypto isakmp" & "debug crypto engine" and see if it shows any errors ??

are there any errors on the ipsec client logs ?? i hope the IP connecitivity to the PIX outside is fine and there are no firewalls in between blocking any traffic..

[BRUNO WOLLMANN]

I was having the exact same problem after I added a second vpngroup and second dynamic mapping to my PIX config. To fix the problem I removed the following match address statements...

crypto dynamic-map DYNMAP1 100 match address DYNMAP1

and

crypto dynamic-map DYNMAP2 1000 match address DYNMAP2

I didn't enable any debugging on the PIX before I removed these statements so I can't tell you what the PIX was saying.

I did some testing and the IP range that I wanted accessible from DYNMAP1 is accessible from DYNMAP1 but not DYNMAP2. The IP range I wanted accessible from DYNMAP2 is accessible from DYNMAP2 but not DYNMAP1 - which is exactly what I wanted. I don't yet understand how this works without the MATCH ADDRESS statements.

Hope this fixes your problem too.

Bruno

[mgutowsk01]

I'm having a similar problem with the VPN Client hanging at "Secuing Communications Channel".

The Cisco VPN Client software is provided by my work. I've never had problems in the past with XP, but my PC recently died at home and I'm now running Windows 7 Ultimate on a new machine.

I've installed the VPN Client software and can enter my profile and password, but it then hangs at the "Securing Communications Channel" message. Neither the help desk nor myself can figure it out. I'm an IT professional, but on an AS400 platform so I have a little knowledge with PCs.

Work is convinced it's due to Ultimate.

Any suggestions?

Thanks in advance for any and all help.

[andamani]

Hi,

Your machine is a 32 bit machine or a 64 bit mahcine? Are you sure the correct client version is installed?

You can try collecting logs when connecting to vpn client.

To make logging full:

VPN Client > Log > Log settings > make all of the categories full.

VPN Client > Log > Log settings > Enable

Try connecting. then go to vpn client > log tab > View. collect the logs an dpaste here.

Hope this helps

Regards,

Anisha

P.S.: please mark this thread as answered if you feel your query is resolved. Do rate helpful posts.

[charradke]

So I had the same issue.  Variables as follows:

- Windows 7 Ultimate x64 (anytime upgraded from 7 basic or whatever it's called

- ASA version 825 (also tried 822)

- VPN client version 5.0.07.0440 (also tried 5.0.07.0290)

Basically, the client would complete phase 1 and 2 then hang on a status of "securing communications channel".  There were IPSec SAs on the ASA (sho crypto ipsec sa) and address was allocated from the ip local pool (sho ip lo poo [name]).  However, on my machine, there were no routes installed (route print) and the ip address on the virtual tunnel adapter was unassigned (ipconfig /all).

The client log was showing errors to the effect of route install failed and failed to enable virtual tunnel adapter.  Unfortunately I didn't save the exact errors, but I'll try to recreate and post later. 

Ultimately, what resolved the issue for me was running the client as an administrator.  I've since removed that configuration and it still seems to work running as normal.  So, right click VPN client in your start menu and go to properties->compatibility and check "run this program as an administrator".

At this point, I am running 5.0.07.0290 and 822.  I am still experiencing some issues with my split tunnel, but I have some abnormal stuff going on with persistent routes etc...  Bottom line is, the client seems to be happy.   

Let me know how it goes.