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
[email protected]



On Fri, Jan 26, 2024 at 4:28 AM William Atwood <[email protected]> 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@Ritchie:~$ sudo ipsec add RIGI6cl
    "RIGI6cl": added IKEv2 connection
    dev@Ritchie:~$

    On Gingko:
    dev@Gingko:~$ sudo ipsec add GIRI6cl
    "GIRI6cl": added IKEv2 connection
    dev@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@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 <[email protected]> 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:[email protected]
    <mailto:email%[email protected]>
    1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill
    Montreal, Quebec Canada H3G 1M8

    _______________________________________________
    Swan mailing list
    [email protected]
    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:[email protected]
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan

Reply via email to