<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi Geordie,</div><div><br></div><div>Did you end up getting to the bottom of this? </div><div><div><br></div><blockquote type="cite"><div dir="ltr">LIfetime is an hour / 4608000KB. Group 2, PFS, NAT-T, fairly boring policy and proposals. It's dropping every half hour more or less on the half hour and comes back up a few seconds later. The reason I was staring at the NTP shift is it's obviously something happening on a very regular schedule and the drops are very regular too.</div></blockquote></div><div><br></div><div>I just got back in front of a Netscreen/SSG:</div><div><br></div><div>SSG default P1 is 28800, default P2 is 3600.</div><div><br></div><div>According to Cisco[1]:</div><div><br></div><div>ASA default P1 is 86400, default P2 is 28800.</div><div>IOS default P1 is 86400, default P2 is 3600.</div><div><br></div><div>Not sure if the lifetime you're providing above is ISAKMP or IPSEC (assuming the latter), but having a timer mismatch in configuration will still bring up the tunnel - but cause issues like you describe when the hub side tears down the SA and can't re-establish it because the peer is behind a NAT or similar.</div><div><br></div><div>NTP is not used - expiry of P1/P2 in a PSK IPSEC environment is a simple count down timer and not based on a specific timestamp. </div><div><br></div><div>In an PKI-based IPSEC environment, the system clock is used only to confirm certificate validity, so again, minor (or even major) skew won't break anything. If you let your certificates expire, you might find one end goes invalid before the other, but that's about it.</div><div><br></div><div>Feel free to unicast any config/logs if you're stuck.</div><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div></span></span>
</div>
<div>[1] Assuming you are using Cisco: <a href="https://supportforums.cisco.com/docs/DOC-25467">https://supportforums.cisco.com/docs/DOC-25467</a></div><br><div><blockquote type="cite"><div dir="ltr"><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 6, 2014 at 3:13 PM, Colin Stubbs <span dir="ltr"><<a href="mailto:colin.stubbs@equatetechnologies.com.au" target="_blank">colin.stubbs@equatetechnologies.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Very unlikely to be directly a time/NTP issue if it's that small a difference.</div><div><br>
</div><div>Encryption and authentication with basic IPSec PSK type configurations isn't dependent on time synchronisation with peers. </div>
<div><br></div><div>Expiry of negotiated phase 1/2 parameters might happen if there was a larger skew, e.g. minutes/hours.</div><div class="gmail_extra"><div><div dir="ltr"><br></div></div>
I'd lean towards a phase 2 renegotiation failure. Or software bug triggered by time skew and adjustment.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>What are the phase 1 and 2 parameters for each side of the tunnel ? e.g. lifetime in seconds and/or bytes ?</div>
<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 6 January 2014 13:09, Geordie Guy <span dir="ltr"><<a href="mailto:elomis@gmail.com" target="_blank">elomis@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">G'day NOGgers,<div>
<br></div><div>We have an IPSEC peer that keeps dropping the tunnel and renegotiating. The only events in the logs on their side that look like they could be related are a fairly constant NTP update which is causing their Netscreen to adjust by between 3 and 13 milliseconds every ten minutes. Would this cause the tunnel to renegotiate when the clock changed? It seems to happen on the half hour every half hour, or every three NTP updates.</div>
<span><font color="#888888">
<div><br></div><div>- Geordie</div></font></span></div>
<br></div></div>_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></div>
_______________________________________________<br>AusNOG mailing list<br><a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>http://lists.ausnog.net/mailman/listinfo/ausnog<br></blockquote></div><br></body></html>