VPN connection dropping

mwilkinson · ‎06-20-2008

Hi

I've got an end user who, up to the last week, was connecting fine to the VPN. He is now experiencing intermittent drops to the Concentrator, and about 4 times a day has to reconnect. I've pulled off the log from the concentrator showing the process:

49339 06/20/2008 16:01:30.140 SEV=4 IKE/123 RPT=3593 10.201.41.51

Group [xxxxxx] User [xxxxxx]

IKE lost contact with remote peer, deleting connection (keepalive type: DPD)

49341 06/20/2008 16:01:30.140 SEV=5 IKE/194 RPT=42521 10.201.41.51

Group [xxxxxx] User [xxxxxxx]

Sending IKE Delete With Reason message: Connectivity to Client Lost.

49343 06/20/2008 16:01:30.140 SEV=4 AUTH/28 RPT=44019 10.201.41.51

User [xxxxxxxxxxx] Group [xxxxxx] disconnected:

Session Type: IPSec/UDP

Duration: 1:58:45

Bytes xmt: 4553024

Bytes rcv: 560168

Reason: Lost Service

We have set the Peer response timeout on the Client to the max (480 secs) but he's still losing service. We have also upgraded his client to 4.8.01 to see if this makes a difference - it hasn't(I know there are newer versions out there but 4.8.01 seems to work fine for other users!)

We've also had our telco visit the end user and check out the physical line in his house - they reported no fault with the line.

Any ideas where we can go next would be much appreciated.

Thanks

Miles

michael.leblanc · ‎06-20-2008

Would the DPD configuration (referenced in first log entry) override the peer response timeout of 480 seconds?

The duration shown is "Duration: 1:58:45", and you've indicated that it happens about 4 times a day.

8hr. work day / 4 occurrences ~= 1:58:45

Has the duration consistently been ~ 2hr., or does it vary? If it's consistent, maybe that's a clue you can use to your advantage.

Does the concentrator support IPSec over TCP?

mwilkinson · ‎06-20-2008

Hi

The loss of service is completely random. Could be fine for hours and then drop twice in 10 minutes.

michael.leblanc · ‎06-20-2008

I've seen DPD described as query/response, and would assume that the concentrator would be querying the client.

Is there any evidence of ISAKMP DPD being dropped on the external interface of the router/firewall that I assume the client resides behind?

We selectively permit an internal host to establish RAVPNs outbound through our firewall.

When we do so, we are provisioning the return path using "inspection". If the inspection timeout configured was inadequate, I could imagine ISAKMP DPD packets being dropped at the firewall's external interface during periods of relative inactivity.

I'm not saying that is your problem, only that knowledge of what is happening at an intervening device can be relevant.

A sniffer trace from the WAN side of your concentrator would help you evaluate the responsiveness of the client; how absent the client needed to be to trigger the tear down; and correlate it to events.

Farrukh Haroon · ‎06-20-2008

An easy way to test would be to instruct the user to put a continuous ping to any host on the subnet behind the concentrator, and see if it still drops.

Regards

Farrukh

mwilkinson · ‎06-23-2008

Hi

We've got the user to do an continuous ping and will get the results later. We also got the users VPN client log from earlier today (before the continuous ping) with the sequence of events before it lost service. Basically DPD's were being sent to the VPN Conc and the client was getting replies. This is all seemed to stop though from line 1336

1335 14:04:03.078 06/23/08 Sev=Info/5 IKE/0x63000040

Received DPD ACK from 10.200.2.1, seq# received = 1283243927, seq# expected = 1283243927

1336 14:04:43.562 06/23/08 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 10.200.2.1

1337 14:04:43.562 06/23/08 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 10.200.2.1, our seq# = 1283243928

1338 14:04:48.562 06/23/08 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 10.200.2.1

1339 14:04:48.562 06/23/08 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 10.200.2.1, our seq# = 1283243929

1340 14:04:53.562 06/23/08 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY:DPD_REQUEST) to 10.200.2.1

this went on for a further 8 mins with no DPD ack from the VPN Conc.

Why would the VPN Conc stop replying? I'm also assuming that the eu was also not generating any traffic at the time.

Best wishes

Miles

Farrukh Haroon · ‎06-23-2008

It would be nice if you enable the logs on the VPNC and check as well

|System >> Events

Regards

Farrukh

mwilkinson · ‎06-23-2008

I wish I could but the VPNC is looked after by another company and we don't have admin rights on the box.

I've also just heard back from the end user and he's lost service again, even when running a continuous ping to an external device. Does this indicate that the problem is with the telco's line?

Best wishes

Miles

Farrukh Haroon · ‎06-23-2008

90% it seems to be the connection (ISP/TELCO).

Who knows it could be a bug as well. I hope you have the latest software for the Client/VPNC.

Regards

Farrukh

craig.eyre · ‎01-08-2009

Miles,

Did you resolve this issue yet?

Craig