Issue #2958
Trap policies with unspecified remote IP covering multiple specific ports constantly produce new IKE_SAs
Description
Hi,
I'm using transport mode to encrypt traffic between a set of ports on a fleet of machines. Based on https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples#Host-To-Host-transport-mode
I have a config that works, but it seems to constantly generate new IKE_SAs every few seconds (log attached). I've not measured the overhead of this, but expect it to be a significant latency hit!
Any hints on how to improve this? Or can I safely ignore the problem?
thanks
James Masson
Config
conn default ike=aes128gcm16-prfsha256-ecp256! esp=aes128gcm16-prfsha256-ecp256! keyexchange=ikev2 keyingtries=%forever mobike=no conn transport-mode-out also=default 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 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=route
root@ipsec:/# ipsec status Routed Connections: transport-mode-in{2}: ROUTED, TRANSPORT, reqid 2 transport-mode-in{2}: 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] === 0.0.0.0/0 transport-mode-out{1}: ROUTED, TRANSPORT, reqid 1 transport-mode-out{1}: 0.0.0.0/0 === 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] Security Associations (6 up, 0 connecting): transport-mode-out[110]: ESTABLISHED 0 seconds ago, 10.32.1.10[10.32.1.10]...10.32.3.10[10.32.3.10] transport-mode-in{112}: INSTALLED, TRANSPORT, reqid 78, ESP SPIs: c57a8898_i cad278a4_o transport-mode-in{112}: 10.32.1.10/32[17/10000] 10.32.1.10/32[17/10001] 10.32.1.10/32[17/10002] 10.32.1.10/32[17/10003] 10.32.1.10/32[17/10004] 10.32.1.10/32[17/10005] 10.32.1.10/32[17/10006] 10.32.1.10/32[17/10007] === 10.32.3.10/32 transport-mode-out[109]: ESTABLISHED 7 seconds ago, 10.32.1.10[10.32.1.10]...10.32.2.10[10.32.2.10] transport-mode-in{111}: INSTALLED, TRANSPORT, reqid 2, ESP SPIs: c0841f21_i cf4181ce_o transport-mode-in{111}: 10.32.1.10/32[17/10000] 10.32.1.10/32[17/10001] 10.32.1.10/32[17/10002] 10.32.1.10/32[17/10003] 10.32.1.10/32[17/10004] 10.32.1.10/32[17/10005] 10.32.1.10/32[17/10006] 10.32.1.10/32[17/10007] === 10.32.2.10/32 transport-mode-out[108]: ESTABLISHED 10 seconds ago, 10.32.1.10[10.32.1.10]...10.32.3.10[10.32.3.10] transport-mode-out{110}: INSTALLED, TRANSPORT, reqid 77, ESP SPIs: cf88ceec_i c2957bf4_o transport-mode-out{110}: 10.32.1.10/32 === 10.32.3.10/32[17/10000] 10.32.3.10/32[17/10001] 10.32.3.10/32[17/10002] 10.32.3.10/32[17/10003] 10.32.3.10/32[17/10004] 10.32.3.10/32[17/10005] 10.32.3.10/32[17/10006] 10.32.3.10/32[17/10007] transport-mode-out[107]: ESTABLISHED 17 seconds ago, 10.32.1.10[10.32.1.10]...10.32.2.10[10.32.2.10] transport-mode-out{109}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: ca06e25f_i c730c145_o transport-mode-out{109}: 10.32.1.10/32 === 10.32.2.10/32[17/10000] 10.32.2.10/32[17/10001] 10.32.2.10/32[17/10002] 10.32.2.10/32[17/10003] 10.32.2.10/32[17/10004] 10.32.2.10/32[17/10005] 10.32.2.10/32[17/10006] 10.32.2.10/32[17/10007] transport-mode-out[6]: ESTABLISHED 8 minutes ago, 10.32.1.10[10.32.1.10]...10.32.101.37[10.32.101.37] transport-mode-in{8}: INSTALLED, TRANSPORT, reqid 6, ESP SPIs: c2a132ed_i c8de4a58_o transport-mode-in{8}: 10.32.1.10/32[17/10000] 10.32.1.10/32[17/10001] 10.32.1.10/32[17/10002] 10.32.1.10/32[17/10003] 10.32.1.10/32[17/10004] 10.32.1.10/32[17/10005] 10.32.1.10/32[17/10006] 10.32.1.10/32[17/10007] === 10.32.101.37/32 transport-mode-out[1]: ESTABLISHED 8 minutes ago, 10.32.1.10[10.32.1.10]...10.32.1.124[10.32.1.124] transport-mode-in{3}: INSTALLED, TRANSPORT, reqid 3, ESP SPIs: cc3dce99_i c006b429_o transport-mode-in{3}: 10.32.1.10/32[17/10000] 10.32.1.10/32[17/10001] 10.32.1.10/32[17/10002] 10.32.1.10/32[17/10003] 10.32.1.10/32[17/10004] 10.32.1.10/32[17/10005] 10.32.1.10/32[17/10006] 10.32.1.10/32[17/10007] === 10.32.1.124/32
History
#1 Updated by Tobias Brunner almost 2 years ago
- Description updated (diff)
- Status changed from New to Feedback
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.
#2 Updated by James Masson almost 2 years ago
- File server1.log server1.log added
- File server0.log server0.log added
- File server1.xfrm_state server1.xfrm_state added
- File server0.xfrm_state server0.xfrm_state added
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?
#3 Updated by Tobias Brunner almost 2 years ago
- Subject changed from Transport mode only on specific ports constantly produces new IKE_SAs to Trap policies with unspecified remote IP covering multiple specific ports constantly produce new IKE_SAs
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]
#4 Updated by James Masson almost 2 years ago
Thanks for the advice - it worked perfectly.
For future people on this path - here's what worked.
conn default
ike=aes256gcm16-sha256-prfsha256-ecp256!
esp=aes128gcm16-sha256-ecp256!
keyexchange=ikev2
keyingtries=%forever
mobike=no
dpdaction=clear
conn transport-mode-out
also=default
leftid=${LOCAL_IP}@out.id
rightsubnet=10.32.0.0/16[/10000],10.32.0.0/16[/10001],10.32.0.0/16[/10002],10.32.0.0/16[/10003],10.32.0.0/16[/10004],10.32.0.0/16[/10005],10.32.0.0/16[/10006],10.32.0.0/16[/10007],10.32.0.0/16[/17000],10.32.0.0/16[/17100]
type=transport
authby=psk
auto=route
conn transport-mode-in
also=default
rightid=*@out.id
leftsubnet=10.32.0.0/16[/10000],10.32.0.0/16[/10001],10.32.0.0/16[/10002],10.32.0.0/16[/10003],10.32.0.0/16[/10004],10.32.0.0/16[/10005],10.32.0.0/16[/10006],10.32.0.0/16[/10007],10.32.0.0/16[/17000],10.32.0.0/16[/17100]
type=transport
authby=psk
auto=add