Once again, Macavity, thanks for your help and advice.

I've just checked with the VPN server provider and they've just suggested turning up the router IKE2 lifetime to 28800 or even 86400, so I guess they have a flexible response to SA policy requests from the router.

So I've banged it all the way up to 86400 and will see what happens from there - I've just exceeded 3600sec so all is well so far..

My understanding is that, ideally, IKE phase 2 should run again when the SA expires creating a new SA policy. I think what is happening in my case is that this IKE phase 2 must be either not occur or be rejected, resulting in the dropped VPN. Then, when it reconnects, a new IKE phase 1 and phase 2 is completed sucessfully and then the VPN runs again for the next period.

So I imagine that this new lifetime setting it will now result in the VPN dropping once a day. I can live with that and I don't mind a regular refresh. I'm also not running highly private or critical network data, so can live with the extended SA period.

As an aside, for others such as myself who are reltively new to networking, I found this Cisco document quite useful in understanding VPNs and IPSEC. Ignore the 'sample chapter' bit, the whole document appears live using the chapter links. Whilst its quite old, it explains the concepts and meanings in a straightforward way.

http://www.ciscopress.com/articles/article.asp?p=24833&seqNum=7

Regards

My understanding is that, ideally, IKE phase 2 should run again when the SA expires creating a new SA policy. I think what is happening in my case is that this IKE phase 2 must be either not occur or be rejected, resulting in the dropped VPN. Then, when it reconnects, a new IKE phase 1 and phase 2 is completed sucessfully and then the VPN runs again for the next period.

Yep, the idea is that the phase 2 gets re-negotiated in time so that it can seamlessly switch from the new phase 2 without any distruption to the tunnel. What appears to be happening to you is the phase 2 is not renegotiating. Why is the question. Speculation is that it could be that one end doesn't take part in the re-negotiation, perhaps it think it's as time X and the other end thinks it at time Y so when time X occurs the other end doesn't take part. Alternatively perhaps there is some protocol mismatch in the renegotiation. Eg one end thinking that PFS will be used, but the other doesn't use PFS or a mismatch in the cipher to be used.

If the VPN keeps disconnecting ever 86400 with the new settings then it might be worth investigating with support (they'd probably need some details regarding the 3rd party device and its configuration), there are some log -wt logs which output what looks like hex garbage and tends to be more trouble than it's worth to debug, but it can be de-coded. I've found that often it's just easier to re-check the IPSEC settings on both ends to find a mismatch in the settings but in your case I wonder if there is some sort of inter-op issue they might find.

You've raised the issue of 'time' which I had considered before but didn't action.

I've been using the default 'pool.ntp.org' as the time set for the router but I've noticed that, when I do a manual 'inquire' the router time is usually corrected by a few seconds.

I've just changed it to 'time.nist.gov'.

I've just 'inquired' again and noticed the router clock changed by a few seconds.

Clearly, the router clock is no accurate atomic clock!

I've set the update interval to 30 seconds.

Lets see if that makes a difference - you never know!

Interesting

Just a final update:

Both VPNs are up for much longer now, anything up to 18 hours, but still drop randomly. Seems to be DPD timeout each time according to the logs.

Anyway, because the uptime is now significantly longer, it doesn't tend to interfer with my internet use or video downloads.

The router does a grand job of reconnecting instantly, so I'm now leaving things as they are.

With regard to the router clock, this is now more stable although I'm not sure why it is always 1 second behind the PC clock, which also uses time.nist.gov.

Anyhow, thanks for your help Macavity.

Consider this one closed.