Hello,
We were trying to configure LibreSwan opportunistic IPSec in a cluster with
the next configuration.
conn private
type=tunnel
left=%defaultroute
leftid=%fromcert
# our certificate
leftcert="NSS Certificate DB:vm0"
right=%opportunisticgroup
rightid=%fromcert
# their certificate transmitted via IKE
rightca=%same
ikev2=insist
authby=rsasig
failureshunt=drop
negotiationshunt=hold
auto=ondemand
conn clear
left=%defaultroute
right=%group
type=passthrough
auto=route
priority=65535
IP ranges configurations:
[root@vm0 ipsec.d]# cat policies/clear
0.0.0.0/0
[root@vm0 ipsec.d]# cat policies/private
10.0.0.0/24
The expectation is: IPSec is enforced in the cluster subnet & clear is
allowed for everything else.
First, we didn't set a priority, but clear connection has higher priority
than private in that case.
When we lower clear priority, libreswan fails to establish a tunnel.
Here'is a set of relevant logs:
1: conn_prio for clear is higher than private.
[root@vm0 ipsec.d]# ipsec barf | grep conn_prio
000 "clear": conn_prio: 32,32; interface: eth0; metric: 0; mtu: unset;
sa_prio:65535; sa_tfc:none;
000 "clear#0.0.0.0/0": conn_prio: 32,32; interface: eth0; metric: 0; mtu:
unset; sa_prio:65535; sa_tfc:none;
000 "private": conn_prio: 32,0; interface: eth0; metric: 0; mtu: unset;
sa_prio:auto; sa_tfc:none;
000 "private#10.0.0.0/24": conn_prio: 32,0; interface: eth0; metric: 0;
mtu: unset; sa_prio:auto; sa_tfc:none;
000 "private#10.0.0.0/24"[1]: conn_prio: 32,0; interface: eth0; metric:
0; mtu: unset; sa_prio:auto; sa_tfc:none;
2. As a result, find_connection function selects clear connection as the
better option
3. However, find_connection function reset best to NULL for NEVER_NEGOTIATE
connections (and clear is one them)
[root@erwelchipsecvm-000000 ipsec.d]# cat /var/log/pluto.log | grep
find_conne
Nov 15 15:32:20.434481: | find_connection: looking for policy for
connection: 10.0.0.4:17/36303 -> 10.0.0.5:17/1025
Nov 15 15:32:20.434488: | find_connection: conn "clear#0.0.0.0/0" 0.0.0.0
has compatible peers: 10.0.0.4/32 -> 0.0.0.0/0 [pri: 16842768]
Nov 15 15:32:20.434493: | find_connection: first OK "clear#0.0.0.0/0"
0.0.0.0 [pri:16842768]{0x7fdc68319868} (child none)
Nov 15 15:32:20.434498: | find_connection: conn "private#10.0.0.0/24" has
compatible peers: 10.0.0.4/32 -> 10.0.0.0/24 [pri: 16777224]
Nov 15 15:32:20.434504: | find_connection: comparing best "clear#0.0.0.0/0"
0.0.0.0 [pri:16842768]{0x7fdc68319868} (child none) to "private#10.0.0.0/24"
[pri:16777224]{0x7fdc68319d88} (child none)
Nov 15 15:32:20.434508: | find_connection: concluding with empty
So, as a result, libreswan thinks there is no routed template that covers
this pair:
10.0.0.4/32:36303 -17-> 10.0.0.5/32:1025 => %hold 0 no routed template
covers this pair
So, two questions I have:
1. Do our expectation make sense or is it some weird usage pattern? (Any
other ways to achieve this?)
2. If #1 is yes, do you think this is a bug? Does it make sense to exclude
NEVER_NEGOTIATE connections from find_connections() code? Something like
this:
programs/pluto/connections.c :2395
if (!NEVER_NEGOTIATE(c) && (best == NULL || prio > best_prio)) {
best = c;
best_sr = sr;
best_prio = prio;
}
Kirill.
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
