<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi Rajiv,<br>
    <br>
    Yes, they're needed in my setup to actually assign a CHILD_SA to a
    XFRM interface, as described here:
<a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Configuration-2">https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Configuration-2</a><br>
    This is also just a local option, and in my case different
    assignments, because xfrm0 on the initiator will be terminated in
    xfrm3 on the responder.<br>
    <br>
    Regards<br>
    <br>
    - Marcel<br>
    <br>
    <div class="moz-cite-prefix">Am 25.01.2022 um 11:52 schrieb Rajiv
      Kulkarni:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+35gnSkXXSS7n3GXLAipkmUsZ63bz=v8Bn4Ckq-0ZCH8CPgSA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
            moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"><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"
                    moz-do-not-send="true">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>
    </blockquote>
    <br>
  </body>
</html>