06-20-2008 07:53 AM - edited 02-21-2020 03:47 PM
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
06-20-2008 09:54 AM
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?
06-20-2008 10:16 AM
Hi
The loss of service is completely random. Could be fine for hours and then drop twice in 10 minutes.
06-20-2008 11:18 AM
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.
06-20-2008 12:17 PM
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
06-23-2008 07:29 AM
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
06-23-2008 07:44 AM
It would be nice if you enable the logs on the VPNC and check as well
|System >> Events
Regards
Farrukh
06-23-2008 07:52 AM
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
06-23-2008 10:43 PM
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
01-08-2009 11:00 AM
Miles,
Did you resolve this issue yet?
Craig
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide