By default, the IKE charon daemon logs via syslog(3) using the facilities LOG_AUTHPRIV (only messages on log level 0) and LOG_DAEMON (all log levels). The default log level for all subsystems is 1.

Where the log messages eventually end up depends on how syslog is configured on your system. Common places are /var/log/daemon, /var/log/syslog or /var/log/messages.

Unlike charon, charon-systemd by default logs to the systemd journal and not to syslog by default. The log levels are configurable in a separate section in strongswan.conf which is not described here.

Levels and Subsystems/Groups

The IKE daemon knows different numerical levels of logging ranging from -1`to `4:


Absolutely silent


Very basic auditing logs, (e.g. SA up/SA down)


Generic control flow with errors, a good default to see whats going on


More detailed debugging control flow


Including RAW data dumps in hex


Also include sensitive material in dumps, e.g. keys

Each logging message also has a source from which subsystem in the daemon the log came from:


applications other than daemons


Low-level encoding/decoding (ASN.1, X.509 etc.)


Configuration management and plugins




Main daemon setup/cleanup/signal handling


Packet encoding/decoding encryption/decryption operations


libipsec library messages




Integrity Measurement Collector


Integrity Measurement Verifier


Jobs queuing/processing and thread pool management


IPsec/Networking kernel interface


libstrongswan library messages


IKE_SA manager, handling synchronization for IKE_SA access


IKE network communication


Platform Trust Service


libtls library messages


Trusted Network Connect

Configuration in strongswan.conf

strongSwan provides a flexible configuration of the loggers in strongswan.conf. There currently are two types:

File loggers

Log directly into a file. Configured in charon.filelog section

Syslog loggers

Log into a syslog facility. Configured in charon.syslog section

Multiple loggers can be set up for each type, with different log verbosity for the different subsystems of the daemon.

The logger configuration is reloaded if the daemon receives a SIGHUP signal which causes the daemon to reload strongswan.conf and the plugins (since version 5.5.2 this also works for charon-systemd). Besides changing the configuration this allows to easily rotate log files created by file loggers without having to restart the daemon. Since version 5.5.2 the swanctl --reload-settings command also reloads the loggers, thus having the same functionality as sending a SIGHUP signal.

The following options are supported for each logger:

File Loggers

Since version 5.7.0 section names can’t contain dots or colons. To specify such paths use the path setting in an arbitrarily named section.


Key Default Description


The absolute path to the log file or stderr/stdout (since version 5.7.0).



Specifies the default loglevel to be used for subsystems for which no specific loglevel is defined



Log level for a specific subsystem



If this option is enabled log entries are appended to the existing file



Enabling this option disables block buffering and enables line buffering, i.e. a flush to disk is enforced for each logged line



Prefix each log entry with the connection name and a unique numerical identifier for each IKE_SA



Add the log level of each message after the subsystem (since version 5.9.1)


Prefix each log entry with a timestamp. The option accepts a format string as passed to strftime(3)



Adds the milliseconds within the current second after the timestamp (separated by a dot so time_format should end with %S or %T)

The placeholder <name> is an arbitrary name if path is specified and otherwise either an absolute file path in the filesystem or one of stdout or stderr.

Syslog Loggers


Key Default Description


Global identifier used for an openlog(3) call prepended to each log message by syslog. If not configured, openlog(3) is not called. Thus the value will depend on system defaults (often the program name)



Specifies the default loglevel to be used for subsystems for which no specific loglevel is defined



Log level for a specific subsystem



Prefix each log entry with the connection name and a unique numerical identifier for each IKE_SA



Add the log level of each message after the subsystem (since version 5.9.1)



Map strongSwan specific loglevels to syslog loglevels (since version 5.9.6).

The default setting of -1 passes all messages to syslog using a log level of LOG_INFO. A non-negative value maps the strongSwan specific loglevels (0..4) to the syslog level starting at the specified number. For example, a value of 5 (LOG_NOTICE) maps strongSwan loglevel 0 to LOG_NOTICE, level 1 to LOG_INFO, and levels 2, 3 and 4 to LOG_DEBUG. This allows (additional) filtering of log messages on the syslog server.

The placeholder <facility> is one of auth or daemon.


An example configuration might look like this:

charon {

  # two defined file loggers
  filelog {
    charon {
      # path to the log file, specify this as section name in versions prior to 5.7.0
      path = /var/log/charon.log
      # add a timestamp prefix
      time_format = %b %e %T
      # prepend connection name, simplifies grepping
      ike_name = yes
      # overwrite existing files
      append = no
      # increase default loglevel for all daemon subsystems
      default = 2
      # flush each line to disk
      flush_line = yes
    stderr {
      # more detailed loglevel for a specific subsystem, overriding the
      # default loglevel.
      ike = 2
      knl = 3

  # and two loggers using syslog
  syslog {
    # prefix for each log message
    identifier = charon-custom
    # use default settings to log to the LOG_DAEMON facility
    daemon {
    # very minimalistic IKE auditing logs to LOG_AUTHPRIV
    auth {
      default = -1
      ike = 0
 # ...

Compile Time Configuration

Debug statements can be stripped from the binaries during compile time. Define DEBUG_LEVEL to the maximum level you want to include, for instance


to include logging messages of level 0 and 1 only.

Other Logging Backends

Performance Considerations

Some parts of the logging system of charon are currently synchronized (e.g. to ensure multi-line log messages are logged together). If performance is critical, reduce the compiled-in debugging level and reduce loggers to a minimum. Depending on your syslog configuration, syslog calls are very expensive if they flush everything to disk. Logging directly to a file might be a lot faster, especially if you are running charon on multiple cores.