cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2194
Views
0
Helpful
8
Replies

VPN 3000 Starts Authentication and then Quits

bfl1
Level 1
Level 1

Out of nowhere, my VPN 3000 has started deleting connections for a couple of accounts as soon as they authenticate. I type in the user name and password; it authenticates, negotiates security policies, and then says "Not Connected". I turned on full logging on the client and this is the output. Can anyone help? Since I’m only allowed to post a certain amount of characters, I’ll break into a few posts. Thanks!

Cisco Systems VPN Client Version 4.0.2 (D)

Copyright (C) 1998-2003 Cisco Systems, Inc. All Rights Reserved.

Client Type(s): Windows, WinNT

Running on: 5.1.2600

177 19:52:05.141 03/24/04 Sev=Info/4 CM/0x63100002

Begin connection process

178 19:52:05.141 03/24/04 Sev=Info/4 CM/0x63100004

Establish secure connection using Ethernet

179 19:52:05.141 03/24/04 Sev=Info/4 CM/0x63100024

Attempt connection with server "1.1.1.1"

180 19:52:05.141 03/24/04 Sev=Info/6 IKE/0x6300003B

Attempting to establish a connection with 1.1.1.1.

181 19:52:05.151 03/24/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Nat-T), VID(Frag), VID(Unity)) to 1.1.1.1

182 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 1.1.1.1

183 19:52:05.572 03/24/04 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, HASH, VID(Unity), VID(Xauth), VID(dpd), VID(Frag), VID(?), VID(?)) from 1.1.1.1

184 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x63000001

Peer is a Cisco-Unity compliant peer

185 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x63000001

Peer supports XAUTH

186 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x63000001

Peer supports DPD

187 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x63000001

Peer supports IKE fragmentation payloads

188 19:52:05.572 03/24/04 Sev=Info/5 IKE/0x63000001

Peer supports DWR Code and DWR Text

189 19:52:05.582 03/24/04 Sev=Info/6 IKE/0x63000001

IOS Vendor ID Contruction successful

8 Replies 8

bfl1
Level 1
Level 1

Part 2

190 19:52:05.582 03/24/04 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, VID(?), VID(Unity)) to 1.1.1.1

191 19:52:05.582 03/24/04 Sev=Info/4 IKE/0x63000082

IKE Port in use - Local Port = 0x01F4, Remote Port = 0x01F4

192 19:52:05.582 03/24/04 Sev=Info/4 CM/0x6310000E

Established Phase 1 SA. 1 Crypto Active IKE SA, 0 User Authenticated IKE SA in the system

193 19:52:05.632 03/24/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 1.1.1.1

194 19:52:05.632 03/24/04 Sev=Info/4 IKE/0x63000014

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

195 19:52:05.632 03/24/04 Sev=Info/4 CM/0x63100015

Launch xAuth application

196 19:52:05.972 03/24/04 Sev=Info/4 IPSEC/0x63700008

IPSec driver successfully started

197 19:52:05.972 03/24/04 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

198 19:52:09.898 03/24/04 Sev=Info/4 CM/0x63100017

xAuth application returned

199 19:52:09.898 03/24/04 Sev=Info/4 IKE/0x63000013

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

200 19:52:10.239 03/24/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 1.1.1.1

201 19:52:10.239 03/24/04 Sev=Info/4 IKE/0x63000014

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

202 19:52:10.239 03/24/04 Sev=Info/4 IKE/0x63000013

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

203 19:52:10.239 03/24/04 Sev=Info/4 CM/0x6310000E

Established Phase 1 SA. 1 Crypto Active IKE SA, 1 User Authenticated IKE SA in the system

204 19:52:10.249 03/24/04 Sev=Info/5 IKE/0x6300005D

Client sending a firewall request to concentrator

205 19:52:10.249 03/24/04 Sev=Info/5 IKE/0x6300005C

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

206 19:52:10.249 03/24/04 Sev=Info/4 IKE/0x63000013

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

207 19:52:11.270 03/24/04 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 1.1.1.1

208 19:52:11.270 03/24/04 Sev=Info/4 IKE/0x63000014

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

209 19:52:11.270 03/24/04 Sev=Info/4 IKE/0x63000080

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

210 19:52:11.270 03/24/04 Sev=Info/5 IKE/0x6300003C

Received a DELETE payload for IKE SA with Cookies: I_Cookie=443A8D23CAFCACA8 R_Cookie=95FD2F7271E6DCBB

211 19:52:11.270 03/24/04 Sev=Info/4 IKE/0x63000017

Marking IKE SA for deletion (I_Cookie=443A8D23CAFCACA8 R_Cookie=95FD2F7271E6DCBB) reason = PEER_DELETE-IKE_DELETE_NO_ERROR

212 19:52:11.981 03/24/04 Sev=Info/4 IKE/0x6300004A

Discarding IKE SA negotiation (I_Cookie=443A8D23CAFCACA8 R_Cookie=95FD2F7271E6DCBB) reason = PEER_DELETE-IKE_DELETE_NO_ERROR

213 19:52:11.981 03/24/04 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

214 19:52:11.981 03/24/04 Sev=Info/5 CM/0x63100025

Initializing CVPNDrv

215 19:52:11.981 03/24/04 Sev=Info/4 IKE/0x63000001

IKE received signal to terminate VPN connection

216 19:52:11.981 03/24/04 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

217 19:52:11.981 03/24/04 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

218 19:52:11.981 03/24/04 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

219 19:52:11.981 03/24/04 Sev=Info/4 IPSEC/0x6370000A

IPSec driver successfully stopped

Do you have a NAT device in front of the client. You may check if the NAT setting cause this problem. The other things is the personal firewall on the client side terminate the tunnel.

jmsimps
Level 1
Level 1

Hi,

I have to say this looks like the client(s) are coming from behind a NAT/NAPT device.

I saw the very same thing with multiple VPN clients behind a PIX 501 trying to connect to a single VPN concentrator.

If this is the case, you could use the NAT-T or IPSEC over UDP features available to you with the VPN 3000 and VPN client

Relevant NAT-T article:

http://www.cisco.com/en/US/customer/products/sw/secursw/ps2276/products_configuration_example09186a008010edf4.shtml

Hope this helps.

I am behind a pix 501... but have been for a year now and have never had a problem. All of the sudden one evening it stopped working. I will look at NAT-T. Thanks.

I looked at the logs on the concentrator and this is what is happening at the same time the client is erroring out.

211 03/24/2004 20:10:34.690 SEV=5 IKE/132 RPT=17 68.89.130.37

Group [VPN-Admin] User [mickeymouse]

Cannot obtain an IP address for remote peer

213 03/24/2004 20:10:34.700 SEV=5 IKE/194 RPT=18 68.89.130.37

Group [VPN-Admin] User [mickeymouse]

Sending IKE Delete With Reason message: No Reason Provided.

Hi,

If you can make changes to the concentrator and client, I can see no harm in configuring NAT-T (this feature was not available when I had this problem so I used IPSEC over UDP).

For information are you trying to run more that one tunnel through the PIX? as this could cause problems for IKE phase 1 as well as ESP.

Cheers.

I tried NAT-T and it didn't work. Nothing has changed, but it just stopped working. The vpn concentrator is saying all the ip's in my pool are in conflict, yet there is nothing else on the switch and this is in the dmz...

The address I assign myself doesn't come from the pool, rather i define it in the user name, so I have the same one every time.

This document describes one of the error messages seen in your concentrator logs.

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

It seems to be suggesting that your pool may not be configured correctly, or no address assignment mode is currently configured.

I would also be looking as to why you are getting any type of IP address conlficts occuring. I assume you have checked that no devices respond to the addresses defined in your pool(s).

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: