When dealing with multi-tiered logging architectures, one persistent pain point emerges: maintaining original host information across forwarding hops. In your specific case with OpenBSD's syslogd forwarding to rsyslog, we're seeing the classic symptom where intermediate systems become the apparent message source.

The traditional BSD syslog protocol (RFC 3164) doesn't explicitly preserve the original hostname during forwarding. When your DMZ syslog receives messages, it typically:

Original: <34>Oct 11 22:14:15 webserver1 sshd[1234]: Failed password
Forwarded: <34>Oct 11 22:14:15 dmz-syslog sshd[1234]: Failed password

For your rsyslog v3 receiver, we can implement message property preservation:

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

# Preserve original hostname in the message
$PreserveFQDN on
$EscapeControlCharactersOnReceive off

On your DMZ syslog (OpenBSD), modify /etc/syslog.conf to include forwarding with original hostnames:

!*
*.* @internal-syslog.example.com;RSYSLOG_ForwardFormat

The RSYSLOG_ForwardFormat is crucial - it tells syslogd to maintain the original message structure.

For more reliable forwarding with metadata preservation, consider using RELP:

# On DMZ syslog (rsyslog as forwarder)
$ModLoad omrelp
*.* :omrelp:internal-syslog.example.com:2514

# On receiver
$ModLoad imrelp
input(type="imrelp" port="2514" ruleset="relp_rules")

Check message preservation with logger:

logger -n dmz-syslog -P 514 -t testapp "Preservation test"
# Then check internal syslog for:
# Original hostname in %hostname% property
# Correct program name in %programname%

For future implementations, consider RFC 5424 (syslog protocol):

# Sample RFC 5424 message
<165>1 2023-10-11T22:14:15.003Z webserver1 sshd 1234 - [meta sequenceId="1"] Failed password

This structured format inherently preserves hostnames and other metadata across hops.

When implementing a multi-hop syslog architecture where DMZ hosts forward logs through an intermediary syslog server (in this case OpenBSD's syslogd v1.17) to a central rsyslog server (v3), a common pain point emerges: the original hostname information gets replaced by the intermediary's hostname. This breaks critical logging metadata needed for security analysis and troubleshooting.

The BSD syslog protocol (RFC 3164) doesn't natively preserve the original hostname during forwarding. When the DMZ syslog server receives messages and forwards them, it acts as a new origin point unless specifically configured otherwise. The protocol was designed in an era when single-hop logging was the norm.

For OpenBSD's syslogd acting as the intermediary:

# /etc/syslog.conf configuration
*.* @internal-syslog.example.com

To preserve hostnames, we need to modify the forwarding behavior:

# Enable RFC 3164 compliance with hostname preservation
syslogd_flags="-a internal-syslog.example.com -v -v"

The receiving rsyslog server needs proper template configuration:

# /etc/rsyslog.conf
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs

For more reliable forwarding with metadata preservation:

# On OpenBSD (requires syslogd-relp package)
syslogd_flags="-r relp://internal-syslog.example.com:20514"

# Rsyslog server configuration
module(load="imrelp")
input(type="imrelp" port="20514")

After configuration, test with logger:

logger -n dmz-syslog.example.com "Test message from original host"

Check the central logs to verify hostname preservation in both the directory structure and log entries.

• Verify network connectivity between all hops
• Check for firewall rules blocking syslog traffic (UDP 514 or custom ports)
• Inspect time synchronization across all hosts
• Confirm DNS resolution works bidirectionally