• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 153
  • Last Modified:

VPN Channel Question

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
Rupert Eghardt
Asked:
Rupert Eghardt
  • 6
  • 4
  • 3
1 Solution
 
QlemoC++ DeveloperCommented:
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
 
Rupert EghardtAuthor Commented:
Thanks Qlemo,

I will configure DPD and see if this helps.
0
 
Rupert EghardtAuthor Commented:
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
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
QlemoC++ DeveloperCommented:
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
 
Rupert EghardtAuthor Commented:
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
 
SIM50Commented:
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
 
QlemoC++ DeveloperCommented:
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
 
QlemoC++ DeveloperCommented:
Yes, IKEv2 (if available) might improve reiliability. Whether it helps here is a different question.
0
 
Rupert EghardtAuthor Commented:
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
 
Rupert EghardtAuthor Commented:
Just an update, so far so good.
No down-time yet.

Disabled "KeepAlive", enabled PDP under IKEv2.
0
 
SIM50Commented:
So you use my solution but give all the points to qlemo?
0
 
Rupert EghardtAuthor Commented:
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
 
SIM50Commented:
Ok,  you weren't clear in your post and made it sound like you switched to IKEv2
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now