What were you trying to do that didn't work?

We are currently establishing twelve parallel IPsec SAs between two servers, both equipped with the same hardware configurations. This setup is intended to utilize a full 10Gbps NIC. Each server’s 10G interface is assigned 12 unique IPv4 addresses from the same subnet, which helps differentiate traffic for each IPsec tunnel. Below is a typical configuration for one of these tunnels:

conn IPv4_transport_aes_gcm128-null_encap-no_172.20.1.10_172.20.1.22
    type=transport
    authby=secret
    left=172.20.1.10
    right=172.20.1.22
    phase2=esp
    esp=aes_gcm128-null
    auto=start
    encapsulation=no
    replay-window=0
    nic-offload=no

At present, we are experiencing issues with some tunnels where encrypted ICMP packets are sent to the corresponding host but fail to receive a reply, or the reply is not recognized by the sending host. This issue occurs even though the tcpdump logs indicate successful transmission of encrypted packets. When the IPsec services are disabled on both servers, all routing and connections with unencrypted traffic work as expected.

Our expertise in diagnosing IPsec issues is limited. However, we can provide access to the testing environment to assist with further debugging.

Please provide the package NVR for which bug is seen:

[root@soustruznik2 ~]# rpm -qa | grep libreswan
libreswan-4.15-2.el10.x86_64
[root@soustruznik1 ~]# uname -r
6.10.0-15.el10.x86_64

Distro: RHEL-10.0-20240717.79 (We can reproduce this issue also on RHEL-9.4.0 GA.)

How reproducible:

almost always (80% cases)

Steps to reproduce

1.  Take a pair of identical servers and install all ipsec dependencies.
2.  Configure 12 unique IP addresses from the same subnet on both servers.
3.  Configure 12 same IPsec tunnels between different IPs according to the example configuration.

Expected results

All tunnels are up, traffic is encrypted, and communication is fully functional.

Actual results

Some tunnels appear to encrypt traffic successfully, as indicated by the tcpdump output. Yet, the encrypted packets are not acknowledged by the destination host, leading to a failure in establishing functional communication. Additionally, the Pluto service is generating unusual logs, as follows:

 pluto[21025]: ERROR: kernel: xfrm XFRM_MSG_DELPOLICY %pass(none) response for flow (out): No such file or directory (errno 2)
pluto[21025]: failed to delete bare shunt bare shunt 0x5568ef736e48 172.20.1.22/32:5210 -TCP-> 172.20.1.10/32:39747 => HOLD 0    acquire
pluto[21025]: ERROR: kernel: xfrm XFRM_MSG_DELPOLICY %pass(none) response for flow (out): No such file or directory (errno 2)
pluto[21025]: failed to delete bare shunt bare shunt 0x5568ef5cd8e8 172.20.1.23/32:5211 -TCP-> 172.20.1.11/32:36949 => HOLD 0    acquire
pluto[18890]: packet from 172.20.1.21:500: CREATE_CHILD_SA request has no corresponding IKE SA; message dropped
pluto[18890]: packet from 172.20.1.20:500: CREATE_CHILD_SA request has no corresponding IKE SA; message dropped