strongSwan

That log is not useful (it does not show why the SAs are deleted or created and it's only one side). See HelpRequests.

Also, with this config you will always have two CHILD_SAs between two peers if they communicate bidirectionally from an arbitrary source port to one of the ports in the list.

Thanks for the pointers.

Here are some more logs, and xfrm state

Agreed that there are going to be more than 1 CHILD_SAs, because there's a lot of separate communication streams going on via UDP involving those ports.

What's odd is that the logs and `ipsec status` imply that the SAs are being constantly replaced - see the low-lifetime connections in the original `ipsec status` above. That server had been up for 8 mins, under steady load.

I would expect either that entries proliferate ( due to multiple port pairs with fresh client ports ), or reach a steady state. I wouldn't expect connections to be replaced every ~5 seconds - which is what seems to be happening.

Am I reading this wrong?

First, you should have used the log settings shown on HelpRequests, with enc on 2 the log is cluttered with lots of unnecessary messages.

Now, what you are using (right=%any with auto=route) is kind of a hack to begin with. And in this asymmetric scenario it definitely shows. The problem is that whenever an acquire is received from the kernel when traffic matches an outbound trap policy, a new IKE_SA is forcibly created (the usual mechanism would otherwise return preexisting IKE_SAs with other peers/IPs).

This means that an existing IKE_SA previously created by a peer will not be reused when traffic to that same peer causes an acquire. Due to the asymmetric nature of the config, you will have to end up with two CHILD_SAs with each peer. That's because the policies installed with a CHILD_SA that matches inbound traffic won't match outbound traffic and vice-versa.

So referring to your config, if a peer initiates an SA, the responder will select transport-mode-in as CHILD_SA config. However, when that responder then starts sending traffic to the initiator itself, it won't match the existing policy but the trap installed with transport-mode-out. As explained above, the existing IKE_SA created by the peer won't be reused, instead a new one is initiated. And because this new IKE_SA uses the same identities (the IPs) and is initiated from the same source IP and port the existing IKE_SA uses, it results in the following on the responder:

01[IKE] <transport-mode-out|3> schedule delete of duplicate IKE_SA for peer '10.32.3.10' due to uniqueness policy and suspected reauthentication

To the responder it looks like the peer initiates a new IKE_SA to replace the existing one (i.e. a reauthentication, which is an ugly mechanism in the first place but the check above currently can't be disabled). So the responder will tear down its instance of transport-mode-out created previously and that in turn will result in another acquire when new outbound traffic matches the traps and yet another new IKE_SA, resulting in the same exact thing on the other peer and so on.

So this currently won't work just like that.

One possible workaround is to use different identities for the in- and outbound traffic. Something like this might work:

conn transport-mode-out
    also=default
    leftid=<name|ip>@out.id
    rightsubnet=10.32.0.0/16[17/10000],10.32.0.0/16[17/10001],10.32.0.0/16[17/10002],10.32.0.0/16[17/10003],10.32.0.0/16[17/10004],10.32.0.0/16[17/10005],10.32.0.0/16[17/10006],10.32.0.0/16[17/10007]
    type=transport
    authby=psk
    auto=route

conn transport-mode-in
    also=default
    rightid=*@out.id
    leftsubnet=10.32.0.0/16[17/10000],10.32.0.0/16[17/10001],10.32.0.0/16[17/10002],10.32.0.0/16[17/10003],10.32.0.0/16[17/10004],10.32.0.0/16[17/10005],10.32.0.0/16[17/10006],10.32.0.0/16[17/10007]
    type=transport
    authby=psk
    auto=add

Note that I also changed auto to add for transport-mode-in because these policies won't match outbound traffic and are therefore useless as trap policies. This way, you'd end up with two IKE and CHILD SAs with each peer (i.e. it adds some overhead, and it also requires creating individual config files for each peer). For example, between 10.32.0.10 and 10.32.0.20 the identities of the two IKE_SAs could look like this on 10.32.0.10:

transport-mode-out:
  [10.32.0.10@out.id] [10.32.0.20]
transport-mode-in:
  [10.32.0.10] [10.32.0.20out.id]