Syslog Receivers

The syslog receivers feature enables the rXg to act as a centralized syslog server, receiving and storing log messages from network devices, servers, and other infrastructure equipment using the standard syslog protocol (RFC 3164).

Overview

Syslog is a standard protocol for message logging that allows separation of the software that generates messages, the system that stores them, and the software that reports and analyzes them. By configuring the rXg as a syslog receiver, operators can:

• Centralize log collection from multiple network devices
• Monitor and troubleshoot network infrastructure from a single location
• Archive log data for compliance and auditing purposes
• Search and filter log messages using the standard log viewer
• Correlate events across different systems and devices

The rXg supports both UDP (default) and TCP syslog protocols and can listen on any available port, with port 514 being the standard syslog port.

Configuring Syslog Receivers

To create a new syslog receiver:

1. Navigate to Services > Servers in the rXg console
2. Scroll down to the Syslog Receivers section
3. Click Create New to add a receiver
4. Configure the following settings:

Configuration Options

Active (checkbox) : Enable or disable the syslog receiver. When active, the receiver will listen for and store incoming syslog messages, and the log file will appear in Archives > Log Files.

Name (required) : A descriptive name for the syslog receiver (e.g., "Cisco Switches", "Linux Servers", "Firewall Logs"). This name will appear in the log file list as "Syslog Receiver: [Name].log".

Protocol (required, default: UDP) : The transport protocol to use: - UDP: Connectionless protocol, faster but no delivery guarantee - TCP: Connection-oriented protocol, reliable but slightly slower

Port (required, default: 514) : The UDP or TCP port on which the receiver will listen for incoming syslog messages. Standard syslog uses port 514, but any port between 1-65535 can be used.

Visibility (required) : Controls which network interfaces can send syslog messages to this receiver: - internal: Only accept logs from internal network interfaces - wan: Only accept logs from WAN interfaces - internal,wan: Accept logs from both internal and WAN interfaces

WAN Targets (optional) : Associate WAN targets to allow specific external sources to send logs to this receiver. This integrates with the rXg firewall system to automatically configure access rules.

Note (optional) : Administrative notes about this receiver's purpose or configuration.

Multiple Active Receivers

Unlike many rXg features that allow only one active instance, multiple syslog receivers can be active simultaneously. This design allows operators to:

• Listen on different ports for different device types
• Separate UDP and TCP syslog streams
• Configure different visibility settings for internal vs. external devices

For example, you might configure: - Receiver 1: "Network Devices" - Port 514/UDP, internal visibility for switches and routers - Receiver 2: "Servers" - Port 6514/TCP, internal,wan visibility for servers requiring reliable delivery - Receiver 3: "IoT Devices" - Port 515/UDP, internal visibility for IoT devices on a separate network

Viewing Syslog Logs

Once a syslog receiver is active and collecting logs, you can view them in the standard log viewer:

1. Navigate to Archives > Log Files in the rXg console
2. In the log source dropdown menu, locate Syslog Receiver: [Receiver Name].log
3. Click on the log name to view its contents

The log viewer provides the standard features available for all rXg log files:

• Pagination: Browse through pages of log entries
• Search/Filter: Enter search terms to filter log entries
• Context Lines: Show lines before/after matches
• Archived Files: View rotated log files by clicking different file numbers
• Dashboard Integration: Add frequently-viewed logs to the Archives dashboard

Log File Format

Each active syslog receiver writes logs to /var/log/syslog-receiver-[ID].log on the rXg filesystem. These files are rotated periodically to manage disk space and are viewable through the web interface.

Log entries are stored in their original format as received from the sending device, preserving the complete syslog message including priority, timestamp, hostname, tag, and message content.

Syslog Message Format

The rXg parses incoming syslog messages according to RFC 3164 format:

<PRI>TIMESTAMP HOSTNAME TAG: MESSAGE

Example: <134>Oct 10 13:03:44 firewall kernel: [UFW BLOCK] IN=eth0 OUT=

Components: - PRI: Priority value encoding facility and severity - Priority = (Facility 8) + Severity - Example: 134 = (16 8) + 6 = local0.info - TIMESTAMP: Three-letter month, day, time (MMM DD HH:MM:SS) - HOSTNAME: Source hostname or IP address - TAG: Application name, optionally with process ID in brackets - MESSAGE: The actual log message content

Facility Codes

Severity Levels

Configuring Network Devices

To send logs to the rXg syslog receiver, configure your network devices to use the rXg as a syslog server. Replace 192.168.1.1 with the IP address of your rXg interface that the devices can reach, and ensure the port matches your configured receiver port.

Cisco IOS

logging host 192.168.1.1
logging trap informational

Linux (rsyslog)

# /etc/rsyslog.conf
*.* @192.168.1.1:514    # UDP
*.* @@192.168.1.1:514   # TCP

Juniper JunOS

set system syslog host 192.168.1.1 any info

pfSense / OPNsense

Navigate to Status > System Logs > Settings - Remote Logging Options: Check "Enable Remote Logging" - Remote Log Servers: Enter rXg IP address - Remote Syslog Contents: Select facilities to log

Windows Event Log Forwarding

Use third-party tools like nxlog or Snare to forward Windows Event Logs as syslog messages to the rXg.

MikroTik RouterOS

/system logging action
set remote=192.168.1.1 remote-port=514

/system logging
add action=remote topics=info

Firewall and WAN Target Integration

Syslog receivers integrate with the rXg firewall system to automatically open the necessary ports:

• When a receiver is created, modified, or its active state changes, firewall rules are updated automatically
• The visibility setting controls which interfaces accept syslog traffic
• WAN targets can be associated with receivers to allow specific external sources
• Changes to syslog receivers trigger a firewall configuration update

This integration ensures that network devices can reach the syslog receiver without manual firewall rule configuration.

Use Cases

Network Device Monitoring

Configure all switches, routers, firewalls, and wireless controllers to send logs to a central syslog receiver. Use the search feature to quickly identify critical errors, link state changes, or security events.

Compliance and Auditing

Centralize authentication logs from servers and network devices to meet compliance requirements for log retention and monitoring. Syslog logs are retained according to configured log rotation policies.

Troubleshooting

When investigating network issues, correlate timestamps across multiple devices by viewing all logs in a central location. Search for specific MAC addresses, IP addresses, or error messages across all collected logs.

Infrastructure Monitoring

Set up separate receivers for different types of infrastructure: - "Network Devices" - Port 514/UDP, internal visibility for switches, routers, and APs - "Security Devices" - Port 515/UDP, internal visibility for firewalls and IDS/IPS - "Servers" - Port 6514/TCP, internal,wan visibility for critical servers requiring reliable delivery

This separation makes it easier to locate and analyze logs by infrastructure category.

Limitations and Considerations

• UDP vs TCP: UDP is faster but messages may be lost under heavy load or network congestion. Use TCP for critical logs where reliability is essential.
• Log Volume: High-volume logging can consume disk space. Log files are rotated automatically, but monitor disk usage if receiving logs from many devices.
• Time Synchronization: Ensure all devices sending logs use NTP to synchronize their clocks. RFC 3164 syslog timestamps don't include timezone or year information, so accurate clocks are critical for log correlation.
• Security: Use the visibility setting to restrict syslog access to appropriate networks, or associate specific WAN targets for external sources.
• Parsing: The rXg parses RFC 3164 syslog format. Some devices may send non-standard formats that may not parse cleanly, but the complete raw message is always stored.

Troubleshooting

Logs Not Appearing

1. Verify the receiver is marked as Active
2. Check that the sending device can reach the rXg IP address and port
3. Verify the visibility setting allows traffic from the sending device's network
4. Test connectivity from sending device:
   • Linux: logger -n <rxg-ip> -P <port> "Test message"
   • Test with netcat: echo "<134>Test message" | nc -u <rxg-ip> <port>
5. Check the raw log file on the rXg: /var/log/syslog-receiver-[ID].log
6. Check /var/log/rxgd.log for errors related to syslog reception

Log File Not Listed in Archives > Log Files

1. Verify the receiver is marked as Active - only active receivers appear in the log list
2. Try refreshing the page
3. Check that the receiver was saved successfully in Services > Servers

Incorrect Timestamps

1. Ensure sending devices have accurate clocks (use NTP)
2. Verify timezone settings on sending devices match expectations
3. Note that RFC 3164 syslog timestamps lack year information - the rXg infers the year based on the current date
4. Messages from December viewed in January may show the previous year

Performance Issues

1. Consider reducing log volume at the source (filter less critical severities)
2. Use UDP instead of TCP if message loss is acceptable (reduces overhead)
3. Monitor disk space usage if collecting high-volume logs
4. Spread load across multiple receivers if necessary

Messages Appear Garbled or Incomplete

1. Some devices send non-RFC-compliant syslog formats
2. Check the raw log file at /var/log/syslog-receiver-[ID].log to see the original format
3. The complete raw message is always stored even if parsing fails
4. Contact RG Nets support if consistent parsing issues occur with standard devices

See Also

• System Logs - Viewing and filtering rXg system logs
• WAN Targets - Managing external network access