Troubleshooting SIEM Local Syslog Collection

Team: Huntress Managed Security Information and Event Management (SIEM)
Product: Huntress Platform, Syslog Source Devices
Environment: your endpoints with Huntress, Huntress dashboard, syslog device configuration
Summary: Step-by-step troubleshooting for local syslog collection issues in Huntress Managed SIEM, including agent health, network, and data flow checks.

Overview

Use this article to troubleshoot local syslog collection into Huntress Managed SIEM from a Huntress agent (see compatibility here). Start with Quick Triage to determine whether the issue is agent configuration, listener availability, or network delivery. If syslog traffic is reaching Rio but not appearing in Huntress, continue to the detailed sections below.

Quick Triage

Use this short checklist before following the detailed steps below.

If all four checks pass and syslog data is still not appearing in Huntress SIEM, continue to the detailed steps below.

Confirm Syslog Collection is Enabled for the agent in the Huntress portal.
Confirm Rio is listening on the expected port and protocol (default UDP 514) and that no other process is listening on the same port.
Confirm syslog is reaching Rio by checking for a recent wbs_ file in the OS specific location
Windows: C:\Program Files\Huntress\Rio\tmp
Linux: /usr/share/huntress/rio/tmp

If you see a recent wbs_ file → Focus on ingestion and formatting checks.
If you do not see a wbs_ file →Confirm your software firewall allows inbound for Rio.exe on the active profile, and confirm the source device is sending to the correct internal IP, port (with no conflict), and protocol (default is UDP port 514).

Agent Configuration

First, verify that the Huntress Agent is configured to collect syslog data. From the Host Details page in the Huntress dashboard, confirm that the Syslog Collection field is set to Enabled for the agent. If syslog collection is not enabled, follow the Enable Syslog Collection (Firewall Logs) guide.

Note: After enabling syslog collection, there may be a delay before the portal reflects the change. If you do not see it enabled after 30 minutes, review the steps below.

Rio Listener Status

Next, confirm that the Huntress Rio Agent is listening for syslog data:

Open an elevated command prompt or PowerShell session on the endpoint.
Windows: Run the following command to check if Rio.exe is listening on the expected port and protocol (default is UDP 514): netstat -naob
Linux: You can use this command to see all listeners sudo ss -tunlp Or look at listeners on a single port like this: sudo lsof -i:514

For more readable output in PowerShell (optional), use:
```
(netstat -bano | Out-String) -replace '(?m)^ (TCP|UDP)', '$1' -replace '\r?\n\s+([^[])', "t$1" -replace '\r?\n\s+\[', "t[" | findstr "Rio.exe"
```
Ensure that only the Huntress Agent is listening on the configured port and protocol by running one of the commands below. If another process is using the port, Rio will not be able to bind the port and will not receive syslog data. If you're not using the standard port 514, please change all instances of 514 in the code snippets below to your desired port.

Windows:
```
(netstat -bano | Out-String) -replace '(?m)^ (TCP|UDP)', '$1' -replace '\r?\n\s+([^[])', "t$1" -replace '\r?\n\s+\[', "t[" | findstr ":514"
```
Linux:
```
sudo lsof -i:514
```

Syslog Data Flow

After confirming the agent is listening, verify that syslog data is being received by checking the OS-specific location for a wbs_ file with a modified timestamp within the last few minutes, ideally immediately after sending a test syslog message. The existence of this file is a strong indicator that Rio is receiving syslog traffic from a source device, so it should be checked before attempting a Wireshark packet capture.

Windows: Check C:\Program Files\Huntress\Rio\tmp

Linux: Check /usr/share/huntress/rio/tmp (you may need to be in an elevated terminal by running sudo -s first)

Additional Troubleshooting

Network Category (Defender Firewall)

If you do not see the wbs_ file, check your network profile and firewall settings:

Run Get-NetConnectionProfile in an elevated PowerShell prompt to check the NetworkCategory parameter.
If the network category is set to Public, this can prevent syslog messages from being received. Change it to Private or DomainAuthenticated using:
```
Get-NetConnectionProfile -InterfaceAlias "YOUR_ALIAS_HERE" | Set-NetConnectionProfile -NetworkCategory Private
```
Ensure that your Windows Defender Firewall has an inbound allow rule for Rio.exe and that it applies to the active profile.

Important: Use RFC1918 addresses whenever you’re collecting over an internal network; avoid targeting public IPs unless you have an explicit secure design for that path.

Defender Firewall Log

You can verify Defender Firewall is allowing packets through by turning on Defender's "Log dropped packets" and inspecting those logs.

Open an Admin PowerShell window on the syslog collector endpoint and run this command

Set-NetFirewallProfile -Profile Domain,Private,Public -LogBlocked True

You may need to wait for a syslog packet to be generated in order for that new Windows log to start writing data. The amount of time will vary based on how "noisy" your particular syslog source is. You may be able to speed this process up by triggering a log-able event on your syslog source such as logging into the source's config page, accessing a known-blocked address (from within the LAN to the internet), or accessing a known-allowed address (from LAN to WAN/internet.
Open C:\Windows\System32\LogFiles\Firewall\pfirewall.log
Look for your syslog source's IP and port you setup Huntress SIEM to use.
1. If you don't see the IP you may need to wait longer or manually trigger an event.
2. If you see "DROP" in the 3rd column then your Defender Firewall needs further configuration.
This log file has a maximum size of 32MB so there won't be any impact to drive utilization if you leave the log on. However you can turn it off easily by using the above command, just change the end to "-LogBlocked False"

It's an info-dense log, so using search for your syslog source IP is ideal. In the above example, 10.0.0.1 was the source IP, 10.0.0.5 was the collector IP, and SIEM was setup to use TCP port 514.

Wireshark

Please note that Wireshark captures data BEFORE Defender Firewall filtering, so seeing data in Wireshark is not indicative of a good Defender Firewall configuration. Make sure the firewall rule exactly matches how you've setup Huntress SIEM. We provide PowerShell code you can use in Collecting Syslog Sources.

If Rio is listening but no wbs_ files are being created and you need to confirm whether packets are reaching the host, use Wireshark to confirm packet delivery to the endpoint (does not confirm packet delivery through Defender Firewall):

Install Wireshark on the Rio host and select the appropriate network interface.
Begin capturing data and apply the filter: _ws.col.protocol == "Syslog"
Check that syslog packets are arriving on the expected port (UDP 514 by default). The logs in Wireshark will only display syslog messages, so you can verify the port and protocol being used.
If you do not see any syslog data, double-check that your syslog source device is configured to send to the correct internal IP and port, and that no network or host firewall is blocking the traffic.