Not all logs from strongswan available

Elastic Observability Logs
1

Hi,

I have StrongSwan installed on a debian 13 machine. The logs are written to the journal. I use elastic-agent in version 9.3.3 trying to read this logs, the stack is in version 9.3.3, too. journalctl -u strongswan shows:

Jun 29 15:49:09 debian-ts.local charon-systemd[11574]: loaded plugins: charon-systemd aesni random nonce x509 revocation constraints pubkey pkcs1 pkcs7 dnskey sshkey pem openssl pkcs8 agent gcm drbg attr kernel-netlink resolve socket-default connmark vici updown eap-mschapv2 xauth-generic counters
Jun 29 15:49:09 debian-ts.local charon-systemd[11574]: dropped capabilities, running as uid 0, gid 0
Jun 29 15:49:09 debian-ts.local charon-systemd[11574]: spawning 16 worker threads
Jun 29 15:49:09 debian-ts.local swanctl[11609]: plugin 'test-vectors': failed to load - test_vectors_plugin_create not found and no plugin file available
Jun 29 15:49:09 debian-ts.local swanctl[11609]: plugin 'ldap': failed to load - ldap_plugin_create not found and no plugin file available

In Kibana I only see swanctl logs, but no charon-systemd logs.

Why are the charon-systemd logs missing? How can I debug this? What can I do to see all logs from the journal?

Best regards,

Robert

2

Hi @leprovokateur,

Where does your elastic-agent read the log files from? Is it possible that it's not reading the journal itself, but reading the swanctl logs from a file, but not the charon logs?

3

Hi @weltenwort ,

Thank you for your response.

I use the default configuration of the system integration:

grafik
grafik796×773 65.1 KB

The condition configured using journald is by default is ${host.os_version} == "13 (trixie)", which is the case.

Disabling "Collect logs from System instances using Jounald" leads to no logs ingested anymore, as I expected.

Strangest thing is that charon-systemd is the only "log.syslog.appname" not appearing in Discover, but in the journal.

4

That is curious indeed :thinking: And it doesn't show up either if you just search for it via the `process.pid` field?

5

I checked and I found every pid from the journal also in Discover, except charon-systemd.

6

Trying to think of reasons why it might be omitted :thinking: Not that it seems likely, but does the charon systemd unit declare a different log namespace? Or do any of the log entry fields look unusual (via `--output=verbose`)?

7

another hypothesis: The strongswan docs suggest that charon-systemd logs to the journal directly using the journal API and not via the kernel's logging API. That might result in the log entry being recorded with a different `_TRANSPORT` which the system's "syslog" data stream filters out.

8

The swanctl log entries have a SYSLOG_FACILITY=3, this is missing completely in the charon-systemd logs:

Tue 2026-06-30 10:54:25.703578 CEST [s=d33f62ceb9684ec0abba122aa333e32e;i=490;b=b2adc684c22d4973a38fbf6ec9356943;m=2b9837f;t=65574b8d38ea3;x=bd2ba8f196f465f2]
_BOOT_ID=b2adc684c22d4973a38fbf6ec9356943
_MACHINE_ID=04847b071bf6476380c397d4f6c6fca3
_HOSTNAME=debian-ts.local
_RUNTIME_SCOPE=system
PRIORITY=6
_UID=0
_GID=0
_SELINUX_CONTEXT=kernel
_SYSTEMD_SLICE=system.slice
_TRANSPORT=journal
_CAP_EFFECTIVE=1ffffffffff
LEVEL=1
THREAD=0
SYSLOG_IDENTIFIER=charon-systemd
_PID=1386
_COMM=charon-systemd
_EXE=/usr/sbin/charon-systemd
_CMDLINE=/usr/sbin/charon-systemd
_SYSTEMD_CGROUP=/system.slice/strongswan.service
_SYSTEMD_UNIT=strongswan.service
_SYSTEMD_INVOCATION_ID=d3489cdcb8ff404e95cf01858d468977
MESSAGE=spawning 16 worker threads
MESSAGE_ID=57d2708c-d607-43bd-8c39-66bf3cb56dac
GROUP=JOB
_SOURCE_REALTIME_TIMESTAMP=1782809665703578
Tue 2026-06-30 10:54:25.876078 CEST [s=d33f62ceb9684ec0abba122aa333e32e;i=492;b=b2adc684c22d4973a38fbf6ec9356943;m=2bc254b;t=65574b8d6306e;x=a2e00432c002a426]
_BOOT_ID=b2adc684c22d4973a38fbf6ec9356943
_MACHINE_ID=04847b071bf6476380c397d4f6c6fca3
_HOSTNAME=debian-ts.local
_RUNTIME_SCOPE=system
PRIORITY=6
SYSLOG_FACILITY=3
_UID=0
_GID=0
_SELINUX_CONTEXT=kernel
_SYSTEMD_SLICE=system.slice
_CAP_EFFECTIVE=1ffffffffff
_TRANSPORT=stdout
_SYSTEMD_CGROUP=/system.slice/strongswan.service
_SYSTEMD_UNIT=strongswan.service
_SYSTEMD_INVOCATION_ID=d3489cdcb8ff404e95cf01858d468977
_STREAM_ID=d4301fd5b3c1471eb9dbfa79e40940dd
SYSLOG_IDENTIFIER=swanctl
MESSAGE=plugin 'test-vectors': failed to load - test_vectors_plugin_create not found and no plugin file available
_PID=1550
_COMM=swanctl
_EXE=/usr/sbin/swanctl
_CMDLINE=/usr/sbin/swanctl --load-all --noprompt
9

I think you might have found the reason there. Looking at integrations/packages/system/data_stream/syslog/agent/stream/journald.yml.hbs at main · elastic/integrations · GitHub I see it explicitly filters for a set of syslog facilities. If the entry doesn't have any it might not be included

10

I can think of two ways to work around that in the short term. Either configure strongswan to log to syslog ( Logging :: strongSwan Documentation ) or add a separate journald integration to the agent which doesn't have that facility filter (and maybe instead filter to target everything that doesn't have any facility).

11

I didn't achieve to give the charon-systemd logs a SYSLOG_FACILITY, neither via the systemd unit, nor via strongswan config. Is it possible to configure the elastic-agent to grab logs, that don't have a SYSLOG_FACILITY?

12

Sorry to hear that. Yes, you should be able to use the journald integration to do so. You might want to add a filtering processor after it to avoid ingesting the entries with a facility twice, though.