<div dir="ltr">Well that was it. Once I narrowed down the proposals on both the client and server, everything got happy. <div><br></div><div>When you said that lifetime weren't negotiated in IKEv2 (totally missed that), it got me digging.From the <a href="https://tools.ietf.org/html/rfc7296#section-2.8">RFC</a>:</div><div><br></div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request
the rekeying. If an SA has been inactive for a long time and if an
endpoint would not initiate the SA in the absence of traffic, the
endpoint MAY choose to close the SA instead of rekeying it when its
lifetime expires. It can also do so if there has been no traffic
since the last time the SA was rekeyed.</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><font face="arial, sans-serif">This would lead me to believe if I reduced the server side (responder) lifetime to < 28800, the initiator would never try to re-key. Is that correct? I feel like I tried that scenerio, and the initiator sent a CREATE_CHILD at 8 hours no matter what.</font></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><font face="arial, sans-serif"><br></font></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><font face="arial, sans-serif">This part of the RFC is going back to Microsoft. We'll see if anything gets done about it. At the very least they need to document it.</font></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><br></pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page"> To rekey a Child SA within an existing IKE SA, create a new,
equivalent SA (see <a href="https://tools.ietf.org/html/rfc7296#section-2.17">Section 2.17</a> below), and when the new one is
established, delete the old one. Note that, when rekeying, the new
Child SA SHOULD NOT have different Traffic Selectors and algorithms
than the old one.</pre>
Thanks,</pre><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">Chris.</pre></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 3:36 PM Chris Sherry <<a href="mailto:smilinjoe@gmail.com">smilinjoe@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Tobias,<div><br></div><div>Thanks for the nudge in the right direction. I have narrowed down my proposals to one, and am running a test.</div><div><br></div><div>Thanks,</div><div>Chris.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 11:15 AM Tobias Brunner <<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Chris,<br>
<br>
> What we are seeing is<br>
> the client sending a CREATE_CHILD request around 10 mins before disconnect:<br>
<br>
Sounds like [1].<br>
<br>
> Phase 1 negotiates with a lifetime of 86400 (24 hours):<br>
<br>
Lifetimes are not negotiated with IKEv2.<br>
<br>
> MS doesn't seem to understand what's going on, they<br>
> are keying in on the " 2020-04-29 08:07:48.412275 ike<br>
> 3:ikev2_vpn_0:109665: request msgid = 23, expected 24" error.<br>
<br>
Probably just a retransmit.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="https://wiki.strongswan.org/issues/3400" rel="noreferrer" target="_blank">https://wiki.strongswan.org/issues/3400</a><br>
</blockquote></div>
</blockquote></div>