IPSec keyingtries setting
-
Is there a method to get strongswan supported settings exposed as a configuration setting in pfsense. Right now I have an issue with IPSec connections which use VTI interfaces and recovery after a service outage. This can already be solved in strongswan settings, but they are not available to me in PFSense. Specifically the
connections.<conn>.keyingtries
The issue is as follows:
When using VTI's you can not use traps and therefore can't support SA's being brought up based on traffic. Therefore the only options are to bring them up at startup/restart. If I pull the WAN connection, the tunnels will go down, but that doesn't restart the daemon. Then it will re-try the connection for a pre-set number of tries (keyingtries setting), before finally giving up and never trying again since it only comes up on startup/restart. This number of re-tries CAN be set to "forever" in strongswan, which would solve the issue as it would just keep trying. IPSec connections would come up on first boot/reboot, and in the case of a service outage, would continue to re-try the connection. When the service outage resolves, the connection would come back as well.
I did look at the configuration XML file, but I am going to guess this is used to fill in a template to create the swanctl.conf file. Since the XML doesn't appear to me to be exactly the same format as the swanctl. If I could (for now until a new release exposed the setting) just add my keyingtries setting to the XML, at least I could fix this until a new update could fix it.
-
There isn't a setting for that at the moment, but it's also not a great general solution.
This should work fine once you're on CE 2.6.0 or Plus 21.09: https://redmine.pfsense.org/issues/12169
-
Great, that should at least solve my issue.
I don't see why including access to the underlying settings of strongswan is a bad option though.
From what I am reading on this other option, there would be another service check for the status of the tunnel. However that is on a timer (5 minutes?) so the tunnel coming back up with have some delay after recovery of the service (max of the timer). Basically the cron solution other users have mentioned using.
-
Not saying it's a bad thing to allow configuring the retries but it's not going to solve this. Eventually it will still timeout you're just delaying that a little longer in the process which doesn't help many people affected by the original problem. For example if the remote is down for a couple hours.
The option for the periodic check job may have a delay but it's better than checking too often (which doesn't scale well) and it will still eventually reconnect which is better than what it does now (nothing).
It's still cron-based but integrated into the settings so you just check a box on the P2 and you're done, no need to dig and figure out the commands to run in your own custom cron script.
-
@jimp said in IPSec keyingtries setting:
Eventually it will still timeout you're just delaying that a little longer in the process which doesn't help many people affected by the original problem. For example if the remote is down for a couple hours.
Actually strongswan supports the setting "forever" so it wouldn't eventually time out. It would just keep re-trying until it can re-connect. Hence if I could just adjust that right now, it would fix my issue, and do so in the underlying IPSec with out custom daemons on top.
-
I was also having the same problem that ipsec tunnels (VTI) wouldn't come up after being disconnected for a short period from the ISP.
Being able to set "keyingtries = %forever" from the gui would be very nice and would solve the issue using strongswan default implementations.
A simple entry of "-1" for "ikev2_retransmit_tries" in the advanced options being saved as "keyingtries = %forever" in the config would be enough.
-
On 22.01/2.6.0 the better solution is to check the new P2 keep alive option which is compatible with VTI. Forcing keying to take place forever isn't ideal.
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p2.html#keep-alive
-
@jimp Thanks for your input!
I just activated this option and see if it resolves the issue.
Is it best to activate it only on the initiating pfsense or on both sites?