[strongSwan] Disconnect issue with Windows native client

[Chris Sherry]

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 <smilinjoe at gmail.com> 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 <tobias at strongswan.org>
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200508/cfaf2f10/attachment.html>