Here is the result of the status command, on Ritchie (running 5.0 RC1):
dev@Ritchie:~$ sudo ipsec status | grep interface
[sudo] password for dev:
using kernel interface: xfrm
interface lo UDP [::1]:4500
interface lo UDP [::1]:500
interface lo UDP 127.0.0.1:4500
interface lo UDP 127.0.0.1:500
interface enp4s0 UDP 132.205.9.46:4500
interface enp4s0 UDP 132.205.9.46:500
interface enp5s4 UDP 132.205.9.50:4500
interface enp5s4 UDP 132.205.9.50:500
interface enp5s5 UDP 132.205.9.53:4500
interface enp5s5 UDP 132.205.9.53:500
interface virbr0 UDP 192.168.123.1:4500
interface virbr0 UDP 192.168.123.1:500
"RITA6c": conn_prio: 128,128; interface: ; metric: 0; mtu: unset;
sa_prio:auto; sa_tfc:none;
dev@Ritchie:~$
The connection appears to be "partly up", but it has no interface that
it is listening on.
In contrast, the same command on Tarjan (running 4.12) shows interface
ens7 for connection TARI6c (which is the other end of the SA).
dev@Tarjan:~$ sudo ipsec status | grep interface
[sudo] password for dev:
000 using kernel interface: xfrm
000 interface ens7 UDP [fd51:20d9:5ad2:b::1]:4500
000 interface ens7 UDP [fd51:20d9:5ad2:b::1]:500
000 interface eno1 UDP [fd51:20d9:5ad2:9::1]:4500
000 interface eno1 UDP [fd51:20d9:5ad2:9::1]:500
000 interface lo UDP [::1]:4500
000 interface lo UDP [::1]:500
000 interface lo UDP 127.0.0.1:4500
000 interface lo UDP 127.0.0.1:500
000 interface eno1 UDP 132.205.9.37:4500
000 interface eno1 UDP 132.205.9.37:500
000 interface ens6 UDP 132.205.9.41:4500
000 interface ens6 UDP 132.205.9.41:500
000 interface ens7 UDP 132.205.9.45:4500
000 interface ens7 UDP 132.205.9.45:500
000 interface virbr0 UDP 192.168.123.1:4500
000 interface virbr0 UDP 192.168.123.1:500
000 "TAPE6c": conn_prio: 128,128; interface: eno1; metric: 0; mtu:
unset; sa_prio:auto; sa_tfc:none;
000 "TARI6c": conn_prio: 128,128; interface: ens7; metric: 0; mtu:
unset; sa_prio:auto; sa_tfc:none;
000 "mytunnel": conn_prio: 32,32; interface: eno1; metric: 0; mtu:
unset; sa_prio:auto; sa_tfc:none;
000 "tape6": conn_prio: 128,128; interface: ; metric: 0; mtu: unset;
sa_prio:auto; sa_tfc:none;
dev@Tarjan:~$
(Note that the connections TAPE6c, mytunnel, and tape6 are left over
from previous experiments.)
Then, I edited RITA6c to remove the auto=add, restarted the daemon on
Ritchie, and then did the "add" and "up" commands manually:
dev@Ritchie:~$ sudo ipsec setup restart
Redirecting to: systemctl restart ipsec.service
dev@Ritchie:~$ sudo ipsec status |grep interface
using kernel interface: xfrm
interface lo UDP [::1]:4500
interface lo UDP [::1]:500
interface lo UDP 127.0.0.1:4500
interface lo UDP 127.0.0.1:500
interface enp4s0 UDP 132.205.9.46:4500
interface enp4s0 UDP 132.205.9.46:500
interface enp5s4 UDP 132.205.9.50:4500
interface enp5s4 UDP 132.205.9.50:500
interface enp5s5 UDP 132.205.9.53:4500
interface enp5s5 UDP 132.205.9.53:500
interface virbr0 UDP 192.168.123.1:4500
interface virbr0 UDP 192.168.123.1:500
dev@Ritchie:~$ sudo ipsec add RITA6c
"RITA6c": added IKEv2 connection
dev@Ritchie:~$ sudo ipsec status |grep interface
using kernel interface: xfrm
interface lo UDP [::1]:4500
interface lo UDP [::1]:500
interface lo UDP 127.0.0.1:4500
interface lo UDP 127.0.0.1:500
interface enp4s0 UDP 132.205.9.46:4500
interface enp4s0 UDP 132.205.9.46:500
interface enp5s4 UDP 132.205.9.50:4500
interface enp5s4 UDP 132.205.9.50:500
interface enp5s5 UDP 132.205.9.53:4500
interface enp5s5 UDP 132.205.9.53:500
interface virbr0 UDP 192.168.123.1:4500
interface virbr0 UDP 192.168.123.1:500
"RITA6c": conn_prio: 128,128; interface: ; metric: 0; mtu: unset;
sa_prio:auto; sa_tfc:none;
dev@Ritchie:~$ sudo ipsec up RITA6c
"RITA6c": we cannot identify ourselves with either end of this
connection. fd51:20d9:5ad2:b::2 or fd51:20d9:5ad2:b::1 are not usable
dev@Ritchie:~$ sudo ipsec status |grep interface
using kernel interface: xfrm
interface lo UDP [::1]:4500
interface lo UDP [::1]:500
interface lo UDP 127.0.0.1:4500
interface lo UDP 127.0.0.1:500
interface enp4s0 UDP 132.205.9.46:4500
interface enp4s0 UDP 132.205.9.46:500
interface enp5s4 UDP 132.205.9.50:4500
interface enp5s4 UDP 132.205.9.50:500
interface enp5s5 UDP 132.205.9.53:4500
interface enp5s5 UDP 132.205.9.53:500
interface virbr0 UDP 192.168.123.1:4500
interface virbr0 UDP 192.168.123.1:500
"RITA6c": conn_prio: 128,128; interface: ; metric: 0; mtu: unset;
sa_prio:auto; sa_tfc:none;
dev@Ritchie:~$
NOTES on the above:
1) The output from the status command is identical for these two instances.
2) The daemon is NOT waiting on any IPv6 address (except on device "lo").
COMMENTS:
I am _not_ familiar with the Libreswan code. However, I go back to my
comments to this list on 2023-12-19 about "The XFRM address scope must
be global", for which a reply was given on 2023-12-26 by Andrew.
A Unique Local Address (ULA) is not global, but it is routable. It is
certainly valid as an endpoint for an SA.
A Link-Local (LL) address is clearly not global, but it is certainly
valid as an endpoint for an SA between two adjacent hosts. However,
because it is not routable, it MUST be accompanied by an interface
identifier. The use case is required by RFC 8994, and is the subject of
issue #1498.
What I am reporting here is a different, but related issue. ULAs worked
in version 4.12. They no longer work in 5.0 RC1. Fixing issue #1498
may also fix this problem, or it may not.
Do you want me to raise a separate issue for this case? As Andrew said
for issue #1498, the use of "%<intf> needs a rethink; my belief is that
the specification of addresses (especially for IPv6) needs to be
carefully reconsidered. My 2cents.
Bill
On 1/14/2024 9:51 AM, Andrew Cagney wrote:
On Sat, 13 Jan 2024 at 18:13, Bill Atwood <[email protected]> wrote:
??
I do not understand your reply.
Offhand, it looks like the connection should match:
conn RITA6c
left=fd51:20d9:5ad2:b::2
leftid="CN=Ritchie Certificate"
leftrsasigkey=%cert
leftcert=RIcert
right=fd51:20d9:5ad2:b::1
rightid="CN=Tarjan Certificate"
rightrsasigkey=%cert
auto=add
the interface:
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd51:20d9:5ad2:b::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21a:a0ff:fe15:62b8/64 scope link
valid_lft forever preferred_lft forever
yet the output indicates that it couldn't vis:
"RITA6c": we cannot identify ourselves with either end of this
connection. fd51:20d9:5ad2:b::2 or fd51:20d9:5ad2:b::1 are not usable
Two things to try:
- confirm that librreswan is listening on those interfaces vis:
ipsec status | grep interface
- drop the auto=add from the connection and then run:
ipsec add RITA6c
ipsec up RITA6c
manually and confirm the problem persists.
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
