[Swan] [External] : Re: Question on opportunistic ipsec for multiple interfaces on same subnet

Mamta Gambhir mamta.gambhir at oracle.com
Tue Aug 29 07:55:55 EEST 2023


Thanks Paul for looking through this,

Agree our setup is unusual, where each machine has two interfaces on same subnet and each interface communicates using ipsec(customized resiliency without bonding).In this setup opportunistic seemed to fit well  until I ran into this issue.



So I have tried several different types and configuration.

Regarding clear-or-private I was trying to see if I could use “ipsec whack” for opportunistic initiation:  --oppohere <ip-address> --oppothere <ip-address>.

However for now going back to private connection types and our configuration with auto=on-demand/route, I had tried one of the interface as private and another as “private-or-clear” when I didn’t find any other way to configure both interfaces  .

******************Node 1********

conn private-or-clear

        authby=null

        leftid=%null

        rightid=%null

        left=192.168.0.1

        right=%opportunisticgroup

        negotiationshunt=passthrough

        failureshunt=passthrough

        ikev2=insist

        auto=route

        type=transport

conn private

        authby=null

        leftid=%null

        rightid=%null

        left=192.168.0.2

        right=%opportunisticgroup

        negotiationshunt=hold

        failureshunt=drop

        ikev2=insist

        auto=route

        type=transport





*********Node 2***********



conn private-or-clear

        type=transport

        authby=null

        leftid=%null

        rightid=%null

        left=192.168.0.3

        right=%opportunisticgroup

        negotiationshunt=passthrough

        failureshunt=passthrough

        ikev2=insist

        auto=route

conn private

        authby=null

        leftid=%null

        rightid=%null

        left=192.168.0.4

        right=%opportunisticgroup

        negotiationshunt=hold

        failureshunt=drop

        ikev2=insist

        auto=route

        type=transport





Issue - I still had trouble to get the SA establishment for both interfaces , either .1<->.3/.4 works or .2 <->.3/.4.

I needed all to work.



Aug 28 21:11:41 pluto[389280]: packet from 192.168.0.4:500: IKE_AUTH response has no corresponding IKE SA; message dropped

Aug 28 21:12:25 pluto[389280]: initiate on-demand for packet 192.168.0.2:0-ICMP->192.168.0.3:0

Aug 28 21:12:25 pluto[389280]: "private#192.168.0.0/20"[2] ...192.168.0.3 #9: processing decrypted IKE_AUTH request: SK{IDi,IDr,AUTH,SA,TSi,TSr,N(USE_TRANSPORT_MODE)}

Aug 28 21:12:25 pluto[389280]: "private#192.168.0.0/20"[2] ...192.168.0.3 #9: responder established IKE SA; authenticated peer using authby=null and ID_NULL 'ID_NULL'

Aug 28 21:12:25 pluto[389280]: "private#192.168.0.0/20"[2] ...192.168.0.3 #9: did not find old ISAKMP state #0 to mark for suppressing delete

Aug 28 21:12:25 pluto[389280]: "private#192.168.0.0/20"[2] ...192.168.0.3 #9: did not find old IKE state #0 to mark for suppressing delete

Aug 28 21:12: pluto[389280]: "private#192.168.0.0/20"[1] ...192.168.0.3 #8: deleting IKE SA (PARENT_I2) aged 0.005637s and NOT sending notification

Aug 28 21:12:25 pluto[389280]: ERROR: "private#192.168.0.0/20"[1] ...192.168.0.3: kernel: xfrm XFRM_MSG_DELPOLICY delete response for flow (out): No such file or directory (errno 2)

Aug 28 21:12:25 scaz32adm01.us.oracle.com pluto[389280]: "private#192.168.0.0/20"[2] ...192.168.0.3 #11: responder established Child SA using #9; IPsec transport [192.168.0.2-192.168.0.2:0-65535 0] -> [192.168.0.3-192.168.0.3:0-65535 0] {ESP/ESN=>0xeeff7277 <0x4074ac8f x>

Aug 28 21:12:25 pluto[389280]: packet from 192.168.0.3:500: IKE_AUTH response has no corresponding IKE SA; message dropped
*********************************************************************************************

I was hoping  above should be working or will need changes too. I am using equivalent of libreswan 5.0.
Though your suggestion of having multiple private (private/private2)sections will be most appropriate I wasn’t aware of that. Thank you.I am assuming I  will need private2 policies file too.
I am open to try and test the changes as needed in programs/pluto/foodgroups.c to make this work as our goal is to get above going.

Thanks again
Mamta


From: Paul Wouters <paul at nohats.ca>
Date: Monday, August 28, 2023 at 12:04 PM
To: Mamta Gambhir <mamta.gambhir at oracle.com>
Cc: swan at lists.libreswan.org <swan at lists.libreswan.org>
Subject: [External] : Re: [Swan] Question on opportunistic ipsec for multiple interfaces on same subnet
On Sun, 27 Aug 2023, Mamta Gambhir wrote:

> How can I add multiple interfaces setup for opportunistic ipsec via .conf file. I am able to successfully use it for one
> interface(using private,clear-or-private, or private-or-clear), but in my configuration each machine participating has two
> interfaces and both on same subnet.

We have never tried to make that work. It is a bit unusual a setup :P

You can try copying the OE connections (private, clear-or-private, etc
etc to private2, clear-or-private2, etc etc) and changing the left=
for the other IP.

> # cat /etc/ipsec.d/ExaNoCert.conf
>
> conn clear-or-private
>         authby=null
>         leftid=%null
>         rightid=%null
>         left=192.168.0.1
>         right=%opportunisticgroup
>         negotiationshunt=passthrough
>         failureshunt=passthrough
>         ikev2=insist
>         auto=route
>         type=transport

Note that this is unusual. clear-or-private is a "respond only"
connection, so it should have auto=add, not auto=route. The
connection private-or-clear would be the one that has auto=route

> # cat /etc/ipsec.d/policies/clear-or-private
>
> 192.168.0.0/20

I'm not sure if this will be picked up by the new connection names :/
It might not without some little tweaking in the code (programs/pluto/foodgroups.c)
We could look at adding an option that sets the opportunistic group name
in the connection so the "private2" could set the group name to
"private".

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230829/10001b89/attachment-0001.htm>


More information about the Swan mailing list