Well that was it. Once I narrowed down the proposals on both the client and server, everything got happy.
When you said that lifetime weren't negotiated in IKEv2 (totally missed that), it got me digging.From the RFC <https://tools.ietf.org/html/rfc7296#section-2.8>: 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. 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. 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. To rekey a Child SA within an existing IKE SA, create a new, equivalent SA (see Section 2.17 <https://tools.ietf.org/html/rfc7296#section-2.17> 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. Thanks, Chris. On Thu, May 7, 2020 at 3:36 PM Chris Sherry <[email protected]> wrote: > Tobias, > > Thanks for the nudge in the right direction. I have narrowed down my > proposals to one, and am running a test. > > Thanks, > Chris. > > On Thu, May 7, 2020 at 11:15 AM Tobias Brunner <[email protected]> > wrote: > >> Hi Chris, >> >> > What we are seeing is >> > the client sending a CREATE_CHILD request around 10 mins before >> disconnect: >> >> Sounds like [1]. >> >> > Phase 1 negotiates with a lifetime of 86400 (24 hours): >> >> Lifetimes are not negotiated with IKEv2. >> >> > MS doesn't seem to understand what's going on, they >> > are keying in on the " 2020-04-29 08:07:48.412275 ike >> > 3:ikev2_vpn_0:109665: request msgid = 23, expected 24" error. >> >> Probably just a retransmit. >> >> Regards, >> Tobias >> >> [1] https://wiki.strongswan.org/issues/3400 >> >
