Pix /VPN Client Time out

[Guest_imported]

I have configured a Pix 515R so that a remote vpn client can connect using pre-shared keys.
The connection is formed without any problems and the user can access the network for approximately 6 minutes but then the server end i.e. the Pix, appears to time out. The client clock goes on ticking as though it is still connected but the user can't do anything. He must disconnect and reconnect.
The Pix version is 6.1(1) and the VPN client is 3.5 for Windows. The group idle time is set for 1800 seconds.
I have searched the CCO site but can't find anything on this.
Grateful for any clues.

 

[yizhar]

HI.

Some ideas:

* It could be an intermidiate network problem in the Internet path between the client and the pix.

* Try keeping the link "warm" to see if its related by pinging through the VPN tunnel. You can use a program like KIT from here:

http://teachers.sivan.co.il/yizhar/#NUTS

You can also make a test by downloading/uploading a big file via the VPN tunnel - is the connection more stable that way?

* Post here your VPN configuration stripping secrets and registered addresses so we can better advice to you.

* Debug at the pix using syslog messages and debug commands.
Use telnet from an internal host to the pix, and issue some or all of the following commands:
debug crypto isakmp
debug crypto ipsec
debug crypto engine
show debug
terminal monitor

Tip1 - capture to text file for easier reviewing later.

Tip2 - Use the command

term no mon

to stop getting the messages, then "no debug ..." when done.


Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[Guest_imported]

Thanks for the comments. I tried tranferring a large file but it stopped at the 6 minute mark and eventually died.

Here is the relevent part of the config. Have I left something out?
PIX Version 6.1(1)

access-list no-nat permit ip 10.10.50.0 255.255.255.0 10.10.80.0 255.255.255.0

ip local pool vpnpool 10.10.80.1-10.10.80.254


nat (inside) 0 access-list no-nat


sysopt connection permit-ipsec

crypto ipsec transform-set blabla esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set blabla
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup vpngrp address-pool vpnpool
vpngroup vpngrp dns-server 10.10.50.1
vpngroup vpngrp wins-server 10.10.50.2
vpngroup vpngrp default-domain ourdomain.com.au
vpngroup vpngrp idle-time 1800
vpngroup vpngrp password ********

Thanks for any comments

 

[yizhar]

Hmm..

The configuration seems fine to me.

Show yourself and us the syslogs and debug outputs.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[Guest_imported]

The debug output is exactly the same as that shown for a successful implementation in the Cisco VPN Client configuration using IPSec doco.
One thing I have discovered is that the time taken before the connection hangs is dependent on the setting of the Peer response timeout value in the Client. If the Peer response timeout is set to 60 seconds it times out after 2 minutes.
If it is set at 480 seconds (the maximum) it times out after 6 minutes.
Something to do with the Dead Peer detection perhaps.
It was suggested by a Cisco Dealer that I should be using VPN Client 3.1.2 rather than 3.5 which they told me was for use with VPN concentrators only so I tried version 3.1.2 of the Client but the result was exactly the same.

 

[yizhar]

HI.

>> The debug output is exactly the same as that shown for a successful implementation in the Cisco VPN Client configuration using IPSec doco

But do you get any debug output when the connection hangs?

What about using the VPN client "Log Viewer"?

Try to connect the client to different ISP and check, also try connecting the client directly via Ethernet to the outside of the pix if you can.

How many remote clients you have? On what OS?
Try different client computers with different OS and OS type (9x versus 2k/XP)

BTW - by default I recommend not to provide name resolution via the VPN, unless you must. So I suggest removing the following commands:
vpngroup vpngrp dns-server 10.10.50.1
vpngroup vpngrp wins-server 10.10.50.2
vpngroup vpngrp default-domain ourdomain.com.au

Use LMHOSTS or HOSTS, if the client only needs access to specific internal server(s).

Good luck
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[Guest_imported]

One to two minutes after it hangs I get a message on the screen saying "Your IPSec connection has been terminated.
At the same time the VPN Client Log Viewer gives the following error.
1 07:42:09.996 03/03/02 Sev=Warning/3 IKE/0xE3000062
Could not find an IKE SA for 200.0.0.9. KEY_REQ aborted.

We have about 10 VPN Clients. We get the same error with different ISP's - Dial-up or cable.

I don't have access to the syslog server at present but am trying to organise someone to look at these.

I will open a case with the TAC Centre.
Regards
Rob

I am trying to organise

 

[Guest_imported]

It is beginning to look as though this problem exists mainly on clients which have cable access to the internet.
We have been able to get vpn access via a dialup modem using Windows 2000 and VPN Client 3.0.3B without the hanging problem. It has been suggested that the mtu size of 1500 to 1550 on cable may be causing packets to be dropped.
The Cisco dealer is investigating further.

 

[Guest_imported]

The problem described above appears to exist only on the cable network of one Australian ISP who sends a "heartbeat" ping packet on port 5050-5055 every 7 minutes and disconnects Clients who don't respond.
As it is not of Universal interest I refer anybody who is having a similar problem to the following url:

http://www.ozcableguy.com/heartbeat.html.

It is possible that the problem can also be solved by split tunneling.
Regards
Rob

 

[Guest_imported]

I got similar problems before, make sure udp 500 accepting inbound traffic.