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 <m...@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@thermi.consulting>
<mailto:noel.kuntze+strongswan-users-ml@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
