VPN Channel Question

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?

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 EghardtProgrammerAuthor Commented: 2016-07-20

Thanks Qlemo,

I will configure DPD and see if this helps.

0

Rupert EghardtProgrammerAuthor Commented: 2016-07-20

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

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

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.

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.

"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.