VPN connection dropping

Unanswered Question


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

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

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

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.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
michael.leblanc Fri, 06/20/2008 - 09:54

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?

michael.leblanc Fri, 06/20/2008 - 11:18

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 Fri, 06/20/2008 - 12:17

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.




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, seq# received = 1283243927, seq# expected = 1283243927

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


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

Sending DPD request to, our seq# = 1283243928

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


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

Sending DPD request to, our seq# = 1283243929

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


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


Farrukh Haroon Mon, 06/23/2008 - 07:44

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

|System >> Events



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


Farrukh Haroon Mon, 06/23/2008 - 22:43

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.




This Discussion