Syslog protocol and format — the wire format every log forwarder speaks · OPNsense

Every log that leaves OPNsense for a remote destination is a syslog message. Syslog is the lingua franca of network device logs — every firewall, switch, server, and application either speaks it natively or can be configured to speak it. Understanding the wire format, the priority value, the transport choices, and the failure modes is the prerequisite to configuring remote forwarding correctly and debugging the “the SIEM did not get the log” problem.

The syslog message

A syslog message has three parts:

Priority value (PRI): a number that encodes the facility and severity in one byte.
Header: timestamp, hostname, app-name, procid, msgid.
Message: the human-readable content, optionally with structured data.

The full format (RFC 5424):

<PRI>1 TIMESTAMP HOSTNAME APP-NAME PROCID MSGID STRUCTURED-DATA MSG

The minimum format (RFC 3164):

<PRI>TIMESTAMP HOSTNAME MSG

A real example:

<165>1 2026-08-14T16:30:01.000Z opnsense filterlog 1234 - - - 5,16777216,,1000000103,igb0,match,block,...

Breaking it down:

<165> is the priority value (facility 20, severity 5).
1 is the version (RFC 5424).
2026-08-14T16:30:01.000Z is the timestamp.
opnsense is the hostname.
filterlog is the app-name.
1234 is the process ID.
- - - is the structured data (empty here).
The rest is the message.

The priority value

The priority value (PRI) is one byte. It encodes:

Facility (upper 3 bits): the source category. 0 = kern, 1 = user, 2 = mail, 3 = daemon, 4 = auth, …, 16 = local0, 17 = local1, …, 23 = local7.
Severity (lower 3 bits): 0 = emerg, 1 = alert, 2 = crit, 3 = err, 4 = warning, 5 = notice, 6 = info, 7 = debug.

The formula: PRI = facility * 8 + severity.

For filter log records (local0, info): facility = 16, severity = 6, PRI = 16 * 8 + 6 = 134. That is why every line in /var/log/filter/ opens with <134>.

For an SSH authentication message (auth, info): facility = 4, severity = 6, PRI = 4 * 8 + 6 = 38. Those land in /var/log/audit/, which claims the whole auth facility.

The PRI is the first thing in the syslog packet. A remote server parses it to decide where to store the message — but note that OPNsense itself does not route on it. Local destinations are selected by program name, with the facility used only by the audit and legacy VPN filters.

Read-only / Safelogger test message— logger injects a message at local0.info, which is PRI 134, with the tag filterlog. It lands in /var/log/filter/ because the local filter for that destination matches on the program name the tag becomes, not on the facility — send the same message with a different tag and it goes somewhere else entirely. This is the cheapest way to prove a routing path end to end. The line will not appear in the parsed Live View, because the payload is not a valid filterlog record and the parser skips it.

$ logger -p local0.info -t filterlog 'test message from operator'; tail -1 /var/log/filter/latest.log

<134>1 2026-08-14T16:30:01+00:00 opnsense.example.com filterlog 63314 - [meta sequenceId="9912"] test message from operator

Illustrative output

Transport choices

Syslog can run over three transports:

Transport	Reliability	Encryption	Use case
UDP (port 514)	None — fire and forget	None	Low-value, high-volume, local network
TCP (port 6514, formerly 514)	Reliable — TCP guarantees	None	Most production deployments
TLS (port 6514)	Reliable + encrypted	Yes	Sensitive logs, regulatory, multi-tenant

UDP is the original. It is connectionless — the sender writes the packet and forgets. The receiver may or may not get it. UDP is fine for high-volume, low-value logs (debug-level noise) where occasional loss is acceptable. UDP is not fine for security logs where every entry matters.

TCP adds reliability. The receiver acknowledges receipt. The sender retries on failure. TCP is the production default. The cost is overhead — each log line is a TCP segment, and the sender must manage connections (typically a single long-lived connection to the remote).

TLS adds encryption on top of TCP. The syslog messages are wrapped in a TLS session; intermediate observers see only ciphertext. TLS is required when logs contain sensitive content (PII, credentials, security events that could be used by an attacker who has positioned themselves on the path).

Framing

TCP and TLS syslog need framing — a way to delimit messages on the wire. RFC 6587 defines two:

Octet counting: each message is prefixed with its length in ASCII digits followed by a space. 165 2026-08-14... (length is “165”).
Non-transparent framing: each message ends with a trailing newline (\n). The receiver reads until newline.

Octet counting is more robust — the receiver knows exactly how many bytes to read for each message. Non-transparent framing breaks if a message contains an embedded newline (which some applications emit).

OPNsense supports both. The default is usually octet counting; the remote server should be configured to accept it.

The failure modes

Each transport has characteristic failures:

UDP: silent loss. The sender has no way to know the message was dropped. The receiver may have been down, the network may have been congested, the firewall may have been blocking. The operator who relies on UDP for security logs is missing entries and does not know.

TCP: connection drop. The sender keeps a long-lived TCP connection; when the remote restarts, the connection is broken. The sender must detect the break and reconnect. syslog-ng reconnects on its own after time_reopen seconds, but there is a window during which messages are lost.

TLS: certificate validation. The sender must trust the receiver’s certificate. If the receiver’s certificate expires, is self-signed, or has a hostname mismatch, the TLS handshake fails and no messages flow. The operator who configured TLS without monitoring the certificate is in for a surprise at expiry.

Read-only / Safesyslog wire capture— tcpdump captures syslog traffic (UDP 514 or TCP/TLS 6514) on igb1 for one second. logger injects a test message. The capture file should contain the message in plaintext (UDP/TCP) or encrypted (TLS). The operator who captures on UDP sees the message text directly — proof that unencrypted syslog is human-readable on the wire. The operator who captures on TLS sees only ciphertext.

$ tcpdump -ni igb1 -s 0 -w /tmp/syslog.pcap port 514 or port 6514 &
sleep 1
logger -p local0.info -t test 'syslog capture test'
sleep 1
kill %1 2>/dev/null
ls -la /tmp/syslog.pcap 2>/dev/null

-rw-r--r--  1 root wheel  1423 Aug 14 16:30 /tmp/syslog.pcap

Illustrative output

What the remote server expects

Different remote syslog servers expect different things:

rsyslog (Linux): accepts RFC 3164, RFC 5424, both framing modes, all transports. Default on most Linux distributions.
syslog-ng: accepts RFC 3164 and RFC 5424, both framing modes, all transports. Premium features (TLS, RELP) in the commercial version.
Windows Event Collector: requires an agent (e.g., nxlog) to translate syslog to Windows Event Log format.
SIEMs (Splunk, Elastic, Sumo): typically use an agent (forwarder) on the source or accept syslog via a receiver. Splunk’s universal forwarder speaks syslog; Elastic’s Logstash accepts syslog directly; Sumo’s collector accepts syslog.
Cloud-native (Datadog, Grafana Cloud): agent-based, but the agent can accept syslog from devices that cannot run an agent.

The operator should pick the transport and format the receiver expects. The default for production is TCP with octet counting and (where sensitive) TLS.

Why RFC 5424 has structured data and what it is for

RFC 3164 messages are just text — a timestamp, a hostname, and a free-form message. Parsing requires regex. Different vendors put different fields in different positions.

RFC 5424 messages have structured data — key-value pairs the receiver can parse unambiguously. Example:

[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

The structured data uses square brackets, an SD-ID (a unique identifier the sender registers), and key-value pairs. The receiver can extract eventID=1011 without parsing the message text.

Why this matters: a SIEM that ingests structured data can index fields and run queries (eventID=1011 AND severity>=4). A SIEM that ingests free-form text has to regex-parse every message, which is fragile and slow.

The discipline: use RFC 5424 with structured data where the source supports it. Suricata’s EVE JSON is structured; PF logs are not (they are comma-separated, requiring a parser). The receiver should be chosen to handle the formats the sources send.

Summary

Syslog has a priority value (facility * 8 + severity), a header, and a message.
RFC 3164 is legacy; RFC 5424 is structured and modern. Use RFC 5424.
Transport choices: UDP (lossy), TCP (reliable), TLS (encrypted). Use TLS for sensitive logs.
Each transport has characteristic failure modes. UDP: silent loss. TCP: connection drops. TLS: certificate expiry.
The remote server expects a specific format and transport. Match the receiver.