Solved

VPN Channel Question

Posted on 2016-07-20
13
99 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
  • 6
  • 4
  • 3
13 Comments
 
LVL 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
Thanks Qlemo,

I will configure DPD and see if this helps.
0
 

Author Comment

by:Rupert Eghardt
Comment Utility
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
 
LVL 68

Expert Comment

by:Qlemo
Comment Utility
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
Comment Utility
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 13

Expert Comment

by:SIM50
Comment Utility
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
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 68

Accepted Solution

by:
Qlemo earned 500 total points
Comment Utility
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 68

Expert Comment

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

Author Comment

by:Rupert Eghardt
Comment Utility
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
Comment Utility
Just an update, so far so good.
No down-time yet.

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

Expert Comment

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

Author Comment

by:Rupert Eghardt
Comment Utility
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 13

Expert Comment

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

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Juniper VPN devices are a popular alternative to using Cisco products. Last year I needed to set up an international site-to-site VPN over the Internet, but the client had high security requirements -- FIPS 140. What and Why of FIPS 140 Federa…
Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
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…
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…

771 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

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now