How to Send Appliance Logs to a Remote Collector Securely

The appliance can emit logs, the collector sits on the other side of the internet, and the first question everybody asks is which tunnel to build. That framing starts in the wrong place. What decides the transport is the format the appliance can produce, the authentication the collector will accept, and what "delivered" is supposed to mean when the link drops. Get those three answers written down and the transport usually chooses itself.

Start from what the appliance can emit

There are only three shapes in practice. Individual syslog events over UDP or TCP, an authenticated HTTPS upload built into the product, or complete files written to disk that have to be moved. A firewall that can only send UDP syslog will not become a TLS sender because you added a tunnel; it will still send unacknowledged datagrams, now inside an encrypted envelope.

So inventory the sender first: protocol, TLS support and which TLS library, whether it can validate the collector's certificate, whether it can present a client certificate, and whether the send buffer survives a reboot. Anything the appliance cannot do has to be done by something else in the path, and that something else becomes part of your design.

TLS syslog: shortest path when both ends speak it

If the appliance supports syslog over TLS and the collector terminates it, use that and stop. The application protocol protects itself, the collector authenticates the sender, and there is no extra hop whose availability you now own. The catch is that "TLS syslog" covers a wide range of implementations, and the current secure-syslog guidance has moved on from the cipher lists in older tutorials, which is how a working forwarder becomes a broken one after a library upgrade.

On rsyslog, the transport module name alone tells you which era you are on: lmnsd_gtls wraps GnuTLS, while lmnsd_ossl wraps OpenSSL and is what current 8.x packages ship. A forward action with certificate verification looks roughly like this, and the exact parameter names are worth checking against your installed version:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Verify the endpoint before you debug the sender. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error either completes a handshake with a valid chain or tells you precisely which check failed. Test from the appliance, not from your laptop, because the appliance's trust store is the one that matters.

SFTP: good for files, wrong for streams

File-based delivery suits appliances that write rotated logs and nothing else. SSH-based transfer gives you host keys, per-account keys and a filesystem you can audit, which is a reasonable trust story for a device that cannot do TLS at all. It is a poor fit for event streams, where "the file is written every hour" means an outage costs you the tail of the current hour.

Keep host verification on. A batch invocation that turns it off to avoid a prompt defeats the only authentication the transport has:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Pin the host key in the account's known_hosts during provisioning, restrict the account to the target directory, and prefer the internal-sftp subsystem with a chroot. Also plan the retransmission story: if a file is re-sent after a partial failure, the collector must be able to tell a duplicate from a new file, usually by name plus checksum rather than by arrival time.

When a local gateway or a tunnel is the honest answer

Some appliances can only speak a format nobody wants to expose. In that case an authorized collector on the appliance's own network receives the native format and forwards it onward over TLS. That is a legitimate design, but be precise about what it buys: encryption starting at the gateway does not retroactively protect the segment between the appliance and the gateway, so that hop still needs its own trust boundary and access control.

A routed site or device tunnel is the heaviest option and the right one when the collector must keep a private address and carry several services, not just logs. It brings address planning, access rules, return paths and the lifecycle of the tunnel endpoint. It also does not improve the inner protocol: UDP syslog inside an IPsec tunnel is still a datagram service with no delivery acknowledgement.

Whatever you pick, keep collector authorization narrower than the transport. A tunnel identity belongs to an endpoint, and it says nothing about which downstream appliance produced a given hostname field in a message.

Write the delivery contract before you ship

Encryption, authentication and retention answer different questions, and a queue is not a retention policy. Before the first log leaves the appliance, decide what an acknowledgement actually means on this collector: received on the wire, accepted for processing, or durably written to storage. Those are three different guarantees and only the last one survives a collector restart.

Then answer the operational questions in writing. Where do unsent events wait, and does that buffer survive a power cut? What happens when it fills, and who gets told? How are retries bounded, and how are duplicates identified? Which field proves the sender's identity, given that a forwarding hop may rewrite the hostname?

Keep the design small enough to explain in one paragraph: the smallest supported transport that carries the required events, plus an explicit statement of the guarantees it does not provide. If the answer needs two hops, say so in the runbook and give each hop an owner.