Logging
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
:
-1 |
Absolutely silent |
0 |
Very basic auditing logs, (e.g. SA up/SA down) |
1 |
Generic control flow with errors, a good default to see whats going on |
2 |
More detailed debugging control flow |
3 |
Including RAW data dumps in hex |
4 |
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 |
|
CHILD_SA/IPsec SA |
|
Main daemon setup/cleanup/signal handling |
|
Packet encoding/decoding encryption/decryption operations |
|
libipsec library messages |
|
IKE_SA/ISAKMP SA |
|
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 |
Syslog loggers |
Log into a syslog facility. Configured in |
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. |
charon.filelog
Key | Default | Description |
---|---|---|
<name>.path |
The absolute path to the log file or stderr/stdout (since version 5.7.0). |
|
<name>.default |
|
Specifies the default loglevel to be used for subsystems for which no specific loglevel is defined |
<name>.<subsystem> |
<default> |
Log level for a specific subsystem |
<name>.append |
|
If this option is enabled log entries are appended to the existing file |
<name>.flush_line |
|
Enabling this option disables block buffering and enables line buffering, i.e. a flush to disk is enforced for each logged line |
<name>.ike_name |
|
Add the connection name and a unique numerical identifier for the current IKE_SA to each log entry if available |
<name>.json |
|
Enables writing each log entry as a JSON object to the file (since version 6.0.0).
The properties are "time" (if |
<name>.log_level |
|
Add the log level of each message after the subsystem (since version 5.9.1) |
<name>.time_format |
Prefix each log entry with a timestamp. The option accepts a format string as
passed to |
|
<name>.time_precision |
Add the milliseconds ( |
|
<name>.time_add_ms |
|
Adds the milliseconds within the current second after the timestamp (separated
by a dot so |
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
charon.syslog
Key | Default | Description |
---|---|---|
identifier |
Global identifier used for an |
|
<facility>.default |
|
Specifies the default loglevel to be used for subsystems for which no specific loglevel is defined |
<facility>.<subsystem> |
<default> |
Log level for a specific subsystem |
<facility>.ike_name |
|
Add the connection name and a unique numerical identifier for the current IKE_SA to each log entry if available |
<facility>.log_level |
|
Add the log level of each message after the subsystem (since version 5.9.1) |
<facility>.map_level |
|
Map strongSwan specific loglevels to syslog loglevels (since version 5.9.6) The default setting of |
The placeholder <facility>
is one of auth
or daemon
.
Example
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
CFLAGS="-DDEBUG_LEVEL=1"
to include logging messages of level 0
and 1
only.
Other Logging Backends
-
charon-systemd
logs to the systemd journal by default. -
The
VICI
plugin provides alog
event that delivers log messages (swanctl --log
subscribes to it. -
The
sql
plugin supports logging to a database if enabled viacharon.plugins.sql.loglevel
. -
Custom plugins may register their own implementation of the
logger_t
interface (src/libcharon/bus/listeners/logger.h
) with the bus (src/libcharon/bus/bus.h#L214
). -
In applications using
libcharon
, custom loggers (src/libcharon/bus/listeners/custom_logger.h
) may also be registered early from code viaregister_custom_logger()
(src/libcharon/daemon.h#L402
).charon-systemd
uses this mechanism for itsjournald
logger.
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.