On 9/30/25 08:34, Yves-Alexis Perez wrote:
On Mon, 2025-09-29 at 21:51 +0000, Luigi Baldoni wrote:
> Since then, strongswan has deprecated the old ipsec.conf format in
favour
> of swanctl.conf. The systemd scripts launch the daemon first and
then invoke
> swanctl to load the new-style configuration, but the existing
> /etc/init.d/ipsec
> does not.
> Other non-systemd distributions (e.g. openwrt and alpine) use separate
> launchers
> to leave users the choice, upstream systemd seems to do it the new
way only,
> but I haven't delved too much into it.
Hi Luigi,
I'm not sure I understand your problem.
If you want to use the "legacy" ipsec.conf, use strongswan-charon and
strongswan-starter.
If you want to use the "new" swanctl.conf, use strongswan-swanctl and
charon-
systemd (and yes that means using systemd launcher).
The `strongswan` metapackage used to depend on the former set, now on the
latter.
As you can see at the bottom of the report, I was trying to run a
sysvinit-only system, so
charon-systemd would be inaccesible in such a setup. I do realise it's
an edge case, I just
wonder if you would include a suitably modified init script to cover it.
On 9/30/25 09:27, Andrew Bower wrote:
An initscript like the following might do the job but, as I said above,
the application is not quite ready for this to be used:
#!/bin/sh /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: strongswan
# Required-Start: $remote_fs $network
# Required-Stop: $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
# Description: The strongSwan VPN suite uses the native IPsec stack
# in the standard Linux kernel. It supports both the
# IKEv1 and IKEv2 protocols.
### END INIT INFO
DAEMON=/usr/sbin/charon-systemd
NAME=strongswan
DESC="strongSwan IPSec daemon"
START_ARGS="--background --make-pidfile --notify-await"
do_start_cmd_override() {
do_start_cmd && swanctl --load-all --noprompt
}
do_reload_cmd() {
swanctl --reload
swanctl --load-all --noprompt
}
Yes, this is exactly what I was thinking about. The problem can also be
mitigated by
adding the first command as start-script in charon.conf.
Regards
