Understood, thank you very much for the clarification!<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018, 6:48 PM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Honestly, I thought that for IKEv2 multiple traffic selectors<br>
> are possible anyway.<br>
<br>
Unfortunately, there are implementations that don't support it.<br>
<br>
> Also, I was confused about the subnets because with<br>
> ipsec statusall it shows different rekey time values for different<br>
> policies which include traffic selectors (ip.net1 === ip.net2).<br>
<br>
So you already have separate CHILD_SAs for these (possibly initiated by<br>
the peer, or narrowed by it).  But to make this work properly your<br>
config has to reflects that.<br>
<br>
> Strongswan also prints "creating rekey job for CHILD_SA ESP/0x12345678/"<br>
> to the log file, which made me think it should rekey only this<br>
> particular SA, with a particular SPI, matching specific source and<br>
> destination (TS).<br>
<br>
Single CHILD_SAs are rekeyed, but the complete local CHILD_SA config is<br>
used for the proposal (i.e. multiple TS if that's what you have<br>
configured locally).  If a responder that doesn't support multiple TS<br>
doesn't consider the TS of the rekeyed CHILD_SA, but just blindly uses<br>
the first proposed TS, that's problematic (i.e. you must change the<br>
config to reflect that limitation).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><p dir="ltr">BR, Kseniya</p>
</div>