TLS for rsyslog forwarding with the gtls driver, and when RELP is worth adding

What it is

rsyslog's TLS tutorial describes network stream drivers for encrypted syslog transport: gtls (GnuTLS) and, since rsyslog 8.36, ossl (OpenSSL), which take the same mode and auth-mode parameters. A minimal setup needs a CA certificate on both sides plus a certificate and key on the sender and the receiver, laid out as described in rsyslog's TLS Certificate Summary, which covers the X.509 material each role needs. The CA file is set globally (global(DefaultNetstreamDriverCAFile=...), plus DefaultNetstreamDriverCertFile/KeyFile). On the sending side, an omfwd action is extended with StreamDriver="gtls", StreamDriverMode="1" (TLS-only) and StreamDriverAuthMode set to x509/name (certificate validation plus a check of the peer's name against StreamDriverPermittedPeers="collector.example.org") or x509/certvalid (any certificate signed by the trusted CA, which the driver documentation calls weak and not recommended).

RELP (Reliable Event Logging Protocol) is a separate transport, provided by the omrelp/imrelp modules, described in rsyslog's documentation as the RELP output and input modules. Unlike plain omfwd over TCP or TLS, RELP acknowledges each message at the application layer, so the sender knows a message was actually processed by the receiver, not merely accepted by the TCP stack.

Why it matters

A successful send over plain TCP only means the bytes were handed to the network stack; if rsyslog on the collector crashes or the disk fills right after accepting the connection, messages already "sent" can be lost with no signal back to the sender. TLS over TCP inherits this property — encryption changes confidentiality and authentication, not delivery semantics. RELP is designed specifically to remove that gap.

How to apply

• Use TLS whenever log traffic crosses a network you do not fully control, even inside a datacenter; prefer StreamDriverAuthMode="x509/name" with StreamDriverPermittedPeers naming the collector, and treat x509/certvalid as a fallback only.
• Combine TLS with omrelp/imrelp (RELP can itself run over TLS) when message loss during a receiver failure is unacceptable — audit logs, compliance-relevant events — and the added complexity of an extra module pair on both ends is acceptable.
• For everyday application or system logs where an occasional lost message during a crash is tolerable, plain TLS over TCP with a disk-assisted queue on the sender is usually sufficient.
• Monitor certificate expiry: since rsyslog 8.2012.0, StreamDriver.PermitExpiredCerts defaults to off, so an expired certificate makes the TLS handshake fail; forwarding stops (errors appear in rsyslog's own log) and messages pile up in the queue.

Pitfalls

• Leaving StreamDriverAuthMode unset (its omfwd default is driver-specific) or using anon, which the driver documentation says does not authenticate the peer and is open to man-in-the-middle attacks.
• Assuming TLS alone guarantees delivery; it does not, and RELP is the documented answer to that specific gap.
• Forgetting that RELP needs its own port and firewall rule distinct from the plain syslog TCP/TLS port.