Project

General

Profile

Issue #2958

Trap policies with unspecified remote IP covering multiple specific ports constantly produce new IKE_SAs

Added by James Masson over 1 year ago. Updated over 1 year ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.7.2
Resolution:

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
log.txt (6.49 KB) log.txt James Masson, 08.03.2019 15:28
server1.log (4 MB) server1.log James Masson, 08.03.2019 17:29
server0.log (4 MB) server0.log James Masson, 08.03.2019 17:29
server1.xfrm_state (3.18 KB) server1.xfrm_state James Masson, 08.03.2019 17:29
server0.xfrm_state (3.18 KB) server0.xfrm_state James Masson, 08.03.2019 17:29

History

#1 Updated by Tobias Brunner over 1 year 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 over 1 year ago

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 over 1 year 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 over 1 year 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

Also available in: Atom PDF