Remote syslog to observability — forwarding OPNsense logs to a SIEM or log server · OPNsense

Remote syslog forwarding is the integration point between OPNsense and the rest of the estate’s observability stack. The firewall produces logs; the SIEM, log server, or cloud destination consumes them. The configuration is straightforward — a destination, a transport, an optional certificate, and a per-facility rule. The discipline is in the verification: confirming the messages actually arrive, that they arrive in the right format, and that the forwarding survives reboots, link failures, and certificate renewals.

The GUI configuration

System → Settings → Logging, “Remote” tab, is the entry point. Each destination is a separate row with these fields:

Enabled: per-destination toggle.
Transport: UDP, TCP, or TLS, each over IPv4 or IPv6 — the IP version is part of the choice, not a separate field.
Applications: the programs to forward. Empty means all of them.
Levels: the severities to forward. Empty means all of them.
Facilities: the facilities to forward. Empty means all of them.
Hostname: the destination host or address.
Port: defaults to 514.
Certificate: the client certificate presented on TLS transports.
Description: free text, used to label the destination.

There is also an RFC 5424 toggle, off by default, which sends the structured format instead of the older BSD format. Note the asymmetry: the local files are always written in RFC 5424, but forwarding falls back to RFC 3164 unless this is switched on.

Read-only / Safeforwarding state in the system log— configctl syslog status confirms the daemon is running. syslog-ng writes its own messages under an unclaimed program name, so they fall through to the system log where they can be grepped. The connection to the receiver came up at 16:30 and broke at 16:41, and time_reopen shows it will retry after sixty seconds. A single broken-and-reestablished pair is a receiver restart; the same pair every minute is a reconnection loop, which usually means a certificate or firewall problem on the path rather than a syslog problem.

$ configctl syslog status; echo '---'; grep -i 'syslog-ng' /var/log/system/latest.log | tail -2

Checking syslog-ng status. Running
---
<131>1 2026-08-14T16:30:02+00:00 opnsense.example.com syslog-ng 61204 - [meta sequenceId="813"] Syslog connection established; fd='14', server='AF_INET(198.51.100.60:6514)', local='AF_INET(0.0.0.0:0)'
<131>1 2026-08-14T16:41:57+00:00 opnsense.example.com syslog-ng 61204 - [meta sequenceId="907"] Syslog connection broken; fd='14', server='AF_INET(198.51.100.60:6514)', time_reopen='60'

Illustrative output

Per-facility routing

OPNsense supports sending different facilities to different destinations. The use cases:

Security logs (PF, IDS, auth) → SIEM over TLS.
Operational logs (system, services) → log aggregation over TCP.
Debug-level noise → local sink only.

The configuration is the Applications, Levels, and Facilities fields on each destination. Each is a multi-select, each defaults to empty meaning “everything”, and a destination that sets more than one narrows on all of them at once — a destination with Applications set to filterlog and Levels set to notice and above forwards only filter records at notice or above.

TLS setup

TLS syslog requires certificates on both ends:

On the OPNsense side:

The CA certificate that signed the receiver’s certificate must be in OPNsense’s trust store. Import via System → Trust → Authorities.
Optionally, a client certificate for mutual TLS. Import via System → Trust → Certificates.

On the receiver side:

A server certificate signed by a CA the firewall trusts. The certificate’s CN or SAN must match the destination hostname (so the firewall can validate it).
Optionally, the CA that signed the firewall’s client certificate, to validate mutual TLS.

The receiver’s configuration (rsyslog example):

# rsyslog.conf
module(load="imtcp"
       StreamDriver.Name="gtls"
       StreamDriver.Mode="1"   # require TLS
       StreamDriver.AuthMode="x509/certvalid"
       PermittedPeer="opnsense.example.com"
      )
input(type="imtcp" port="6514")

StreamDriver.Mode="1" requires TLS — connections without TLS are rejected. PermittedPeer validates the firewall’s certificate against the expected CN/SAN. x509/certvalid checks the chain against the trust store.

Read-only / SafeTLS receiver verification— openssl s_client connects to siem.example.com:6514 and validates the certificate chain. The receiver presents a certificate for siem.example.com signed by the OPNsense Internal CA. verify return:1 means the chain validated. Protocol is TLSv1.3. The operator should confirm: the receiver hostname matches, the CA is the expected one, the protocol is TLSv1.3 (or 1.2 at minimum), and the chain validates.

$ openssl s_client -connect siem.example.com:6514 -CAfile /etc/ssl/siem-ca.crt 2>&1 | grep -E 'subject=|issuer=|verify return|Protocol'

subject=CN = siem.example.com
issuer=CN = OPNsense Internal CA, O = Estate Internal
verify return:1
Protocol  : TLSv1.3

Illustrative output

Verification

The end-to-end check uses logger to inject a known test message and tcpdump (or the receiver’s logs) to confirm it arrived.

Read-only / Safeforwarding test— logger injects a message with a unique tag so the operator can find it at both ends. The tag test-forward is not claimed by any local filter, so the message falls through to the system log — which is why the severity has to be notice or above. Sent at info it would be discarded locally, and the operator would wrongly conclude logging was broken. Confirm the line locally, then confirm the same string on the receiver.

$ logger -p local0.notice -t test-forward 'verify remote forwarding 12345'; sleep 2; grep 'verify remote' /var/log/system/latest.log

<133>1 2026-08-14T16:30:01+00:00 opnsense.example.com test-forward 62110 - [meta sequenceId="8321"] verify remote forwarding 12345

Illustrative output

The second check is over time. The operator should confirm:

Steady-state forwarding — a continuous flow of messages from the firewall.
No reconnection storms — syslog-ng should reconnect once after a remote restart, not once a minute. The system log records each break and each re-establishment, so the pattern is visible without touching the receiver.
No certificate errors — TLS handshake should succeed on every reconnection.

Common failures

The remote-forwarding deployment has a few characteristic failure modes:

Symptom	Likely cause	Fix
No messages at receiver	`syslog-ng` not running, destination not enabled, firewall blocking the port	Check `configctl syslog status`, enable the destination, open the port
TLS handshake failures	Certificate expired, hostname mismatch, untrusted CA	Renew certificate, fix SAN, import CA
Sporadic drops	Network congestion, receiver overloaded, TCP retransmits	Increase receiver capacity, check network
Reconnection loops	Receiver bouncing, certificate issue, network flap	Check receiver logs, certificate
Wrong format at receiver	RFC mismatch between sender and receiver	Match RFC version (both 5424 or both 3164)
Messages arrive but with wrong facility	Facility mismatch in routing	Verify syslog.conf routing

Why the firewall needs to validate the receiver's certificate

TLS without certificate validation is encryption, not authentication. The firewall encrypts the messages to whoever is listening on the port. An attacker who can position themselves between the firewall and the receiver — by ARP spoofing, by DNS poisoning, by compromising a switch — can present their own certificate and receive the logs.

Without hostname validation, the firewall accepts any certificate signed by any CA in its trust store. An attacker who can obtain a certificate for any domain (a rogue CA, a mis-issued certificate) can MITM the connection.

With hostname validation, the firewall only accepts certificates whose CN or SAN matches the destination hostname. The attacker cannot obtain a certificate for siem.example.com unless they compromise the CA or the receiver.

The discipline: TLS with hostname validation, mutual TLS where the receiver supports it. The certificates are not optional; they are the authentication that prevents MITM.

Capacity planning

Forwarding volume matters. A firewall with TLS interception and Suricata may produce thousands of log lines per second at peak. The receiver must be able to absorb that:

Disk I/O: the receiver writes every message to disk. SSD is recommended; spinning disk is the bottleneck for high-volume syslog.
Network bandwidth: each syslog message is 100 to 1000 bytes. At 10,000 messages per second, the bandwidth is 1 to 10 MB/s. The link between the firewall and the receiver must carry this.
Indexing: the SIEM (Splunk, Elastic) indexes every field. Indexing is CPU-intensive; budget for it.

The operator who deploys remote forwarding without sizing the receiver has built a system that drops messages under load. The discipline: size the receiver for peak volume, monitor queue depth, alert on drops.

Multiple destinations

Some estates split forwarding across destinations:

SIEM (Splunk, Elastic) for security-relevant logs.
Log aggregation (Graylog, Loki) for operational logs.
Cloud-native (Datadog, Grafana Cloud) for vendor-managed retention.

OPNsense supports multiple destinations with per-destination facility filters. The configuration is in the GUI. The discipline: use one destination by default; add others with reason.