(continued from " 5.0 RC1 connection not found", with changed subject,
because this is a new error).
After renaming RITA6C to RITA6C.conf, I ran:
sudo ipsec add RITA6c
which reported that an IPsec connection had been established.
However:
ip addr show
did *not* show the new interface. Subsequently running
sudo ipsec up RITA6c
produced the following error message:
"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
Since Andrew had suggested that "addcon" had a --verbose option, I went
back and tried:
dev@Ritchie:~$ sudo ipsec addconn --verbose RITA6c
opening file: /etc/ipsec.conf
debugging mode enabled
including file '/etc/ipsec.d/*.conf' ('/etc/ipsec.d/*.conf') from
/etc/ipsec.conf:80
end of file /etc/ipsec.d/RITA6C.conf
resuming /etc/ipsec.conf:80
end of file /etc/ipsec.conf
Loading conn RITA6c
loading named conns: RITA6c
resolving family=IPv6 src=fd51:20d9:5ad2:b::2 gateway=<not-set> peer
fd51:20d9:5ad2:b::1
seeking NOTHING
resolving family=IPv6 src=fd51:20d9:5ad2:b::1 gateway=<not-set> peer
fd51:20d9:5ad2:b::2
seeking NOTHING
"RITA6c": terminating SAs using this connection
"RITA6c": added IKEv2 connection
dev@Ritchie:~$
The two addresses (beginning with "fd51") are Unique Local Addresses
(ULA), and are _perfectly_valid_IPv6_ addresses. I am building an IPsec
tunnel between two adjacent hosts, which are on the same LAN, and the
assigned address for each interface is declared to be a /64, so the
kernel knows how to reach the peer.
dev@Ritchie:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
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
3: enp5s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::20e:cff:fea9:b90f/64 scope link
valid_lft forever preferred_lft forever
4: enp5s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::20e:cff:fea9:b937/64 scope link
valid_lft forever preferred_lft forever
dev@Ritchie:~$
Please remove whatever constraints are built into Libreswan that exclude
non-global addresses. (OR, provide a toggle that allows the use of ULAs)
As I have discussed previously on this list, please note that,
eventually, once XFRM is fixed to properly handle Link-Local addresses
(and their associated interface names), then Libreswan will need to
accept LL addresses as well.
Bill Atwood
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
