Syslog forwarding over TLS: getting the operational layer right

Plaintext syslog crossing a network boundary in 2026 is a finding waiting to happen. The IETF defined encrypted syslog years ago in RFC 5425: TCP/6514, mutual TLS where the trust model needs it. What still trips teams up is rarely the protocol itself — it’s certificate lifecycle, framing mismatches, and forwarders that fall over when the collector blinks. Here’s the short version: which standards matter, where teams break the framing, and the four operational habits that decide whether the pipeline holds up.

The standards that matter

You don’t need to memorize the full RFC family, but you should know which one your auditor or peer will reference:

RFC 5425: TLS transport mapping for syslog. The threat model it covers: eavesdropping, modification, and masquerade between transport sender and receiver. This is the spec your auditor will cite.
RFC 5424: The structured syslog message format, with higher-precision timestamps and structured data fields. It replaces the older BSD format from RFC 3164.
RFC 6587: Plain TCP transport, including octet-counting framing.
RFC 6012: DTLS mapping for environments that can’t hold a long-lived TCP session.
RFC 9662: Updates the mandatory cipher suites for RFC 5425. ECDHE/GCM (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) is now preferred over the older RSA/CBC suite.

Ports and the framing trap

The port map is short:

TCP/6514: IANA-assigned for syslog over TLS. The one you want.
TCP/601: Reliable syslog over plain TCP (RFC 3195).
UDP/TCP 514: Legacy plaintext. Retire it for anything crossing a trust boundary or carrying regulated data.

RFC 5425 mandates octet-counting framing — the framing layer prefixes each message with its byte length and a space: MSG-LEN SP SYSLOG-MSG. Some implementations send newline-terminated messages instead, which silently breaks compliance and truncates multi-line events at the receiver. The pipeline keeps running. Your stack traces and Windows event payloads quietly lose their tails. Test for this explicitly — don’t take a vendor’s word for it.

One-way TLS or mTLS?

Server-only authentication is the right answer when you’re sending to a hosted SIEM that doesn’t enroll client certificates. The forwarder verifies the collector against a trusted CA, and the wire is encrypted. That’s the whole story.

For anything internal, regulated, or carrying audit evidence, use mutual TLS. Both ends present certificates. The collector rejects anything that doesn’t authenticate. This matters more than the encryption itself: an attacker who’s already inside the network can otherwise forge log events into your SIEM, poison correlation rules, and bury their own activity in the noise.

What TLS fixes, and what it doesn’t

TLS covers three of the four classical syslog threats: confidentiality, integrity, and peer authentication. It does nothing for availability. Solve that with disk-assisted queues on the forwarder and failover targets on the collector — not by reaching for a bigger cipher.

The compliance side is direct. PCI DSS Requirement 10 calls for audit log retention of at least one year, with the most recent 90 days available without restore. HIPAA pushes that to six years for ePHI-adjacent logs. GDPR doesn’t name TLS, but "appropriate technical measures" for log traffic in transit means encryption — and encryption in transit means this.

Operational gotchas worth a checklist

Certificate lifecycle: Expired certificates are the top cause of silent log loss in TLS syslog pipelines. Monitor expiry on every forwarder and collector, automate rotation, and test your revocation path before you need it. A CRL or OCSP endpoint that’s never been exercised is a failed control.
Cipher policy: TLS 1.2 floor, prefer TLS 1.3. Pin to AEAD suites — GCM and ChaCha20-Poly1305. Disable CBC where you can, even though RFC 9662 still lists one CBC suite as mandatory-to-implement.
Back-pressure: TLS adds CPU cost and framing overhead. Benchmark at realistic EPS, not at idle. Put a disk-assisted queue on the forwarder so a collector outage delays events instead of dropping them.
Time sync: TLS doesn’t fix clock skew, and your SIEM correlation rules break the moment two sources disagree on what "now" means. Run NTP everywhere and normalize timestamps to UTC at ingest.

The four habits in one config

NXLog Agent handles both sides of a TLS syslog pipeline without a separate forwarder and collector product. The relevant modules:

TLS/SSL input — for the receiving side.
TLS/SSL output — for the sending side.
Syslog extension — RFC 5424/3164 message formatting plus the RFC 5425 framing writer.

For example, here’s a sender configuration that puts framing, mTLS, handshake visibility, cipher pinning, and disk-assisted buffering in one place, with a failover target:

<Extension syslog>
    Module                   xm_syslog
</Extension>

<Input local_syslog>
    Module                   im_uds
    UDS                      /dev/log
</Input>

<Output secure_siem>
    Module                   om_ssl
    Host                     siem-primary.example.com:6514
    Host                     siem-secondary.example.com:6514
    OutputType               Syslog_TLS
    CAFile                   %CERTDIR%/ca.pem
    CertFile                 %CERTDIR%/agent.pem
    CertKeyFile              %CERTDIR%/agent.key
    AllowHostnameValidation  TRUE
    SSLProtocol              TLSv1.2, TLSv1.3
    TLSCertLog               TRUE
    TcpSendStallDetect       TRUE
    PersistLogqueue          TRUE
    LogqueueSize             2147483648
    Exec                     to_syslog_ietf();
</Output>

<Route r1>
    Path                     local_syslog => secure_siem
</Route>

Framing: OutputType Syslog_TLS selects the RFC 5425 octet-counting writer registered by xm_syslog — no newline-truncation surprises at the receiver. The <Extension syslog> block loads xm_syslog so that writer and the to_syslog_ietf() procedure are available. Without the extension, NXLog Agent fails to start.
Certificate lifecycle: om_ssl defaults to AllowUntrusted FALSE, so the sender already refuses to connect to a collector whose certificate doesn’t validate against the trusted CA. AllowHostnameValidation TRUE prevents another system from impersonating the remote server. TLSCertLog TRUE writes the Subject, Issuer, NotBefore, and NotAfter fields of a failing peer certificate into the NXLog Agent log. Alert on those entries. A forwarder that’s been emitting handshake failures for three hours is a control failure you want your SIEM catching before your auditor does.
Cipher policy: om_ssl defaults to TLS 1.2 and 1.3, and the default SSLCiphersuites value for TLS 1.3 is TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256 — three AEAD suites, no negotiation surprises. Setting SSLProtocol TLSv1.2, TLSv1.3 in the config makes the floor explicit for an auditor. Override SSLCipher and SSLCiphersuites directly if your compliance regime pins a specific list.
Back-pressure: PersistLogqueue TRUE switches the output module’s incoming queue from memory to disk, sized by LogqueueSize (2 GiB in the example; from NXLog Agent v6 onward the value is in bytes). When the primary collector drops, events accumulate on disk while the failover Host line picks up the live traffic. TcpSendStallDetect TRUE logs a warning when the send buffer is full, so you see back-pressure happening instead of guessing at it. An outage costs you delay, not evidence.
Time sync: Outside NXLog Agent’s scope, but a habit either way. Keep NTP on every node and normalize timestamps to UTC at ingest, or correlation across sources fails regardless of how well the rest is configured.

This setup fits three common deployments. PCI- and HIPAA-regulated workloads forwarding into a hosted SIEM; mixed Windows/Linux estates that need a single agent on both sides; and cross-region forwarding where you can’t trust the WAN segment to stay quiet.

Conclusion

The protocol question is settled. The work that’s left is operational. Get the framing right, then build the four habits: automate certificate rotation before it bites you, pin cipher policy where compliance demands it, design for back-pressure, and keep your clocks honest. Do those things and TLS becomes the boring layer of your logging stack — which is where you want it.

NXLog Platform is an on-premises solution for centralized log management with
versatile processing forming the backbone of security monitoring.

With our industry-leading expertise in log collection and agent management, we comprehensively
address your security log-related tasks, including collection, parsing, processing, enrichment, storage, management, and analytics.

Start free Contact us