libreswan get_active_conns() is not looking for Child SA but any SA

[The-Mule]

The current version of libreswan check for active connections looks as follows:

    def get_active_conns(self):
        return self.get_conns_from_status(r"#\d+: .*\"(.*)\".*")

It looks for the following in the output of ipsec status:

#1831: "ovn-8cd020-0-out-1":500 ESTABLISHED_CHILD_SA ...                                  
#1831: "ovn-8cd020-0-out-1" esp.c17d497a@10.0.54.91 esp.a1627f5e@10.0.91.148 Traffic: ...
#2308: "ovn-8cd020-0-out-1":500 ESTABLISHED_IKE_SA ...

Any of the aforementioned three lines will mark ovn-8cd020-0-out-1 as active but in reality only the first or second line means that this connection is actice - a Child SA must be established. The following connection will be incorrectly marked as active even though it only contains orphaned IKE SA and no Child SA (ie. there is no IPsec SA in kernel for this connection):

#2308: "ovn-8cd020-0-out-1":500 ESTABLISHED_IKE_SA ...

I suggest to update the check to look for ESTABLISHED_CHILD_SA. Notice that even though there is a difference between libreswan-4 and libreswan-5 output "#\d+: .*\"(.*)\".*ESTABLISHED_CHILD_SA.*" should match correctly using either version.

[igsilya]

IIRC, one of the reasons we're not doing that is output format varying significantly between versions of Libreswan. For example, I get the following output from Libreswan 3.32 that is used by Ubuntu 22.04:

000 #8: "tun-in-1":500 STATE_V2_IPSEC_R (IPsec SA established); EVENT_SA_REKEY in 28513s; newest IPSEC; eroute owner; isakmp#7; idle;
000 #8: "tun-in-1" esp.c6981ce4@10.1.1.2 esp.e9260fec@10.1.1.1 ref=0 refhim=0 Traffic: ESPin=1KB ESPout=0B! ESPmax=0B 
000 #7: "tun-out-1":500 STATE_PARENT_R2 (received v2I2, PARENT SA established); EVENT_SA_REKEY in 3313s; newest ISAKMP; idle;
000 #9: "tun-out-1":500 STATE_V2_IPSEC_R (IPsec SA established); EVENT_SA_REKEY in 28528s; newest IPSEC; eroute owner; isakmp#7; idle;
000 #9: "tun-out-1" esp.5255d765@10.1.1.2 esp.2cf44503@10.1.1.1 ref=0 refhim=0 Traffic: ESPin=0B ESPout=742B! ESPmax=0B

[The-Mule]

Right, I completely understand (STATE_V2_IPSEC_R (IPsec SA established) is what we would like to be looking at on 3.32). This is just something for consideration. Situations when you end up with orphaned IKE SA (second example from the description) are quite rate but at the same time they often points to some errorneous scenario where reconciliation would actually be very useful.

[igsilya]

Do you think we can do #\d+: .*\"(.*)\".*(esp\.[0-9a-f]+@).* ? Would that be more portable across versions? The format of printing actual SA identifiers seem to be more stable.

[The-Mule]

Sorry for a late reply - yes, this should work fine too (definitely for 4 and 5 version) I would have to recheck 3 if it is still active somewhere.

[igsilya]

The change has unforeseen consequences. Just replacing the regex breaks connectivity in Libreswan 4.6. It seems like more active dismantling of connections drives pluto into some broken state. I'm trying to figure out if we can also modify the reconciliation logic to e.g. avoid deletion of already fully active connections, but I'm not sure if it will help or if it will also break some other cases. Need a lot of testing...

[The-Mule]

Is it possible to reproduce it with 4.6 libreswan running ipsec self-test?

[igsilya]

I think, the reason for those failures in 4.6 is that since the meaning of "active" changed, we're more aggressive with tearing down connections. And the "half-loaded" logic makes us delete even fully established ones. And in some cases this leads to ovs-monitor tearing down connections faster than pluto is able to bring them up (it has to bring both of them up within 15 seconds, while the other side may not initiate the -out- connection for some time).

So, I reworked the reconciliation logic to get rid of the "half-loaded" hack and streamline it in general. With that, 4.6 seems to work just fine. I've also been using this version for the past few weeks testing various versions of Libreswan and the new reconciliation logic seems to be working as expected in general. I posted the patch for review now: https://patchwork.ozlabs.org/project/openvswitch/patch/20260129140955.3728485-5-i.maximets@ovn.org/