[strongSwan] Multiple CHILD_SA in one IKE_SA with same TS

[Marcel Menzel]

Hi Rajiv,

Yes, they're needed in my setup to actually assign a CHILD_SA to a XFRM 
interface, as described here: 
https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#Configuration-2
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.

Regards

- Marcel

Am 25.01.2022 um 11:52 schrieb Rajiv Kulkarni:
> Hi
>
> 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???
>
> best regards
>
>
> On Tue, Jan 25, 2022 at 2:32 PM Marcel Menzel <mail at mcl.gg> wrote:
>
>     Hi Rajiv,
>
>     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.
>
>     Regards
>
>     - Marcel
>
>     Am 25.01.2022 um 07:42 schrieb Rajiv Kulkarni:
>>     Hi
>>
>>     would setting this "reqid" option for each of the tunnels (with
>>     different left-righ-IDs set) in both initiator and responder
>>     peers help?
>>
>>     The below is the setting that is available (in swanctl.conf):
>>     ------------------------------------------------------------------------------------------------------------------------------------
>>     connections.<conn>.children.<child>.reqid = <0(default-value)>
>>     - 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.
>>     - The default of 0 uses dynamic reqids, allocated incrementally.
>>     -------------------------------------------------------------------------------------------------------------------------------
>>
>>     regards
>>     Rajiv
>>
>>
>>
>>     On Tue, Jan 25, 2022 at 1:19 AM Noel Kuntze
>>     <noel.kuntze+strongswan-users-ml at thermi.consulting>
>>     <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
>>
>>         Hello Marcel,
>>
>>         You already found the only good solution to the problem.
>>         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.
>>
>>         Kind regards
>>         Noel
>>
>>         Am 24.01.22 um 10:48 schrieb Marcel Menzel:
>>         > Hello List,
>>         >
>>         > I am connecting multiple XFRM interfaces, each being in a
>>         different VRF, between two servers running strongSwan 5.9.4.
>>         >
>>         > As I am running dynamic routing protocols over those XFRM
>>         interfaces, all traffic selectors of the CHILD_SAs have been
>>         set to 0.0.0.0/0 <http://0.0.0.0/0> & ::/0.
>>         >
>>         > 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.
>>         >
>>         > 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?
>>         >
>>         >
>>         > Thanks
>>         >
>>         >   - Marcel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220125/9d506649/attachment.html>