How to check in one minute
After a restart, look at what wazuh-remoted said and what it is actually listening on:
grep wazuh-remoted /var/ossec/logs/ossec.log | grep -E 'ERROR|CRITICAL|WARNING' | tail -n 20
ss -lntup | grep -E ':(514|1514)\b'(1235): Invalid value for element 'port' means remoted did not start at all. (9002): Only secure connection supports TCP and UDP at the same time means one protocol was dropped. (1206): Unable to Bind port means one listener did not start while the rest did. Then send a test line to each port and protocol you expect, with <logall>yes</logall> on for a few minutes, and look for it in /var/ossec/logs/archives/archives.log.
What we measured
We added each configuration below to a Wazuh 4.14.7 manager that also had the default agent block (<connection>secure</connection>, port 1514, TCP), started remoted, listed the listening sockets, and sent one syslog line to each port and protocol from the manager itself.
| Configuration | remoted | Listening | Syslog line arrived |
|---|---|---|---|
one block, <port>514,1514</port>, <protocol>tcp,udp</protocol> | does not start: ERROR (1235): Invalid value for element 'port': 514,1514, CRITICAL (1202) | nothing, not even the agent port | none |
one block, <port>514</port>, <protocol>tcp,udp</protocol> | starts with WARNING (9002): Only secure connection supports TCP and UDP at the same time. Default value (TCP) will be used. | TCP 514 (+ agent TCP 1514) | TCP only; UDP senders are not heard |
| four blocks: 514/tcp, 514/udp, 1514/tcp, 1514/udp | starts, but logs CRITICAL: (1206): Unable to Bind port '1514' for the syslog TCP listener; the other listeners and the agent port keep running | TCP 514, UDP 514, UDP 1514, and TCP 1514 (the agent listener only) | TCP 514 ✓ · UDP 514 ✓ · UDP 1514 ✓ · TCP 1514 ✗ |
The syslog TCP 1514 listener fails to bind (1206), but remoted does not stop: agents stay connected and the other syslog ports work, so the CRITICAL line is easy to miss. A device that keeps sending syslog over TCP to 1514 reaches the agent listener instead. The only trace of each line is WARNING: Too big message size from socket, since the agent protocol reads a syslog line as a framed message.
local_ip is not allowed-ips
<local_ip> is the address remoted listens on; <allowed-ips> is which senders it accepts. With <local_ip>127.0.0.1</local_ip> the UDP 514 socket was bound to 127.0.0.1, while a block without it was bound to 0.0.0.0. Replacing one with the other changes what the block does.
Fix
One block per port and protocol, and keep syslog off TCP 1514 while agents use it. For example, syslog on 514 over both protocols, plus a second TCP port:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.0.0.0/8</allowed-ips>
<local_ip>10.0.0.161</local_ip>
</remote>
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>tcp</protocol>
<allowed-ips>10.0.0.0/8</allowed-ips>
<local_ip>10.0.0.161</local_ip>
</remote>
<remote>
<connection>syslog</connection>
<port>10514</port>
<protocol>tcp</protocol>
<allowed-ips>10.0.0.0/8</allowed-ips>
<local_ip>10.0.0.161</local_ip>
</remote>Repeat <allowed-ips> for each source range. If a device can only send to 1514, use UDP 1514, which did arrive, or move the agents to another port first.
Limits of what we measured
Measured on a Wazuh 4.14.7 manager container, sending from the manager to itself over 127.0.0.1, one line per port and protocol. We did not test syslog over TLS, a cluster, IPv6, or other versions. The 10514 example port was not part of the measurement; any free port works the same way as 514.