Solved

VPN Channel Question

Posted on 2016-07-20
13
105 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
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
 
LVL 68

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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
LVL 68

Accepted Solution

by:
Qlemo earned 500 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 68

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

Control application downtime with dependency maps

Visualize the interdependencies between application components better with Applications Manager's automated application discovery and dependency mapping feature. Resolve performance issues faster by quickly isolating problematic components.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Watchguard Firewall Setup 3 68
small, multi network, problem 3 82
Not able to route between subnets 8 103
Cisco Any Connect Client 5 37
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…
OpenVPN is a great open source VPN server that is capable of providing quick and easy VPN access to your network on the cheap.  By default the software is configured to allow open access to your network.  But what if you want to restrict users to on…
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…

911 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

15 Experts available now in Live!

Get 1:1 Help Now