ossec.conf configuration to support secure agent and syslog on a single server
Ronald Simmons
<!-- Secure connection for Wazuh agents -->
<remote>
<connection>secure</connection>
<port>1514</port>
<protocol>tcp</protocol>
<allowed-ips>192.168.21.0/24</allowed-ips>
</remote>
<!-- Syslog connection for external devices -->
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>tcp</protocol>
<allowed-ips>192.168.2.20/24</allowed-ips>
<local_ip>192.168.21.10</local_ip>
</remote>
When I make this change, I get token errors and the agent information won't load.
Juan Sebastián Saldarriaga Arango
Good question. Let me help you understand what's happening.
The two <remote> blocks aren't the problemHaving two <remote> blocks (one secure and one syslog) in the same ossec.conf is a supported and valid configuration in Wazuh. That alone shouldn't break anything. Different subnets aren't the issue either, as long as you have network connectivity between them.
What's likely causing the errorLooking at your config, there's a suspicious detail in the allowed-ips of the syslog block:
This is inconsistent. You're saying "allow hosts in 192.168.2.20 with /24 mask," which Wazuh interprets as the 192.168.2.0/24 network. But then you declare:
Meaning the Wazuh server listens for syslog on IP 192.168.21.10 (subnet .21.0/24), but only accepts packets from subnet .2.0/24. If your syslog devices are actually in 192.168.2.0/24, then routing between subnets needs to be working so packets can reach 192.168.21.10.
About the "token errors" and agent info not loadingThis sounds more like a symptom of the Wazuh API / dashboard, not the manager itself. When Wazuh can't start properly due to an error in ossec.conf, the dashboard loses connection to the manager and shows "token" or "401" errors because the API isn't responding.
I'd recommend checking the following in order:
1. Verify the manager started correctly:
2. Look for specific errors in the logs:
If there's an XML parsing error or a port bind error, it will show up there. Common errors in this scenario:
- Port 514 already in use (rsyslog usually listens there by default on Ubuntu/RHEL).
- local_ip not assigned to any interface on the server.
- Conflict between the two blocks if they use the same port/protocol.
3. Check that port 514 is free before Wazuh tries to bind it:
If rsyslog or syslog-ng is listening on 514, you'll need to stop them or move them to another port, because Wazuh won't be able to bind.
4. Verify that 192.168.21.10 is actually an IP on the manager:
Changes:
- allowed-ips for syslog now reads 192.168.2.0/24 (the network, not a specific host with a network mask, which is ambiguous).
- I switched syslog to UDP since most network devices (firewalls, switches, etc.) send syslog over UDP by default. If your specific devices send over TCP, leave it as TCP.
is this because the syslog servers are in a different subnet from the servers and wazuh server?
Not directly. Different subnets work fine as long as routing is configured and firewalls allow traffic to port 514. The most likely causes are one of these three:
- Port 514 conflict with an OS-level syslog service (most common).
- Misconfigured local_ip (doesn't exist on any manager interface).
- The manager isn't starting due to the XML/config error, which is why the dashboard loses its token and can't display agents.
Start by checking /var/ossec/logs/ossec.log right after restarting the manager — the exact clue will be there.