<div dir="ltr">Hi<div><br></div><div>Sorry, alongwith the probable use of "reqid" i missed mentioning whether you had also tried with using the xfrm-interface-IDs "if_id_in|out in swanctl.conf" ??? in both the peergws???</div><div><br></div><div>best regards</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 25, 2022 at 2:32 PM Marcel Menzel <<a href="mailto:mail@mcl.gg">mail@mcl.gg</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>
<font size="4">Hi Rajiv,<br>
<br>
I already tried this, this would not help. "reqid" is local only
and this information is never being transmitted to the other side
as part of the CHILD_SA establishment, so setting these per hand
on both sides will still end up all tunnels being terminated into
the first matching CHILD_SA on the responder.<br>
<br>
Regards<br>
<br>
- Marcel<br>
</font><br>
<div>Am 25.01.2022 um 07:42 schrieb Rajiv
Kulkarni:<br>
</div>
<blockquote type="cite">
<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
<a href="mailto:noel.kuntze+strongswan-users-ml@thermi.consulting" target="_blank"><noel.kuntze+strongswan-users-ml@thermi.consulting></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">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>
</blockquote>
<br>
</div>
</blockquote></div>