`ovs-appctl -t ovs-monitor-ipsec tunnels/show` always reports no active connections

[antoninbas]

ovs-appctl -t ovs-monitor-ipsec tunnels/show always reports that there are no active connection (at least when using strongSwan), even when ipsec status shows active connections and traffic is encrypted as expected across VMs.

ovs-appctl -t ovs-monitor-ipsec tunnels/show

/# ovs-appctl -t ovs-monitor-ipsec tunnels/show
Interface name: ol-plane-a39e0c v1 (CONFIGURED)
  Tunnel Type:    geneve
  Local IP:       %defaultroute
  Remote IP:      172.18.0.4
  Address Family: IPv4
  SKB mark:       None
  Local cert:     None
  Local name:     None
  Local key:      None
  Remote cert:    None
  Remote name:    None
  CA cert:        None
  PSK:            changeme
  Ofport:         1
  CFM state:      Disabled
Kernel policies installed:
  src 172.18.0.3/32 dst 172.18.0.4/32 proto udp dport 6081
  src 172.18.0.3/32 dst 172.18.0.4/32 proto udp dport 6081
  src 172.18.0.3/32 dst 172.18.0.4/32 proto udp sport 6081
  src 172.18.0.3/32 dst 172.18.0.4/32 proto udp sport 6081
Kernel security associations installed:
IPsec connections that are active:

Interface name: worker2-a0d026 v1 (CONFIGURED)
  Tunnel Type:    geneve
  Local IP:       %defaultroute
  Remote IP:      172.18.0.2
  Address Family: IPv4
  SKB mark:       None
  Local cert:     None
  Local name:     None
  Local key:      None
  Remote cert:    None
  Remote name:    None
  CA cert:        None
  PSK:            changeme
  Ofport:         2
  CFM state:      Disabled
Kernel policies installed:
  src 172.18.0.3/32 dst 172.18.0.2/32 proto udp sport 6081
  src 172.18.0.3/32 dst 172.18.0.2/32 proto udp sport 6081
  src 172.18.0.3/32 dst 172.18.0.2/32 proto udp dport 6081
  src 172.18.0.3/32 dst 172.18.0.2/32 proto udp dport 6081
Kernel security associations installed:
  sel src 172.18.0.3/32 dst 172.18.0.2/32 proto udp sport 6081
  sel src 172.18.0.2/32 dst 172.18.0.3/32 proto udp dport 6081
  sel src 172.18.0.3/32 dst 172.18.0.2/32 proto udp dport 6081
  sel src 172.18.0.2/32 dst 172.18.0.3/32 proto udp sport 6081
IPsec connections that are active:

ipsec status

/# ipsec status
Routed Connections:
worker2-a0d026-out-1{4}:  ROUTED, TRANSPORT, reqid 4
worker2-a0d026-out-1{4}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
worker2-a0d026-in-1{3}:  ROUTED, TRANSPORT, reqid 3
worker2-a0d026-in-1{3}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]
ol-plane-a39e0c-out-1{2}:  ROUTED, TRANSPORT, reqid 2
ol-plane-a39e0c-out-1{2}:   172.18.0.3/32[udp] === 172.18.0.4/32[udp/6081]
ol-plane-a39e0c-in-1{1}:  ROUTED, TRANSPORT, reqid 1
ol-plane-a39e0c-in-1{1}:   172.18.0.3/32[udp/6081] === 172.18.0.4/32[udp]
Security Associations (1 up, 0 connecting):
worker2-a0d026-in-1[1]: ESTABLISHED 43 seconds ago, 172.18.0.3[172.18.0.3]...172.18.0.2[172.18.0.2]
worker2-a0d026-out-1{5}:  INSTALLED, TRANSPORT, reqid 4, ESP SPIs: c3cc41d2_i cfe36729_o
worker2-a0d026-out-1{5}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
worker2-a0d026-in-1{6}:  INSTALLED, TRANSPORT, reqid 3, ESP SPIs: c57b55c2_i cdca211d_o
worker2-a0d026-in-1{6}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]

ipsec statusall

/# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.13, Linux 6.8.0-50-generic, x86_64):
  uptime: 87 seconds, since Feb 04 23:38:15 2025
  malloc: sbrk 2891776, mmap 0, used 1024864, free 1866912
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl pkcs8 fips-prf gmp agent xcbc hmac kdf gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown counters
Listening IP addresses:
  10.10.1.1
  172.18.0.3
  fc00:f853:ccd:e793::3
Connections:
ol-plane-a39e0c-in-1:  %any...172.18.0.4  IKEv2
ol-plane-a39e0c-in-1:   local:  uses pre-shared key authentication
ol-plane-a39e0c-in-1:   remote: [172.18.0.4] uses pre-shared key authentication
ol-plane-a39e0c-in-1:   child:  dynamic[udp/6081] === dynamic[udp] TRANSPORT
ol-plane-a39e0c-out-1:   child:  dynamic[udp] === dynamic[udp/6081] TRANSPORT
worker2-a0d026-in-1:  %any...172.18.0.2  IKEv2
worker2-a0d026-in-1:   local:  uses pre-shared key authentication
worker2-a0d026-in-1:   remote: [172.18.0.2] uses pre-shared key authentication
worker2-a0d026-in-1:   child:  dynamic[udp/6081] === dynamic[udp] TRANSPORT
worker2-a0d026-out-1:   child:  dynamic[udp] === dynamic[udp/6081] TRANSPORT
Routed Connections:
worker2-a0d026-out-1{4}:  ROUTED, TRANSPORT, reqid 4
worker2-a0d026-out-1{4}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
worker2-a0d026-in-1{3}:  ROUTED, TRANSPORT, reqid 3
worker2-a0d026-in-1{3}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]
ol-plane-a39e0c-out-1{2}:  ROUTED, TRANSPORT, reqid 2
ol-plane-a39e0c-out-1{2}:   172.18.0.3/32[udp] === 172.18.0.4/32[udp/6081]
ol-plane-a39e0c-in-1{1}:  ROUTED, TRANSPORT, reqid 1
ol-plane-a39e0c-in-1{1}:   172.18.0.3/32[udp/6081] === 172.18.0.4/32[udp]
Security Associations (1 up, 0 connecting):
worker2-a0d026-in-1[1]: ESTABLISHED 45 seconds ago, 172.18.0.3[172.18.0.3]...172.18.0.2[172.18.0.2]
worker2-a0d026-in-1[1]: IKEv2 SPIs: 417aa36fe33b163c_i* ad9b2e675295d89c_r, pre-shared key reauthentication in 2 hours
worker2-a0d026-in-1[1]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
worker2-a0d026-out-1{5}:  INSTALLED, TRANSPORT, reqid 4, ESP SPIs: c3cc41d2_i cfe36729_o
worker2-a0d026-out-1{5}:  AES_GCM_16_256, 0 bytes_i, 4902 bytes_o (43 pkts, 1s ago), rekeying in 42 minutes
worker2-a0d026-out-1{5}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
worker2-a0d026-in-1{6}:  INSTALLED, TRANSPORT, reqid 3, ESP SPIs: c57b55c2_i cdca211d_o
worker2-a0d026-in-1{6}:  AES_GCM_16_256/MODP_2048, 4788 bytes_i (42 pkts, 1s ago), 0 bytes_o, rekeying in 42 minutes
worker2-a0d026-in-1{6}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]

IMO, this regex is the main issue: https://github.com/openvswitch/ovs/blob/481bc09794225b791c36c2790f7acd779a6ae0bb/ipsec/ovs-monitor-ipsec.in#L302

The first (.*) subgroup will do a greedy match, so for example when tunnel_name is worker2-a0d026-out-1{4}, the code will use worker2-a0d026-out as the interface name. In turn, this means that this if statement will never evaluate to true, leading to an empty IPsec connections that are active list.

As a quick test, I added the ? modified to the regex ((.*?)), which makes it non-greedy, and I did get some output, although it was messy and clearly not what we'd like:

IPsec connections that are active:
  worker2-a0d026-out-1{2}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
  worker2-a0d026-in-1{1}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]
  worker2-a0d026-in-1[1]: ESTABLISHED 9 seconds ago, 172.18.0.3[172.18.0.3]...172.18.0.2[172.18.0.2]
  worker2-a0d026-out-1{5}:   172.18.0.3/32[udp] === 172.18.0.2/32[udp/6081]
  worker2-a0d026-in-1{6}:   172.18.0.3/32[udp/6081] === 172.18.0.2/32[udp]

My guess is that the parsing code for the ipsec status output has not changed in OVS in a long time, while the output format of the command has evolved.

I don't know if the command behaves correctly when libreSwan is used for IKE.

[igsilya]

Yeah, unfortunately parsing of the ipsec status is not very reliable as the format is not very stable.
Could you try a change similar to this one on your setup: openvswitch/ovs@2ee0f44 ? This change was made for Libreswan quite some time ago, but should probably be ported for strongSwan as well.