The charon-systemd daemon implements the IKE daemon very similar to charon, but is specifically designed for use with systemd. It uses the systemd libraries for a native integration and comes with a simple systemd service file.

Instead of using starter and an ipsec.conf based configuration, the daemon is directly managed by systemd and configured with the swanctl configuration backend. ipsec.conf based configurations are not supported with that daemon, as that would require the starter process.

Legacy systemd support using ipsec.conf and starter

Since 4.5.2, strongSwan comes with a systemd service unit called strongswan. This service invokes starter, which then loads ipsec.conf. This service is different from the charon-systemd based service we discuss here, which has a much simpler design and native systemd integration. charon-systemd implements the systemd service unit called strongswan-swanctl, because it relies on swanctl for its configuration.

Build options

To build the daemon, add

--enable-systemd --enable-swanctl
to the ./configure options.

To disable starter, ipsec and the stroke backend, additionally add

--disable-charon --disable-stroke --disable-scepclient
to build a lightweight and clean IKE daemon using modern tools.

The systemd unit file directory is detected automatically using pkg-config, but may be set manually using the --with-systemdsystemunitdir= option.

It is available since 5.2.1.


charon-systemd gets installed as native systemd daemon, and should be started and stopped using systemctl. The systemd service unit is named strongswan (was strongswan-swanctl before 5.8.0, to distinguish it from the strongswan service that uses starter, which is now called strongswan-starter).

After startup, systemd uses swanctl to load the swanctl-based configuration, including connections, pools and credentials.

The reload command reloads strongswan.conf and since 5.7.0 also the swanctl-based configuration.


To configure configurations and connections, refer to the swanctl backend documentation. charon-systemd requires the use of a swanctl based configuration.


By default the charon-systemd backend logs to the systemd journal, use journalctl to inspect the log. Loglevels can be configured very similar to the other charon logger configuration, but using a journal section:

charon-systemd {
  journal {
    default = 1
    ike = 2
    knl = 3
    # ...
Of course one may define traditional syslog and filelog loggers in the strongswan.conf charon-systemd section, refer to LoggerConfiguration for details. To disable the journal logger, set default = -1 to make it silent.

The journal based logger provides some additional metadata in custom journal fields:

Field Description
LEVEL numerical strongSwan log level
GROUP logging subsystem string
THREAD numerical thread identifier issuing the journal entry
IKE_SA_UNIQUE_ID IKE_SA unique identifier, if available
IKE_SA_NAME name of the IKE_SA configuration, if available

The MESSAGE field contains the log message, MESSAGE_ID uses a unique identifier specific to each log message type.

The log levels are also mapped to values stored in the PRIORITY field (0 to LOG_NOTICE, 1 to LOG_INFO, everything above to LOG_DEBUG, see syslog(3)).