IPSec VPN tunnels won't reconnect because option "keyingtries" incorrectly written to .conf file

[dinomueller]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Since a few weeks I noticed some of our IPsec VPN connections won't come back online after a disconnection. In the past I've set the Tunnel option keyingtries to -1 as described in the online help:
(see attached screenshots)

"How many attempts should be made to negotiate a connection, or a replacement for one, before giving up (default 3). Leave empty for default, -1 for forever or any positive integer for the number of tries"

So everything was working fine and all tunnels were coming up again after any disconnections. Until recently the VPN-Setup was changed with one of the recent OPNsense versions. The "Connection" menu was introduced and the old Tunnels were moved to "Tunnel Settings [legacy]" Now some tunnels (I suppose only newly created) won't come back after a disconnect.

What I've found so far:

Last working version: 22.7.11_1
Not working since: 23.7.3 (maybe earlier)

Regarding to the strongswan documentation the parameter in the .conf file should be keyingtries=%forever.

In 22.7.11_1 the .conf file was located at /usr/local/etc/ipsec.conf and here I could find the parameter keyingtries=%forever for all tunnels we've set up. So the -1 from the GUI was correctly translated to %forever in the config file.
(see attached screenshots)

Now in 23.7.3 the .conf file is located at /usr/local/etc/swanctl/swanctl.conf and the parameter which is written to it is keyingtries=0.
(see attached screenshots)

To Reproduce

Steps to reproduce the behavior:

1. Create a new IPsec VPN Tunnel [legacy]
2. Set keyingtries to -1
3. Check /usr/local/etc/swanctl/swanctl.conf
4. See the wrong value keyingtries=0

Expected behavior

Write %forever instead of 0 to the config file

Screenshots

WebGUI setting:

Config file working in 22.7.11_1

Config file broken in 23.7.3

[AdSchellevis]

https://wiki.strongswan.org/projects/strongswan/wiki/Fromipsecconf
https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html

[dinomueller]

Thank you. I haven't found that and didn't know that they changed the values.

But it's a fact that (our) IPsec connections won't reconnect after a disconnect since the introduction of the new "Connections" menu. So it must be something else. With the old versions everything was running fine for years. And suggestions?

[Monviech]

My suggestion would be to migrate your IPsec Configuration to the Connections menu since the Tunnels menu is legacy now.

[bisi-sysadmin]

I can confirm that today (2023-10-27), after upgrading one device to OPNsense 23.7.7_1-amd64, and installing the same, fresh, on another device (replacing an ancient cisco device), I have experienced exactly this. The tunnel dropped because of an ISP outage (very common in our area) and did not come back. Keying retries was set to -1 on both ends, and at both ends the below is found:

root@gw1:~ # grep keyingtries /usr/local/etc/swanctl/swanctl.conf
        keyingtries = 0

I have tried migrating to "connections" but was unable to decipher the instructions in time to support user needs for the VoIP phones to work over the long-existing IPsec tunnel.

wanting to apply some duct tape to this 'til I can get my head into the whole connections thing - can I manually the edit the swanctl.conf file, have the keying retry forever, and revisit this issue when I can handle migrating 35 tunnels spread across 12 or 13 separate clients?

edit, later Friday night -- "no you can't edit this file". It even says so at the top of the file itself

# This file is automatically generated. Do not edit

And I proved it, too. Disabling/Enabling the tunnel (and maybe restarting the device) re-writes swanctl.conf with the useless and incorrect value for keyingtries =.

[fichtner]

@bisi-sysadmin I’m going to ask you to be more friendly on the issue tracker. The reaction you may receive in direct response is usually not what you would expect from others so self-awareness is good.

[Monviech]

The documentation is partly a community effort. I have already contributed to the IPsec documentation. But I can't write everything alone in my free time. For "pressurized situations" it might be best to get paid support from deciso? Or take like two hours of your own time to build a test tunnel...? It's not /that/ hard.

[Monviech]

@bisi-sysadmin Maybe you could mitigate your problem by setting keyingretries to a very high number. Since its stored as 32bit integer, it could be as high as 2^31-1. So setting it to something like 100000 would be the same as unlimited retries, since that would take a really long time too. Just an idea.

[bisi-sysadmin]

Maybe you could mitigate your problem by setting keyingretries to a very high number. Since its stored as 32bit integer, it could be as high as 2^31-1. So setting it to something like 100000 would be the same as unlimited retries, since that would take a really long time too.

That was my first idea, but I was uncomfortable with the likelihood this would just get swamped with all the other stuff on my plate, and never be revisited 'til something else breaks, (or I'm forced to try yet again to understand what I don't get about whateverS/WAN VTI tunnelling).

So then I set up Monit at both ends to restart IPsec if the tunnel dropped -- 20 (the maximum # of) failed pings of the inside I/F of the other firewall is my standard for "tunnel down". This works! (Not at all surprised that that I could verify it "in the wild" with this ISP so soon after deployment). With the potential added benefit that I'd get an email about the event from one or both ends of the tunnel. But this is a Gsuite-using-client and Monit hasn't (yet) adapted to the security creep imposed by Google for 3rd party SMTP clients, AND my usual, super-reliable go-to solution (a relay host on my own dev network, connected by ipsec tunnels) doesn't work when used directly from an OPNsense firewall because I-don't-know-why. So I posted about that in the OPNsense forum. I have other clients with more pressing needs, but maybe I'll get this client set up on SMTP2GO for their not-acceptable-to-google email needs.

Thanks for the suggestion!
d.

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.