Strongswan make-before-break setting in UI

Virtual Private Networks IPsec
1

We have an always-on connection that disconnects briefly, then reconnects at an interval equal to the ikev2 key lifetime. When this happens, users must wait about a minute, then reconnect to their remote app. It appears the configuration setting “make-before-break” may resolve this issue, but it is not an option in the UI. I’m guessing I’ll need to hand-edit the strongswan.conf file to enable this, based on this documentation:
https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey#Reauthentication
I would like to request a way to enable this in the UI.

In the meantime, can someone point me to the path to strongswan.conf? Or the path to whichever configuration file holds this setting?

Thanks!

2

The path of strongswan.conf is default ( /etc ) like in other linux distros.

But be carefull with this setting. The doku states “This avoids interruptions but requires that both peers can handle overlapping SAs”
Im not sure if this is correct working because this create matching firewall rules and xfrm policies.

3

Thanks, Arne. Do you have any other suggestions for keep the connection live during the key renewal? I actually tried to set the key renewal interval to 12 hrs so that the disconnect at least occured after-hours and would not interrupt users, but it seems that strongswan will not accept any value greater than 8.

4

The doku states that the lifetime is default 1h and can set up to 24h

5

When I tried setting it to 12h, I would SAVE, then when I went back in, it was still showing 8h. Bug?

6

Im not sure. Micheal has changed and reverted this long time ago. I have contacted him.

7

Please open tickets instead of privately contacting me :slight_smile:

I do not see any case for increasing the maximum lifetime to more than 8 hours. That already is uncomfortably high.

I agree that we can enable make-before-break though. That should have been the default.

But I do not understand why the break-before-make way would disrupt your connection for more than a couple of seconds. Can you analyse your logs and find out why this is?

8

Thanks, Michael.

After IKE_SA is deleted, the CHILD_SA is restarted. When generating the initiation request, it fails 5 times with peer not responding, at which point it initiates a new connection and succeeds. It takes roughly 2 minutes for this entire process to complete.

9

This seems to be a bug on the other side and I am not sure if make-before-break can fix that.

Any idea why the remote peer is dropping your packets?

10

I’ve got a support ticket in with them. Ball is in their court at the moment. Thanks for your help. I’ll relay your comments to them.

11

Do you know what equipment they are using?

12

Not exactly. I do know that it’s a virtual Windows server on AWS, but that’s it.

13

I don’t know if this is useful or not, but in order to get the 8 hour disconnects centered closer to mid-day (to keep the other two disconnects after hours), I shut down and restarted the VPN close to mid-day. What’s interesting is when I turned it back on, it connected IMMEDIATELY. It happened so fast that we got no outage alerts from either end and end user experience was not affected. So if an OFF/ON experience can happen so seemlessly, why does the remote peer not respond during the rekeying process? We get 5 “remote peer not responding” log entries, then when it does the OFF/ON cycle after it gives up after the 5th fail, it connects immediately again. This tells me that there’s something about the rekeying process that is different than an OFF/ON. It would appear that it’s an issue on their end since “remote peer is not responding” but could there be something in strongswan that could be contributing to this issue? I’m open to all possibilities. Still communicating with the remote peer support team, but no headway from them yet.

14

Did you try disabling rekeying?

I assume you are using IKEv1?

15

IKEv2. The list of advantages over v1 is too much to ignore. I suppose as a last troubleshooting step, I can test with v1, but I’ll wait til the other end does their research.

I don’t see a way to disable rekeying in the UI. Must it be done by editing a config file?

16

Yes, under no circumstances go back to IKEv1.

Yes. Just add rekey=no to your connection. That is for testing only.

17

@ms

We have determined that when reauth=no is set (default is reauth=yes), we no longer get disconnected when the key lifetime expires. I would like to turn on make_before_break to see if it helps with reauth=on, but I’m not sure how to do this. According to strongswan docs, it is set in strongswan.conf. I wasn’t sure where in this file to add it, so I put it at the bottom of the file, but after saving it, IPSec would no longer start up until I removed it. I am guessing it’s either set in a different file, or the format in strongswan.conf is pretty specific (ie, not at the bottom of the file). Would appreciate some guidance on how to enable make_before_break in IPFire.

Reference:

It is supported for IKEv2 since 5.3.0 but is disabled by default and may be enabled with the charon.make_before_break strongswan.conf setting.

https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey

18

Hey Tim,

yes, you can simply edit the files in /etc/strongswan.

I do not think that this is the way to go, but if you think it is worth a try, feel free to see if it works.

Just add that parameter to /etc/strongswan.d/charon.conf into the big charon section and run “ipsec restart”.

19

What’s up Michael,

Why don’t you think this is the way to go? Since the problem seems to be with reauth (our connection breaks after 5 failed reauth attempts with “remote peer not responding”), I thought charon.make_before_break=yes might allow the reauth to happen without disconnecting our users. Do you think something else might be going on?

Thanks, man.

20

I was curious if this would change anything. Rekeying and reauthentication are not the same.