Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

VPN Channel Question

Posted on 2016-07-20
13
Medium Priority
?
150 Views
Last Modified: 2016-07-27
Hi Guys,

We have a site-to-site VPN running over IPSec.

We are experiencing an intermittent problem, where connection between the two sites are lost, although the VPN channel stays / shows up. It shows "SA Established"

The one site is using a microwave link, and it seems that it happens everytime the microwave link goes down for a couple of seconds.

After the break in communication, the channel is only fully restored once one of the two routers are soft rebooted.

1.  Is there way to tell one of the routers to drop / re-establish the channel if the communication between the two sites goes down?
2.  Is the packets between the two routers perhaps going out of sync, and this causing the break in communication?  Although the channel stays up?
0
Comment
Question by:Rupert Eghardt
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 4
  • 3
13 Comments
 
LVL 71

Expert Comment

by:Qlemo
ID: 41720600
If the physical connection break-down remains undetected, then the behaviour as described can be seem. IPsec uses UDP. and packets are not confirmed, so loss is unknown.

Dead Peer Detection (DPD) is a way to cope with that. It is kind of ping on IPsec level. If there is no answer within a configured time, the tunnel goes down. Renegotation occurs as soon as the tunnel is used again.
0
 

Author Comment

by:Rupert Eghardt
ID: 41720936
Thanks Qlemo,

I will configure DPD and see if this helps.
0
 

Author Comment

by:Rupert Eghardt
ID: 41720946
Am I correct that these are the DPD IPsec settings?  
These have already been defined.
Is the detection period of 10 seconds perhaps too short?
DPD.png
0
Looking for the Wi-Fi vendor that's right for you?

We know how difficult it can be to evaluate Wi-Fi vendors, so we created this helpful Wi-Fi Buyer's Guide to help you find the Wi-Fi vendor that's right for your business! Download the guide and get started on our checklist today!

 
LVL 71

Expert Comment

by:Qlemo
ID: 41720963
That's a continous ping to a specific IP address, configured to initiate a reconnect after 3x10 seconds. It is another way, but less reliable.
0
 

Author Comment

by:Rupert Eghardt
ID: 41720987
Interestingly, I changed the 30 seconds to 120 seconds and the communication went down again after applying.

This can't be normal?  Can it be so sensitive?  During this time it is showing "IPsec SA Established"

The log is showing:
INFO:  an undead schedule has been deleted: 'pk_recvupdate'.
INFO:  Sending Informational Exchange: delete payload[]
0
 
LVL 14

Expert Comment

by:SIM50
ID: 41721001
Qlemo is right that it is DPD issue. I would suggest to try and reconfigure the tunnel to use IKEv2. In IKEv2, DPD is a part of the protocol while in IKEv1 it is an extension. If that doesn't work, see if you can upgrade the images.
0
 
LVL 71

Accepted Solution

by:
Qlemo earned 2000 total points
ID: 41721017
A "delete payload" means that either a phase 1 or phase 2 SA should be deleted (is outdated). "Sending" means that your device probably detected the failure, and wants to end the VPN tunnel connection.
Increasing the timeout detection period will lead to a more significant failure than before. The connection will not be dead for 2 minutes until a renegotiation is attempted.

The issue with IPsec VPN tunnels is that sometimes one site knows aout a failure, but the other one does not. Because of different SA states, IPsec packets might get discarded though going thru properly. The correct answer is a Delete payload, but for some reasons that gets ignored, does not arrive. or is not even sent.
The same happens if SAs get out of sync for some reason, e.g. different lifetime and ignoring the lifetime negotiated.
You usually see discard log entries at the receiving end of VPN.

Because of what you showed, I'm certain renegotiation of the tunnel helps, but does not take place in time by itself. For now you could use the sub-optimal workaround to ping every second, allowing 5 failures. This leads to a renegotiation within 5 seconds.
There is no direct way to get informed if the microwave link got interrupted, I assume. If the physical netzwork interface of the microwave sender goes down, and the VPN device is connected directly to it, then the interface coming down will lead to immediate renegotiation.
0
 
LVL 71

Expert Comment

by:Qlemo
ID: 41721022
Yes, IKEv2 (if available) might improve reiliability. Whether it helps here is a different question.
0
 

Author Comment

by:Rupert Eghardt
ID: 41721044
Thank you guys for all the useful information ...

For the past couple of days the communication would just die, and a soft reboot of the local VPN router will renegotiate the channel and restore communication successfully.

We traced the last two VPN communication failures back to a "blip" in the microwave link.

However, today, as I was changing the Detection Period and Applied the communication died immediately after.

I tried several soft reboots, but could not get the VPN communication restored.

I had to reboot the microwave link router,  did another soft reboot on the VPN router, only then was the VPN channel and communication successfully restored.

I am trying to make sense of the "sequence of events" ...

I will in the meantime disable the "KeepAlive" option and enable to the DPD under IKEv2.
0
 

Author Comment

by:Rupert Eghardt
ID: 41724408
Just an update, so far so good.
No down-time yet.

Disabled "KeepAlive", enabled PDP under IKEv2.
0
 
LVL 14

Expert Comment

by:SIM50
ID: 41732048
So you use my solution but give all the points to qlemo?
0
 

Author Comment

by:Rupert Eghardt
ID: 41732052
Solution:  "Qlemo is right that it is DPD issue"

"I would suggest to try and reconfigure the tunnel to use IKEv2"  ... This didn't solve the problem
"In IKEv2, DPD is a part of the protocol while in IKEv1 it is an extension. If that doesn't work, see if you can upgrade the images" .. This didn't solve the problem either.

Solution was DPD config as per Qlemo's posts.
0
 
LVL 14

Expert Comment

by:SIM50
ID: 41732055
Ok,  you weren't clear in your post and made it sound like you switched to IKEv2
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I've written this article to illustrate how we can implement a Dynamic Multipoint VPN (DMVPN) with both hub and spokes having a dynamically assigned non-broadcast multiple-access (NBMA) network IP (public IP). Here is the basic setup of DMVPN Pha…
If you use NetMotion Mobility on your PC and plan to upgrade to Windows 10, it may not work unless you take these steps.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…
Suggested Courses

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question