<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello,<div><br></div><div>We were trying to configure LibreSwan opportunistic IPSec in a cluster with the next configuration.</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><font face="monospace, monospace">conn private                                                           </font></div></div></div><div><div><font face="monospace, monospace">        type=tunnel                                                    </font></div></div><div><div><font face="monospace, monospace">        left=%defaultroute                                             </font></div></div><div><div><font face="monospace, monospace">        leftid=%fromcert                                               </font></div></div><div><div><font face="monospace, monospace">        # our certificate                                              </font></div></div><div><div><font face="monospace, monospace">        leftcert="NSS Certificate DB:vm0"            </font></div></div><div><div><font face="monospace, monospace">        right=%opportunisticgroup                                      </font></div></div><div><div><font face="monospace, monospace">        rightid=%fromcert                                              </font></div></div><div><div><font face="monospace, monospace">        # their certificate transmitted via IKE                        </font></div></div><div><div><font face="monospace, monospace">        rightca=%same                                                  </font></div></div><div><div><font face="monospace, monospace">        ikev2=insist                                                   </font></div></div><div><div><font face="monospace, monospace">        authby=rsasig                                                  </font></div></div><div><div><font face="monospace, monospace">        failureshunt=drop                                              </font></div></div><div><div><font face="monospace, monospace">        negotiationshunt=hold                                          </font></div></div><div><div><font face="monospace, monospace">        auto=ondemand                                                  </font></div></div><div><div><font face="monospace, monospace">                                                                       </font></div></div><div><div><font face="monospace, monospace">conn clear                                                             </font></div></div><div><div><font face="monospace, monospace">        left=%defaultroute                                             </font></div></div><div><div><font face="monospace, monospace">        right=%group                                                   </font></div></div><div><div><font face="monospace, monospace">        type=passthrough                                               </font></div></div><div><div><font face="monospace, monospace">        auto=route</font></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">        priority=65535         </font>               </div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><br></div></div></blockquote>IP ranges configurations:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="monospace, monospace">[root@vm0 ipsec.d]# cat policies/clear</font></div></div><div><div><font face="monospace, monospace"><a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a></font></div></div><div><div><font face="monospace, monospace">[root@vm0 ipsec.d]# cat policies/private</font></div></div><div><div><font face="monospace, monospace"><a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>             </font>                </div></div><div><br></div></blockquote>The expectation is: IPSec is enforced in the cluster subnet & clear is allowed for everything else.<div>First, we didn't set a priority, but clear connection has higher priority than private in that case.<br><div>When we lower clear priority, libreswan fails to establish a tunnel.</div></div><div>Here'is a set of relevant logs:</div><div><br></div><div>1: conn_prio for clear is higher than private.</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><font face="monospace, monospace">[root@vm0 ipsec.d]# ipsec barf | grep conn_prio</font></div></div></div><div><div><div><font face="monospace, monospace">000 "clear":   <span style="background-color:rgb(255,255,0)">conn_prio: 32,32</span>; interface: eth0; metric: 0; mtu: unset; sa_prio:65535; sa_tfc:none;</font></div></div></div><div><div><div><font face="monospace, monospace">000 "clear#<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>":   conn_prio: 32,32; interface: eth0; metric: 0; mtu: unset; sa_prio:65535; sa_tfc:none;</font></div></div></div><div><div><div><font face="monospace, monospace">000 "private":   <span style="background-color:rgb(255,255,0)">conn_prio: 32,0</span>; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;</font></div></div></div><div><div><div><font face="monospace, monospace">000 "private#<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>":   conn_prio: 32,0; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;</font></div></div></div><div><div><div><font face="monospace, monospace">000 "private#<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>"[1]:   conn_prio: 32,0; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;</font></div></div></div></blockquote><div dir="ltr"><div><br></div><div>2. As a result, <font face="monospace, monospace">find_connection </font>function selects clear connection as the better option</div></div></div>3. However, <font face="monospace, monospace">find_connection </font>function reset best to NULL for NEVER_NEGOTIATE connections (and clear is one them)<br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div><font face="monospace, monospace">[root@erwelchipsecvm-000000 ipsec.d]# cat /var/log/pluto.log | grep find_conne</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434481: | find_connection: looking for policy for connection: <a href="http://10.0.0.4:17/36303" target="_blank">10.0.0.4:17/36303</a> -> <a href="http://10.0.0.5:17/1025" target="_blank">10.0.0.5:17/1025</a></font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434488: | find_connection: conn "clear#<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>" 0.0.0.0 has compatible peers: <a href="http://10.0.0.4/32" target="_blank">10.0.0.4/32</a> -> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> [pri: 16842768]</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434493: | find_connection: first OK "clear#<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>" 0.0.0.0 [pri:16842768]{0x7fdc68319868} (child none)</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434498: | find_connection: conn "private#<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>" has compatible peers: <a href="http://10.0.0.4/32" target="_blank">10.0.0.4/32</a> -> <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> [pri: 16777224]</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434504: | find_connection: comparing best <span style="background-color:rgb(255,255,0)">"clear#<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>" 0.0.0.0 [pri:16842768</span>]{0x7fdc68319868} (child none) to "<span style="background-color:rgb(255,255,0)">private#<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>" [pri:16777224</span>]{0x7fdc68319d88} (child none)</font></div></div></div></div><div><div><div><div><font face="monospace, monospace">Nov 15 15:32:20.434508: | find_connection: <span style="background-color:rgb(255,255,0)">concluding with empty</span></font></div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div>So, as a result, libreswan thinks there is no routed template that covers this pair:</div></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><font face="monospace, monospace"><a href="http://10.0.0.4/32:36303" target="_blank">10.0.0.4/32:36303</a> -17-> <a href="http://10.0.0.5/32:1025" target="_blank">10.0.0.5/32:1025</a> => %hold 0    no routed </font><span style="font-family:monospace,monospace">template covers this pair</span></div></div></div></div></blockquote><div><br></div><div>So, two questions I have:</div><div>1. Do our expectation make sense or is it some weird usage pattern? (Any other ways to achieve this?)</div><div>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:</div><div><br></div><div>programs/pluto/connections.c :2395</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><font face="monospace, monospace">if (<span style="background-color:rgb(255,255,0)">!NEVER_NEGOTIATE(c) && </span>(best == NULL || prio > best_prio)) {</font></div></div></div><div><div><div><font face="monospace, monospace"><span style="white-space:pre-wrap">  </span>best = c;</font></div></div></div><div><div><div><font face="monospace, monospace"><span style="white-space:pre-wrap">   </span>best_sr = sr;</font></div></div></div><div><div><div><font face="monospace, monospace"><span style="white-space:pre-wrap">       </span>best_prio = prio;</font></div></div></div><div><div><div><font face="monospace, monospace">}</font></div></div></div></blockquote><div dir="ltr"><div><br></div>Kirill. <br></div></div>