<div dir="ltr">Hi<div><br></div><div>would setting this "reqid" option for each of the tunnels (with different left-righ-IDs set) in both initiator and responder peers help? </div><div><br></div><div>The below is the setting that is available (in swanctl.conf):</div><div>------------------------------------------------------------------------------------------------------------------------------------</div><div>connections.<conn>.children.<child>.reqid = <0(default-value)><br>- Fixed reqid to use for this CHILD_SA. This might be helpful in some scenarios, but works only if each CHILD_SA configuration is instantiated not more than once. <br>- The default of 0 uses dynamic reqids, allocated incrementally.<br>-------------------------------------------------------------------------------------------------------------------------------</div><div><br></div><div>regards</div><div>Rajiv</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 25, 2022 at 1:19 AM Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> 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">Hello Marcel,<br>
<br>
You already found the only good solution to the problem.<br>
The general problem is that there's no way to identify any specific CHILD_SA because there are no markers or authentication procedures, or ways to match them by establishment order.<br>
<br>
Kind regards<br>
Noel<br>
<br>
Am 24.01.22 um 10:48 schrieb Marcel Menzel:<br>
> Hello List,<br>
> <br>
> I am connecting multiple XFRM interfaces, each being in a different VRF, between two servers running strongSwan 5.9.4.<br>
> <br>
> As I am running dynamic routing protocols over those XFRM interfaces, all traffic selectors of the CHILD_SAs have been set to <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> & ::/0.<br>
> <br>
> Now, the responder is not being able to distinguish between the CHILD_SAs anymore (due to the same TS) for one IKE_SA and all the CHILD_SAs of the initiator end up in the same (the first) CHILD_SA in the responder, meaning the different XFRM interfaces of the initiator are being terminated all in the same XFRM interface of the responder.<br>
> <br>
> My current workaround is to create one IKE_SA per CHILD_SA as I am able to set the local and remote ID in the IKE_SA and use these to distinguish the tunnels as the local and remote addresses are the same aswell. Unfortunately. the CHILD_SA parameter "reqid" is a local setting only and looking at the docs I can't see another way to set some "ID" of some sort to be able to distinguish between overlapping/identical traffic selectors. Am I missing something here or is this the only possible workaround?<br>
> <br>
> <br>
> Thanks<br>
> <br>
>   - Marcel<br>
</blockquote></div>