Re: VPN Client Connection Terminates

CoetzerJ · ‎09-13-2005

I have a problem with VPN Client connections to a VPN3005. Sometimes the connection will work at first time, other times the connection will complete all the negotiation for the secure tunnel and terminate just before going active.

Have anyone experienced something similar?

smalkeric · ‎09-19-2005

This document provides troubleshooting tips you can use in order to resolve connectivity issues with the Cisco VPN 3000 Concentrator.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_tech_note09186a0080094eca.shtml

jackko · ‎09-19-2005

need to identify the issue first. have you try connecting from a different pc and/or different isp?

CoetzerJ · ‎09-20-2005

Yes, we have tried different ISPs and even tried connecting from the same subnet as the VPN concentrator - it still does this. Will be doing more investigation today or tomorrow, and will add some logs etc.....

CoetzerJ · ‎09-23-2005

Got some logs,

CLIENT Unsuccessfull Log

---------------------------------------------------

34 09:27:08.232 09/21/05 Sev=Info/5 IKE/0x6300005E

Client sending a firewall request to concentrator

35 09:27:08.232 09/21/05 Sev=Info/5 IKE/0x6300005D

Firewall Policy: Product=Cisco Systems Integrated Client, Capability= (Centralized Protection Policy).

36 09:27:08.232 09/21/05 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 112.113.114.115

37 09:27:08.748 09/21/05 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 112.113.114.115

38 09:27:08.748 09/21/05 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, DWR) from 112.113.114.115

39 09:27:08.763 09/21/05 Sev=Info/4 IKE/0x63000081

Delete Reason Code: 4 --> PEER_DELETE-IKE_DELETE_NO_ERROR.

40 09:27:08.763 09/21/05 Sev=Info/5 IKE/0x6300003C

Received a DELETE payload for IKE SA with Cookies: I_Cookie=272A81E8752A8FB3 R_Cookie=44E573837B52390D

41 09:27:08.763 09/21/05 Sev=Info/4 IKE/0x63000017

Marking IKE SA for deletion (I_Cookie=272A81E8752A8FB3 R_Cookie=44E573837B52390D) reason = PEER_DELETE-IKE_DELETE_NO_ERROR

42 09:27:08.810 09/21/05 Sev=Info/6 IPSEC/0x6370001D

TCP RST received from 112.113.114.115, src port 10000, dst port 1486

43 09:27:09.310 09/21/05 Sev=Info/4 IKE/0x6300004B

Discarding IKE SA negotiation (I_Cookie=272A81E8752A8FB3 R_Cookie=44E573837B52390D) reason = PEER_DELETE-IKE_DELETE_NO_ERROR

44 09:27:09.310 09/21/05 Sev=Info/4 CM/0x6310000F

Phase 1 SA deleted before Mode Config is completed cause by "PEER_DELETE-IKE_DELETE_NO_ERROR". 0 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system

---------------------------------------------------

The VPN Concentrator log has similar entry in it sending the DELETE_NO_ERROR message to the client software.

If you try and connect stratight thereafter (after the first attempt failed, the connection is successfull, and connects.

---------------------------------------------------

89 09:31:15.043 09/21/05 Sev=Info/5 IKE/0x6300005E

Client sending a firewall request to concentrator

90 09:31:15.043 09/21/05 Sev=Info/5 IKE/0x6300005D

Firewall Policy: Product=Cisco Systems Integrated Client, Capability= (Centralized Protection Policy).

91 09:31:15.059 09/21/05 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to 112.113.114.115

92 09:31:15.637 09/21/05 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 112.113.114.115

93 09:31:15.652 09/21/05 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 112.113.114.115

Connection > Continues without any errors.

---------------------------------------------------

jackko · ‎09-23-2005

just wondering if remote users share a single username/password or every user has an individual username/password. the reason i want to clarify is that concentrator has a setting named concurrent conneciton per user.

assuming the current setting is 3, then that's mean the 4th person try to logon will need to wait until one of those 3 log off.

CoetzerJ · ‎09-23-2005

All the users have their own username and password.

I have another box that is configured with exactly the same configuration and that one does not do it.

The only difference I can spot at this stage is the code.

The working box has vpn3005-4.1.5.Rel.k9 on it and the non working one has the latest code on it. I have tried all the versions available on the VPN Download site, but they all give the same problem.

The vpn3005-4.1.5.Rel.k9 is no longer on the VPN Download site so I cannot get the software to downgrade the troublesome unit to verify that it is infact the problem.

pkapoor · ‎09-23-2005

FYI, if you want the 4.1.5 release, then you can open a TAC case and they may be able to publish it for you, if the release has not been deffered.