VPN Client RA-Connection drops sometimes

otillig · ‎06-30-2011

I have an issue witch Cisco VPN-Client V 5.0.06.0160 Remote VPV-Access to ASA 5510 8.2(3)

Evrything works fien but sometimes after about 4-5 Hours the Connection is dropped by the ASA. The Client still prtends to be connected, but there is no connection seen on teh ASA. Has anyone an Idea ?

Kind Regards

Oliver

Herbert Baerten · ‎07-03-2011

Since there is not much data to go on, just a few thoughts:

Does this happen when the client is idle for a long time (if so, check the idle-timeout on the ASA) ? Is the client behind NAT?

Are isakmp keepalives /DPD enabled? If not, try enabling them - the least this should so is disconnect the client when the ASA ends the session.

Check syslogs on the ASA, maybe also "debug crypto isakmp 10" and "debug crypto ipsec 10" (these can be limited to one client with "debug crypto condition ...").

Check client logs, although if it thinks it is still connected, it will probably not have much useful info.

hth

Herbert

otillig · ‎07-11-2011

Hello Herbert,

the Client is not idle for a long time, and the Connection is still alive but no more Data passes throug the tunnel. I think that is an error regarding the key exchange.

I´ll debug further....

Tx,

Oliver

Herbert Baerten · ‎07-11-2011

Ok, if we can help let us know what you see in the logs debugs and client logs

Cheers

Herbert

Sent from Cisco Technical Support iPhone App

otillig · ‎07-12-2011

Hello Herbert,

as you can see in my listing below , it seems to be a Phase 2 rekeying problem. The client requests a new key-exchange, but gets no answer.

any suggestions?

regards,

Oliver

Richard Burts · ‎07-04-2011

Oliver

I have sometimes seen symptoms like that when there was some interruption in the client connectivity to Internet. Is it possibly the case here?

HTH

Rick

Sent from Cisco Technical Support iPhone App

HTH

Rick

otillig · ‎07-11-2011

Hello Rick,

sorry, but as you can see above, ithink its a problem during key-exchange, since the tunnel still exists, but is carrying no more traffic...

here is the debugging from the client side: (the ASA is to busy to debug several hours)

222 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x63700014

Deleted all keys

223 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

224 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0x331c4759 into key list

225 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x63700010

Created a new key structure

226 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x6370000F

Added key with SPI=0xca4313d1 into key list

227 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x6370002F

Assigned VA private interface addr 10.6.15.50

228 16:29:52.557 06/07/11 Sev=Info/4 IPSEC/0x63700037

Configure public interface: 192.168.1.39. SG: x.x.x.x

229 16:29:52.557 06/07/11 Sev=Info/6 CM/0x63100046

Set tunnel established flag in registry to 1.

230 16:29:54.080 06/07/11 Sev=Info/4 IPSEC/0x63700019

Activate outbound key with SPI=0x331c4759 for inbound key with SPI=0xca4313d1

231 22:53:49.586 06/07/11 Sev=Info/4 IPSEC/0x6370000E

Key with outbound SPI=0x331c4759 is about to expire, requesting a new one

232 22:53:49.586 06/07/11 Sev=Info/4 IPSEC/0x6370000B

Key requested

233 22:53:49.586 06/07/11 Sev=Info/4 IKE/0x63000056

Received a key request from Driver: Local IP = 10.6.15.50, GW IP = x.x.x.x, Remote IP = 0.0.0.0

234 22:53:49.586 06/07/11 Sev=Info/4 IKE/0x63000051

Initiating IKE Phase 2 (MsgID=8B1AA328)

Initiator = ID=10.6.15.50 Protocol=0 port=0, Responder = ID=0.0.0.0/0.0.0.0 Protocol=0 port=0

235 22:53:49.586 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to x.x.x.x

236 22:53:54.656 06/07/11 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

237 22:53:54.656 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(Retransmission) to x.x.x.x

238 22:53:59.726 06/07/11 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

239 22:53:59.726 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(Retransmission) to x.x.x.x

240 22:54:04.796 06/07/11 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

241 22:54:04.796 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(Retransmission) to x.x.x.x

242 22:54:09.865 06/07/11 Sev=Info/4 IKE/0x6300002D

Phase-2 retransmission count exceeded: MsgID=8B1AA328

243 22:54:09.865 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, DEL) to x.x.x.x

244 22:54:09.865 06/07/11 Sev=Info/4 IKE/0x63000049

Discarding IPsec SA negotiation, MsgID=8B1AA328

TX,

Oliver

Nachricht geändert durch OLIVER TILLIG, client debug excerpt

Herbert Baerten · ‎07-14-2011

This shows indeed that the client starts a rekey, but the ASA does not respond (or the response doesn't reach the client):

235 22:53:49.586 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID) to x.x.x.x

236 22:53:54.656 06/07/11 Sev=Info/4 IKE/0x63000021

Retransmitting last packet!

237 22:53:54.656 06/07/11 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK QM *(Retransmission) to x.x.x.x

I don't think we can get any further without debugs and captures from the ASA. You can configure conditional debugging so that it only produces debug output for a certain client, see "debug crypto condition ?".

And if you dont want to enable the debugs for a long time, you can either enable them 6 hours after the connection started, OR temporarily decrease the ipsec lifetime to e.g. 10 minutes, quickly start the connection and the debugs, then increase the lifetime again (to avoid impact on other users), then after about 8 minutes you should see the problem (unless of course the problem is related to some kind of timer)

hth

Herbert

(I don't know yet if I'll have internet access the next 2 weeks so not sure if I'll be able to follow up :/ )