Description of problem:
We are developing a new performance test case, which runs TCP streams over many (60) ipsec tunnels with the same parameters in parallel. However, we found buggy behavior. If the ipsec service is restarted, some tunnels remain down and log weird errors. Reboot or many restarts of the ipsec service is required to bring all tunnels up.

Version-Release number of selected component (if applicable):
distro: RHEL-9.1.0 GA
kernel: 5.14.0-162.6.1.el9_1.x86_64
libreswan: 4.6-3.el9.x86_64

How reproducible:
Often

Steps to Reproduce (for both servers in a pair):
1. Install a pair of identical servers with RHEL-9.1.0 GA
2. Install required packages: libreswan
3. Assign 60 additional IP addresses from the same network for testing interfaces
4. Create 60 IPsec tunnels according to the provided example below
5. systemctl enable ipsec
6. Reboot
7. systemctl restart ipsec

Actual results:
Some tunnels are down. Reboot or many restarts of the ipsec service is required to bring all tunnels up.

The following errors appear in the logs:
netlink_acquire got message with length 116 < 232 bytes; ignore message
Apr 14 14:52:01 hostname pluto[10779]: "IPv4_transport_aes_gcm128-null_encap-no_172.20.1.14_172.20.1.28" #71: deleting incomplete state after 200 seconds
Apr 14 14:52:01 hostname pluto[10779]: "IPv4_transport_aes_gcm128-null_encap-no_172.20.1.14_172.20.1.28" #71: deleting state (STATE_V2_PARENT_R1) aged 200.041531s and NOT sending notification

Expected results:
All tunnels are up and running within a reasonable time range.

Additional info:
We can provide a testing environment with the buggy setup for further investigation.

IPsec tunnel example:
conn IPv4_transport_aes_gcm128-null_encap-no_172.20.1.5_172.20.1.61
type=transport
authby=secret
left=172.20.1.1
right=172.20.1.61
phase2=esp
esp=aes_gcm128-null
auto=start
encapsulation=no
nic-offload=no