[Swan] LibreSWAN and IPv6 Link Local addresses
William Atwood
william.atwood at concordia.ca
Fri Jan 26 19:31:51 EET 2024
Brady,
I am not trying to create a user-level interface with a specific
address. I am trying to get Libreswan to accept that a given, existing
Link-Local (LL) address is a valid endpoint for a Security Association.
Please read issue #1498 on the Github site for the details. The message
was intended to demonstrate to Tuomo that Libreswan actively asserts
that LL addresses are not acceptable.
Bill
On 1/26/2024 8:38 AM, Brady Johnson wrote:
>
> Attention This email originates from outside the concordia.ca domain.
> // Ce courriel provient de l'extérieur du domaine de concordia.ca
>
>
>
>
> Bill,
>
> To be able to "invoke" XFRM in the config you listed, you need to add
> the following 2 parameters:
>
> ipsec-interface=1
> leftinterface-ip=<your IPv6 with netmask>
>
>
> The "ipsec-interface=1" parameter will create an interface called
> ipsec01, and the other parameter will set the IP on that interface.
>
> Regards,
>
> *Brady Johnson*
> Principal Software Engineer
> Telco Solutions & Enablement
> brady.johnson at redhat.com
>
>
>
> On Fri, Jan 26, 2024 at 4:28 AM William Atwood
> <william.atwood at concordia.ca> wrote:
>
> Tuomo,
>
> I apologize for disagreeing, but Libreswan not only does not support
> Link-Local addresses, but it actively declares that they are not
> usable.
> I agree that making Libreswan process Link-Local addresses properly
> will not be possible until XFRM is fixed, but in the case outlined
> below, it appears that XFRM is not even invoked.
>
> I have two hosts, with a shared LAN, called Gingko and Ritchie, both
> running Libreswan 5.0rc1.
>
> File GIRI6CL.conf on Gingko:
> conn GIRI6cl
> left=fe80::20e:cff:fe9c:d92d%ens7
> leftid="CN=Gingko Certificate"
> leftrsasigkey=%cert
> leftcert=GIcert
> right=fe80::20e:cff:fea9:b90f%ens7
> rightid="CN=Ritchie Certificate"
> rightrsasigkey=%cert
> auto=add
>
> File RIGI6CL.conf on Ritchie:
> conn RIGI6cl
> left=fe80::20e:cff:fea9:b90f%enp5s4
> leftid="CN=Ritchie Certificate"
> leftrsasigkey=%cert
> leftcert=RIcert
> right=fe80::20e:cff:fe9c:d92d%enp5s4
> rightid="CN=Gingko Certificate"
> rightrsasigkey=%cert
> auto=add
>
> On Ritchie:
> dev at Ritchie:~$ sudo ipsec add RIGI6cl
> "RIGI6cl": added IKEv2 connection
> dev at Ritchie:~$
>
> On Gingko:
> dev at Gingko:~$ sudo ipsec add GIRI6cl
> "GIRI6cl": added IKEv2 connection
> dev at Gingko:~$ sudo ipsec up GIRI6cl
> "GIRI6cl": we cannot identify ourselves with either end of this
> connection. fe80::20e:cff:fe9c:d92d or fe80::20e:cff:fea9:b90f
> are not
> usable
> dev at Gingko:~$
>
> The listed Link-Local addresses are correct; I can " ping -6
> fe80::20e:cff:fea9:b90f%ens7" on Gingko, and get the appropriate
> response from Ritchie, and I can " ping -6
> fe80::20e:cff:fe9c:d92d%enp5s4" from Ritchie, and get the appropriate
> response from Gingko.
>
> Finally, if I assign Unique Local Addresses to the same two
> interfaces,
> and use these addresses in the above .conf files, the Security
> Association establishes perfectly.
>
> Therefore, I believe that your statement that "Global is only used
> when
> adding IP for XFRM interface for route-based IPsec vpn." is
> incorrect.
> Clearly, Libreswan has code somewhere that is rejecting non-global
> addresses for simple, tunnel-mode Security Associations between two
> adjacent hosts.
>
> Andrew has put a milestone of Release 5.1 on my issue #1498, which
> provides justification for the use of Link-Local addresses as valid
> endpoints. I hope that XFRM has been fixed by the time 5.1 is
> released.
>
> Bill
>
> On 1/17/2024 1:24 AM, Tuomo Soini wrote:
> > Attention This email originates from outside the concordia.ca
> <http://concordia.ca/> domain. // Ce courriel provient de
> l'extC)rieur du domaine de concordia.ca <http://concordia.ca/>
> >
> > On Tue, 16 Jan 2024 21:17:41 -0500
> > William Atwood <william.atwood at concordia.ca> wrote:
> >
> >> 1) I know that Libreswan does not support %zone identifiers
> >> associated with Link-Local (LL) addresses, and it appears from your
> >> experience that Strongswan does not either. I also know that
> >> Libreswan insists that an endpoint address must be "Global".
> >
> > Global is only used when adding IP for XFRM interface for
> route-based
> > IPsec vpn. And because this is route-based, this can't be
> LL-address.
> > We told you multiple times that this doesn't affect LL address
> > handling. And we can't really implement support for LL addresses on
> > linux before XFRM/IPsec stack supports it.
> >
>
> --
> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
> Distinguished Professor Emeritus fax: +1 (514) 848-2830
> Department of Computer Science
> and Software Engineering
> Concordia University ER 1234 email:william.atwood at concordia.ca
> <mailto:email%3Awilliam.atwood at concordia.ca>
> 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
> Montreal, Quebec Canada H3G 1M8
>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>
--
Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046
Distinguished Professor Emeritus fax: +1 (514) 848-2830
Department of Computer Science
and Software Engineering
Concordia University ER 1234email:william.atwood at concordia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20240126/13d0c8fe/attachment-0001.htm>
More information about the Swan
mailing list