Loading...

VONDS ©

Lab 86: Configuring an rsyslog Client for Remote Logging

Back to Lab Index

Configure a Linux host as an rsyslog client that forwards local logs to a central receiver at 192.168.1.10:514 over UDP. Apply a catch-all forwarding rule, restart rsyslog, generate a test message, and verify client-side processing evidence.

logging networking operations

Scenario

Your organization now has a central rsyslog server listening on 192.168.1.10:514. Your task is to configure this host as an rsyslog client so local logs are forwarded to the central receiver.

Operator context

Centralized logging only works if clients forward reliably. Your goal is to implement a simple, catch-all forwarding rule, apply it safely, and generate proof that messages are being handled by the logging pipeline.

Objective

  • Install rsyslog on the client system.
  • Create a forwarding rule that sends all facilities/severities (*.*) to 192.168.1.10 over UDP 514.
  • Restart rsyslog to apply the configuration.
  • Generate a test message with logger.
  • Verify rsyslog processed the event locally via journalctl.

Concepts

  • rsyslog forwarding rules are typically placed in /etc/rsyslog.d/ to keep configuration modular and auditable.
  • Selector syntax *.* matches all facilities and severities (a catch-all rule).
  • A single @ in the action indicates UDP forwarding; a double @@ indicates TCP forwarding.
  • UDP forwarding is common and simple, but unreliable by design; validate basic flow first, then harden as needed.

Walkthrough

Step 1 : Install rsyslog on the client.
Commands 
# Debian/Ubuntu
sudo apt update
sudo apt install -y rsyslog

# RHEL / Fedora / CentOS
sudo dnf install -y rsyslog
# or (older flows)
sudo yum install -y rsyslog

# Arch
sudo pacman -S rsyslog

The client must have rsyslog installed and running to forward system events to a remote receiver. On many distros, rsyslog is already present; installing ensures the unit and config paths exist. 

# Example output (varies by distro):
# rsyslog installed successfully.
Step 2 : Create a remote forwarding rule.
Command 
# Create a drop-in config for remote forwarding:
sudo nano /etc/rsyslog.d/remote.conf
# or
sudo vim /etc/rsyslog.d/remote.conf

Using a dedicated file under /etc/rsyslog.d/ keeps forwarding rules isolated and easier to audit. The selector *.* matches all facilities and severities. 

# /etc/rsyslog.d/remote.conf
*.*    @192.168.1.10:514
Note

The single @ indicates UDP forwarding. A double @@ typically indicates TCP forwarding.

Step 3 : Restart rsyslog to apply the client configuration.
Command 
sudo systemctl restart rsyslog

Restarting applies the new forwarding rule. If rsyslog fails to start, validate your rule syntax and inspect systemctl status rsyslog. 

# Quick verification:
systemctl status rsyslog --no-pager
Step 4 : Generate a test log event.
Command 
logger -t remote-test "exit_0: rsyslog client forward test"

logger writes to the system logging pipeline. Using a unique tag makes it easy to identify the test message locally and correlate with receipt on the central server. 

# Expected outcome:
# Test log message generated with tag 'remote-test'.
Step 5 : Confirm rsyslog processed the event locally.
Command 
sudo journalctl -u rsyslog -n 50 --no-pager | grep -i remote-test || true

This confirms rsyslog is running and processing events on the client. In a real environment, you would also validate receipt on the central server, but client-side evidence is your first checkpoint. 

# Example output (varies):
Feb 11 10:22:41 clienthost remote-test[2457]: exit_0: rsyslog client forward test
Result

This client is now forwarding logs to 192.168.1.10:514 via UDP.

Step 6 : (Optional) Prove network reachability to the receiver.
Command 
# UDP is connectionless, but you can still sanity-check name/IP reachability:
ping -c 2 192.168.1.10

This is a basic connectivity check. True end-to-end validation still requires verifying the message appears on the receiver.

Breakpoints

rsyslog won’t restart

Validate /etc/rsyslog.d/remote.conf syntax and check systemctl status rsyslog plus journalctl -u rsyslog for errors.

No evidence in journalctl

Make sure your logger command ran successfully and that you are grepping for the correct tag. Also try journalctl -n 50 to confirm the event exists at all.

Receiver doesn’t show the message

Confirm the receiver is listening on 514/udp, confirm firewall rules allow UDP 514, and confirm the client is using @192.168.1.10:514 (UDP) rather than @@ (TCP).

Cleanup checklist

If this forwarding rule is lab-only, remove the drop-in file and restart rsyslog.

Commands 
# Remove forwarding rule
sudo rm -f /etc/rsyslog.d/remote.conf

# Apply removal
sudo systemctl restart rsyslog

Reference

  • apt install rsyslog: Install rsyslog on Debian/Ubuntu.
    • -y: assume “yes” to prompts
  • dnf install rsyslog: Install rsyslog on RHEL-family systems.
    • -y: assume “yes” to prompts
  • pacman -S rsyslog: Install rsyslog on Arch.
  • /etc/rsyslog.d/: Drop-in directory for rsyslog rules.
  • *.* @192.168.1.10:514: Catch-all forwarding rule to a UDP receiver.
    • *.*: all facilities and severities
    • @: UDP forwarding (TCP uses @@)
  • systemctl restart rsyslog: Restart rsyslog to apply configuration changes.
  • logger -t remote-test "...": Emit a tagged test message into the logging pipeline.
    • -t: tag the message for easier filtering
  • journalctl -u rsyslog: View rsyslog unit logs via systemd-journald.
    • -n 50: last 50 lines
    • --no-pager: print directly
  • 192.168.1.10:514: Central receiver address/port used in this lab scenario.