PEER_DELETE-IKE_DELETE_NO_ERROR

michelcaissie · ‎03-27-2006

Hi all,

I have a strange problem between a Cisco VPN client and a

Cisco Concentrator 3020 (vpn3000-4.1.7.H-k9.bin) .

I created a new User Group on the concentrator, similar to

an existing and working one.The main difference is in the

IP address pool and the split-tunnel network list.

The new profile works fine, except for one thing. Everyday, the first

time i use it i have to connect twice. The first time, after authentication

i get disconnected. I try again immediately and it works fine. I can then

disconnect and reconnect without problems after that,... until the next

day.

( I haven'y mesure exactly after how much time i need to connect twice).

I have five profiles on this concentrator and i have this behavior only with

this one. The problem occurs with different users, and different client

version.

I am testing with 4.8.00.0440. The problem is not related to the radius

server

since the disconnected sessions occurs after a successfull authentication.

Here are logs from a successful connection and a disconnected session.

You can see a "PEER_DELETE-IKE_DELETE_NO_ERROR" appearing.

Anyone have a solution for this ?

thanks

Successfull connection logs

36 15:54:37.770 03/22/06 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 206.x.x.x

37 15:54:37.770 03/22/06 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 206.x.x.x

38 15:54:37.770 03/22/06 Sev=Info/5 IKE/0x63000010

MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_ADDRESS: , value = 192.168.128.194

39 15:54:37.770 03/22/06 Sev=Info/5 IKE/0x63000010

MODE_CFG_REPLY: Attribute = INTERNAL_IPV4_NETMASK: , value = 255.255.255.224

Disconnected session logs

36 13:11:48.955 03/21/06 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 206.x.x.x

37 13:11:48.955 03/21/06 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, DWR) from 206.x.x.x

38 13:11:48.955 03/21/06 Sev=Info/4 IKE/0x63000081

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

39 13:11:48.955 03/21/06 Sev=Info/5 IKE/0x6300003C

Received a DELETE payload for IKE SA with Cookies:

I_Cookie=B00AF86D6AA272A7 R_Cookie=EEA371DC2813DF8D

mpmcwhirt · ‎06-28-2006

We were having a similar problem. Our problem turned out to be that we had included a broadcast address (x.x.x.0) as part of your IP address scope for a particular profile. Once the broadcast address was removed from the assigned IP address scope, the problem disappeared.

michelcaissie · ‎06-28-2006

Hi,

The problem here was also related to the IP pool but was slightly different. I could see in the Monitoring-Statictics-AddressPools that the first address of the pool was HELD, even though it was a valid address. I just removed the address from the pool, then add it back and the problem never came back.