Troubleshoot Wazuh Syslog Port 514 Ingestion

Wazuh Syslog Port 514 is one of the most common methods organizations use to forward logs from network devices, security appliances, servers, and infrastructure components into Wazuh for centralized monitoring and threat detection.

Many firewalls, routers, switches, and Linux systems rely on syslog as their primary logging mechanism, making Port 514 a critical part of many Wazuh deployments.

Despite its widespread use, syslog ingestion problems are among the most frequently reported issues in production environments.

Logs may be generated correctly on the source device, but network restrictions, protocol mismatches, listener configuration errors, firewall rules, or parsing problems can prevent those events from ever reaching the Wazuh Manager.

When Port 514 ingestion fails, administrators often notice missing security events, incomplete visibility across their infrastructure, delayed incident detection, or dashboards that appear unusually quiet despite active systems generating logs.

Because syslog traffic can use both UDP and TCP transports, troubleshooting often requires examining multiple layers of the logging pipeline.

Common symptoms of Wazuh Syslog Port 514 issues include:

No syslog events appearing in the Wazuh dashboard
Devices reporting successful log transmission while Wazuh receives nothing
Intermittent log delivery
Packet loss during high-volume logging periods
Connection refused errors
Syslog messages arriving but failing to trigger rules or alerts

In this guide, you’ll learn how Wazuh syslog ingestion works, how Port 514 listeners process incoming logs, how to identify the root cause of ingestion failures, and the exact steps required to restore reliable log collection.

If you’re configuring Wazuh as a syslog receiver for the first time, see How to Configure Wazuh as a Centralized Syslog Server.

Understanding How Wazuh Syslog Ingestion Works

Syslog Data Flow in Wazuh

Before troubleshooting Port 514 issues, it’s important to understand the complete path a syslog message follows through the Wazuh architecture.

Log Source

The process begins with a device generating events.

Common sources include:

Firewalls
Routers
Switches
Linux servers
Security appliances
IDS/IPS systems
Application servers

These devices create syslog messages and forward them to a configured destination IP address.

Network Transport (UDP/TCP 514)

After generation, messages travel across the network using either:

UDP Port 514
TCP Port 514

UDP is lightweight and commonly used by networking equipment, while TCP provides delivery guarantees and is preferred for critical logging environments.

According to the official syslog standard defined in RFC 5424, transport selection significantly impacts reliability and message delivery behavior.

RFC 5424 Syslog Protocol: https://datatracker.ietf.org/doc/html/rfc5424

Wazuh Manager Listener

The Wazuh Manager runs a syslog listener configured within ossec.conf.

When configured correctly, the listener:

Opens the specified port
Accepts incoming syslog messages
Writes received data to internal processing queues
Passes messages to the analysis engine

If the listener fails to start or cannot bind to Port 514, no logs will be received regardless of source-side configuration.

Analysis Engine

Once messages arrive, Wazuh decoders attempt to parse the logs.

The analysis engine:

Extracts fields
Matches decoders
Evaluates rules
Generates alerts when conditions are met

Parsing failures can create the appearance of a Port 514 problem even when ingestion is functioning normally.

See Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive for advanced decoder troubleshooting.

Alert Generation

After successful decoding and rule matching, alerts are generated and indexed for visualization in the dashboard.

At this stage, administrators can:

Search events
Build dashboards
Trigger active responses
Create alerts and reports

Any interruption in the earlier stages prevents alerts from reaching this final step.

Default Syslog Ports and Protocols

Wazuh supports several syslog transport methods depending on reliability and security requirements.

UDP 514

UDP remains the most commonly deployed syslog transport.

Advantages include:

Minimal overhead
Low latency
Broad device compatibility
Easy configuration

Disadvantages include:

No delivery confirmation
Possible packet loss
Poor performance during traffic spikes

UDP is generally suitable for network devices generating moderate log volumes.

TCP 514

TCP provides a connection-oriented transport mechanism.

Benefits include:

Reliable delivery
Packet retransmission
Better handling of large log volumes
Reduced message loss

TCP is often preferred for servers and security-critical systems.

TCP with TLS Alternatives

Organizations with strict security requirements often deploy encrypted syslog transport using TLS.

Benefits include:

Encryption in transit
Protection against interception
Strong authentication capabilities
Regulatory compliance support

The official Wazuh documentation recommends encrypted communication when logs traverse untrusted networks.

When to Use Each Protocol

1. Use UDP when:

Devices only support UDP
Logging volumes are moderate
Occasional message loss is acceptable

2. Use TCP when:

Reliability is important
Log volumes are high
Message delivery must be confirmed

3. Use TLS when:

Logs traverse external networks
Compliance requirements exist
Sensitive data may appear in logs

Common Devices That Send Syslog to Wazuh

Firewalls

Firewalls are among the most common syslog sources.

Examples include:

pfSense
OPNsense
Fortinet
Palo Alto Networks
Cisco ASA

These devices typically send:

Traffic logs
Threat events
Authentication records
Configuration changes

See How to Collect Firewall Logs in Wazuh and How to Integrate Wazuh with OPNsense.

Routers and Switches

Network infrastructure commonly forwards:

Interface status changes
Routing updates
Authentication events
Hardware failures

Because these devices often default to UDP 514, network connectivity problems frequently affect log delivery.

Linux Servers

Linux systems typically use:

rsyslog
syslog-ng
systemd-journald forwarding

They can transmit:

Authentication logs
System events
Application logs
Security events

Windows Systems via Syslog Agents

Windows does not natively support syslog transmission.

Instead, organizations commonly deploy:

NXLog
Snare
WinSyslog
Other syslog forwarding agents

These tools convert Windows Event Logs into syslog messages for centralized collection.

See our How to Monitor Windows Event Logs Using Wazuh guide.

Security Appliances

Security products frequently generate large syslog volumes.

Examples include:

IDS/IPS platforms
Web Application Firewalls
VPN concentrators
Endpoint security solutions
Network monitoring platforms

Because these devices can produce thousands of events per second, TCP transport is often recommended.

Common Symptoms of Wazuh Syslog Port 514 Problems

No Events Appearing in the Wazuh Dashboard

This is the most obvious symptom.

Administrators may confirm that devices are sending logs while the dashboard remains empty.

Typical causes include:

Closed firewall ports
Incorrect destination IP addresses
Listener configuration errors
Wazuh Manager service failures
Network routing issues

The problem can occur anywhere between the source device and the Wazuh listener.

Device Reports Successful Syslog Transmission But Wazuh Receives Nothing

Many devices only confirm that messages were handed off locally, not that they were successfully received.

This often happens when:

UDP packets are dropped
Network ACLs block traffic
Port 514 is not listening
Messages are sent to the wrong host

Packet capture analysis frequently reveals the root cause.

Intermittent Log Reception

Logs may appear for several minutes and then stop unexpectedly.

Common causes include:

Network congestion
Listener restarts
Resource exhaustion
Firewall session timeouts
Load spikes on the Wazuh Manager

Intermittent failures are typically more difficult to diagnose because they are not consistently reproducible.

High Packet Loss During Peak Logging Periods

Research from the Internet Engineering Task Force (IETF) has long documented that UDP-based syslog can experience message loss during periods of congestion because it lacks retransmission mechanisms.

Symptoms include:

Missing events
Partial logging records
Reduced visibility during incidents
Large gaps in timelines

Organizations that experience sustained high log volume often migrate from UDP to TCP to improve reliability.

RFC 5426 Syslog over UDP: https://datatracker.ietf.org/doc/html/rfc5426

Syslog Events Arrive But Rules Do Not Trigger

Sometimes ingestion works correctly while detection does not.

Indicators include:

Raw logs visible
No generated alerts
Missing dashboard notifications
Empty security event views

Potential causes include:

Decoder failures
Rule mismatches
Incorrect log formats
Field extraction errors

See How to Test Wazuh Rules and Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive guides.

Connection Refused or Listener Errors

Administrators may encounter errors such as:

connection refused
unable to connect to remote host
cannot bind port 514
address already in use

These errors usually indicate:

Another service already owns Port 514
The Wazuh listener failed to start
Insufficient permissions
Incorrect configuration within ossec.conf

Listener-related errors are often identified quickly through service logs and network socket inspection tools such as ss, netstat, or lsof.

Verify That Wazuh Is Listening on Port 514

One of the first troubleshooting steps for any Wazuh Syslog Port 514 issue is confirming that the Wazuh Manager is actually listening for incoming syslog traffic.

Even if source devices are correctly configured, logs will never arrive if the listener is not active.

Check Active Listening Ports

Start by verifying which services are bound to Port 514.

Using ss

On modern Linux distributions, ss is usually the preferred tool.

Check UDP listeners:

ss -lun | grep 514

Check TCP listeners:

ss -ltn | grep 514

Example output:

udp   UNCONN   0   0   0.0.0.0:514   0.0.0.0:*

tcp   LISTEN   0   128   0.0.0.0:514   0.0.0.0:*

If no results are returned, Wazuh may not be listening on the expected protocol.

Using netstat

Older systems may still rely on netstat.

netstat -tulpn | grep 514

Look for an active process bound to Port 514.

Using lsof

To determine which process owns the port:

lsof -i :514

Example:

wazuh-remoted 12345 root  UDP *:514

This confirms that the Wazuh service is actively listening.

Confirm the Correct Protocol Is Enabled

A common mistake is configuring source devices to use TCP while Wazuh listens only on UDP, or vice versa.

UDP Listener Verification

Check for UDP listeners:

ss -lun | grep 514

Expected output:

udp UNCONN 0 0 *:514 *:*

Most firewalls, routers, and switches use UDP by default.

TCP Listener Verification

Check for TCP listeners:

ss -ltn | grep 514

Expected output:

tcp LISTEN 0 128 *:514 *:*

Many Linux servers and security appliances use TCP to ensure reliable delivery.

Validate Wazuh Syslog Listener Configuration

If no listener exists, review the Wazuh configuration.

Reviewing ossec.conf

The primary configuration file is:

/var/ossec/etc/ossec.conf

Open the file and inspect the remote logging configuration.

sudo nano /var/ossec/etc/ossec.conf

Checking remote and syslog Sections

Look for configuration blocks similar to:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
</remote>

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
</remote>

Ensure the configuration matches the protocol used by the sending device.

Common Configuration Mistakes

Frequent issues include:

Incorrect port numbers
TCP configured on devices while Wazuh listens on UDP
XML syntax errors
Duplicate listener definitions
Missing <connection>syslog</connection> entry
Failure to restart Wazuh after configuration changes

See How to Fix ossec.conf Syntax Errors in Wazuh Agents for XML validation techniques that also apply to manager configurations.

Review Wazuh Syslog Configuration Settings

Even when Port 514 is open, incorrect listener settings can prevent successful log ingestion.

Understanding the Remote Configuration Block

Wazuh uses the <remote> block to define how it accepts remote logs.

This section controls:

Connection type
Port assignment
Transport protocol
Source communication behavior

A single incorrect value can stop syslog collection entirely.

Important Parameters to Validate

Connection Type

Verify that syslog collection is enabled.

Correct value:

<connection>syslog</connection>

Incorrect values such as secure or agent may prevent syslog traffic from being processed correctly.

Port Number

Confirm the configured port matches the sender configuration.

Example:

<port>514</port>

A mismatch between sender and receiver ports is one of the most common causes of missing logs.

Allowed IP Addresses

Some deployments restrict which devices can send logs.

Review any access restrictions to ensure source devices are permitted.

Validate:

Source IP addresses
Subnet definitions
NAT translations
Network segmentation rules

Protocol Settings

Ensure protocol settings match the source device.

Examples:

<protocol>udp</protocol>

<protocol>tcp</protocol>

Protocol mismatches often produce symptoms where devices appear healthy but no logs arrive.

Example Working Syslog Listener Configuration

The following example is commonly used for UDP-based syslog ingestion:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>udp</protocol>
</remote>

Example TCP configuration:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
</remote>

After making changes:

systemctl restart wazuh-manager

Verify that the listener successfully starts before testing again.

Configuration Errors That Commonly Break Ingestion

Watch for:

Missing XML closing tags
Invalid protocol values
Duplicate remote blocks
Typographical errors
Conflicting listener definitions
Incorrect indentation introduced during manual editing
Failure to reload the manager

Review manager logs immediately after configuration changes:

tail -f /var/ossec/logs/ossec.log

Look for startup or listener-related errors.

If service startup fails after changes, see Wazuh Agent Not Connecting to Manager? 12 Proven Fixes for additional connectivity diagnostics.

Check Firewall Rules and Network Connectivity

Once the listener configuration is verified, the next step is ensuring that network traffic can actually reach the Wazuh Manager.

Many Port 514 issues are ultimately caused by firewalls, ACLs, or routing restrictions rather than Wazuh itself.

Verify Local Firewall Rules

Start with the firewall running on the Wazuh server.

firewalld

View current rules:

firewall-cmd --list-all

Allow UDP 514:

firewall-cmd --permanent --add-port=514/udp
firewall-cmd --reload

Allow TCP 514:

firewall-cmd --permanent --add-port=514/tcp
firewall-cmd --reload

iptables

List active rules:

iptables -L -n

Allow UDP syslog:

iptables -A INPUT -p udp --dport 514 -j ACCEPT

Allow TCP syslog:

iptables -A INPUT -p tcp --dport 514 -j ACCEPT

ufw

Check current status:

ufw status

Allow UDP:

ufw allow 514/udp

Allow TCP:

ufw allow 514/tcp

Windows Firewall

For Windows-based collectors:

Open Windows Defender Firewall
Select Inbound Rules
Create a new Port Rule
Allow TCP or UDP 514
Apply to appropriate profiles

Verify the rule is enabled after creation.

Validate Upstream Network Devices

The Wazuh server may be correctly configured while upstream devices silently block traffic.

Cloud Security Groups

For cloud deployments, verify:

AWS Security Groups
Azure Network Security Groups
Google Cloud Firewall Rules

Ensure inbound Port 514 is allowed from the expected source networks.

Network ACLs

Review:

Subnet ACLs
Segmentation policies
Zero-trust controls
Microsegmentation platforms

These controls frequently block syslog traffic unintentionally.

Router Policies

Examine:

Access control lists
Route policies
NAT rules
VPN tunnels

Routing issues often cause one-way connectivity where devices can reach the network but not the logging server.

Test Port 514 Reachability

Connectivity testing helps determine whether traffic can reach the Wazuh Manager.

Using nc

For TCP:

nc -vz wazuh-server-ip 514

Successful output:

Connection to wazuh-server-ip 514 port [tcp/*] succeeded

Using telnet

TCP connectivity can also be tested using:

telnet wazuh-server-ip 514

A successful connection indicates that the port is reachable.

Using nmap

Scan the target host:

nmap -sU -p 514 wazuh-server-ip

UDP scan example.

For TCP:

nmap -sT -p 514 wazuh-server-ip

These tests help identify firewall or routing problems.

Capturing Network Traffic with tcpdump

When connectivity appears correct but logs still do not arrive, packet captures provide definitive evidence.

Confirm Packets Reach the Wazuh Manager

Capture syslog traffic:

tcpdump -i any port 514

Example output:

192.168.1.10.45678 > 192.168.1.20.514: SYSLOG

This confirms that packets are reaching the server.

If no traffic appears:

The sender may not be transmitting
A firewall may be blocking traffic
Routing may be incorrect

Identify Dropped or Malformed Traffic

Packet captures can also reveal:

Invalid source addresses
Truncated messages
Fragmentation problems
Unexpected protocols
Incorrect destination ports

For deeper analysis, save captures for inspection in Wireshark:

tcpdump -i any port 514 -w syslog-capture.pcap

Wireshark Documentation: https://www.wireshark.org/docs/

Packet analysis is often the fastest way to distinguish between a Wazuh configuration issue and a network-layer problem.

If connectivity tests reveal broader communication issues affecting log collection services, see Resolving Filebeat Connection Refused Errors in Wazuh Deployments for additional network troubleshooting techniques that also apply to syslog ingestion.

Troubleshooting Privileged Port Binding Issues

One often-overlooked cause of Wazuh Syslog Port 514 ingestion failures is the inability of the Wazuh Manager to bind to Port 514 itself.

On Linux systems, ports below 1024 are considered privileged ports and require elevated permissions.

If Wazuh cannot successfully bind to Port 514, no syslog messages will be accepted regardless of network connectivity or sender configuration.

Why Port 514 Requires Elevated Privileges

Most Unix-like operating systems restrict access to ports below 1024 to privileged processes.

Because syslog traditionally uses Port 514, any service attempting to listen on that port must:

Run as root
Be granted specific Linux capabilities
Receive traffic via port forwarding

Without sufficient privileges, the listener will fail during startup.

Common Permission Errors

When reviewing logs, you may encounter messages such as:

bind() failed: Permission denied
cannot bind to port 514
address unavailable
unable to create listening socket

Other symptoms include:

Wazuh Manager starts normally but does not listen on Port 514
Port 514 does not appear in ss or netstat
Source devices successfully transmit logs but none arrive

Review the Wazuh Manager logs immediately after service startup to identify permission-related failures.

Running Wazuh with Appropriate Capabilities

Instead of running all Wazuh components as root, Linux capabilities can grant only the permissions necessary to bind privileged ports.

For example:

setcap 'cap_net_bind_service=+ep' /var/ossec/bin/wazuh-remoted

Verify assigned capabilities:

getcap /var/ossec/bin/wazuh-remoted

Expected output:

/var/ossec/bin/wazuh-remoted cap_net_bind_service=ep

This allows the process to listen on Port 514 without granting full root privileges.

Alternative Approaches

In some environments, administrators prefer avoiding privileged ports entirely.

Port Forwarding

Linux can redirect incoming Port 514 traffic to a higher unprivileged port.

Example:

iptables -t nat -A PREROUTING -p udp --dport 514 -j REDIRECT --to-port 1514

Wazuh then listens on Port 1514 while external devices continue sending to Port 514.

NAT Redirection

Cloud firewalls, load balancers, and network appliances can perform the same function.

Benefits include:

Reduced permission requirements
Simpler application configuration
Easier service isolation

This approach is particularly common in large enterprise environments.

Using a Non-Privileged Port

Some organizations simply configure both the sender and receiver to use an alternate port.

Examples include:

1514
2514
5514

Advantages include:

No privileged access requirements
Simpler troubleshooting
Easier container deployments

The primary drawback is that all sending devices must be updated accordingly.

Verify Logs Are Reaching the Wazuh Analysis Engine

Successfully receiving packets on Port 514 does not guarantee that Wazuh is processing them.

The next step is verifying that messages are reaching the analysis engine.

Review Wazuh Manager Logs

The primary troubleshooting file is:

/var/ossec/logs/ossec.log

Monitor it in real time:

tail -f /var/ossec/logs/ossec.log

Look for:

Listener startup messages
Decoder errors
Queue overflows
Permission failures
Parsing warnings

This file often provides the first indication of where the ingestion pipeline is failing.

Check archives.log

The archives.log file contains raw events received by Wazuh before rule processing.

Location:

/var/ossec/logs/archives/archives.log

Search for recent messages:

tail -f /var/ossec/logs/archives/archives.log

If events appear here:

Port 514 ingestion is working
Network connectivity is functioning
Messages are reaching the analysis pipeline

If the file remains empty, the problem likely exists earlier in the ingestion process.

Check alerts.log

The next stage is alert generation.

Location:

/var/ossec/logs/alerts/alerts.log

Monitor recent alerts:

tail -f /var/ossec/logs/alerts/alerts.log

If logs appear in archives.log but not alerts.log, the issue may involve:

Decoder failures
Rule mismatches
Event filtering
Alert threshold settings

Enable Additional Logging for Troubleshooting

For difficult cases, additional debugging can provide more visibility.

Useful steps include:

Increasing Wazuh logging verbosity
Enabling decoder debugging
Capturing packet traces
Running Logtest simulations

Always return logging levels to normal after troubleshooting to avoid excessive disk consumption.

Identifying Parsing and Decoder Issues

A surprisingly common scenario is that logs arrive successfully but cannot be parsed.

Indicators include:

Messages visible in archives.log
No alerts generated
Missing extracted fields
Unclassified events

Use Logtest to verify decoding behavior.

/var/ossec/bin/wazuh-logtest

Paste a sample syslog message and review:

Decoder matches
Extracted fields
Triggered rules

Testing Syslog Ingestion End-to-End

After verifying configuration and connectivity, perform an end-to-end test to confirm the entire ingestion pipeline is functioning correctly.

Generate a Test Syslog Message

A controlled test eliminates uncertainty about the sending device.

The goal is to:

Generate a known event
Send it to Wazuh
Verify receipt
Confirm analysis
Validate dashboard visibility

Send Test Events with logger

On Linux systems, the simplest approach is the logger command.

Example:

logger "Wazuh Syslog Port 514 test event"

For remote syslog targets:

logger -n WAZUH_SERVER_IP -P 514 "Remote syslog test event"

For TCP:

logger -T -n WAZUH_SERVER_IP -P 514 "TCP syslog test"

These commands generate predictable events for troubleshooting.

Validate Event Reception

After sending the test message:

Check packet captures:

tcpdump -i any port 514

Then inspect:

tail -f /var/ossec/logs/archives/archives.log

If the event appears, ingestion is working.

Confirm Alert Generation

Next, verify that the event generates an alert.

Check:

tail -f /var/ossec/logs/alerts/alerts.log

Look for:

Matching decoder
Triggered rule ID
Generated alert level

If alerts do not appear, investigate decoder and rule processing.

Verify Dashboard Visibility

Finally, confirm that the event is searchable within the Wazuh Dashboard.

Search using:

Event message text
Source IP
Hostname
Rule ID
Timestamp

If the alert exists in alerts.log but not in the dashboard, the issue may involve indexing or dashboard synchronization.

See Wazuh Dashboard Not Loading? Complete Troubleshooting GuideandTroubleshooting “No Matching Indices Found” Error in Wazuh Dashboard for dashboard-side troubleshooting.

Troubleshooting Device-Specific Syslog Issues

Different vendors implement syslog differently.

Device-specific configuration mistakes are a common source of ingestion problems.

Cisco Syslog Devices

Common Cisco issues include:

Incorrect logging destination IP
Disabled logging service
Severity filtering
Source-interface misconfiguration

Useful verification commands:

show logging
show running-config | include logging

Confirm:

Destination IP address
Port number
Transport protocol
Logging level

Fortinet Firewalls

FortiGate devices frequently encounter issues related to:

Forward traffic logging disabled
Incorrect syslog format selection
Interface restrictions
TCP/UDP mismatches

Verify:

config log syslogd setting
show

Pay special attention to:

Server IP
Port
Mode
Facility

Palo Alto Networks Devices

Common Palo Alto issues include:

Missing Log Forwarding Profiles
Incorrect Syslog Server Profiles
Filtering policies
Format mismatches

Verify:

Syslog Server Profile
Log Forwarding Profile assignment
Security Policy logging actions

Without a forwarding profile, events may never leave the firewall.

Linux Syslog Senders

Linux systems typically use:

rsyslog
syslog-ng
journald forwarding

Common issues include:

Incorrect destination host
Service failures
Firewall restrictions
Protocol mismatches

Verify service status:

systemctl status rsyslog

Check configuration files:

/etc/rsyslog.conf
/etc/rsyslog.d/

Windows Syslog Forwarders

Because Windows lacks native syslog support, forwarding tools introduce additional troubleshooting variables.

Common products include:

NXLog
Snare
WinSyslog

Verify:

Collector destination
Port number
Protocol
Service status

See our How to Monitor Windows Event Logs Using Wazuh for Windows logging best practices.

Cloud-Based Syslog Sources

Cloud platforms often introduce additional network controls.

Common examples include:

AWS services
Azure resources
Google Cloud infrastructure
SaaS security products

Typical issues involve:

Security group restrictions
Network ACLs
VPC routing
Private endpoint limitations

When troubleshooting cloud syslog ingestion:

Verify outbound connectivity from the source.
Confirm inbound access to the Wazuh server.
Validate routing between networks.
Capture packets on the Wazuh Manager.
Review provider-specific logging documentation.

Resources:

AWS VPC Security Groups Documentation: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html

Microsoft Azure Network Security Groups Documentation: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview

Performance and Scalability Considerations

Once syslog ingestion is functioning correctly, it’s important to ensure that the deployment can handle growing log volumes without introducing packet loss, processing delays, or missed security events.

Many Wazuh Syslog Port 514 issues appear only after environments scale beyond their original design assumptions.

Handling High Syslog Volumes

As organizations add more devices, the number of incoming syslog messages can increase dramatically.

High-volume sources commonly include:

Firewalls
IDS/IPS platforms
Web proxies
Authentication systems
Kubernetes clusters
Cloud infrastructure

Signs that the Wazuh Manager is struggling to keep up include:

Delayed event processing
Missing logs
Increased CPU utilization
Queue overflow warnings
Dashboard indexing delays

According to guidance from the official Wazuh documentation, proper capacity planning is essential when onboarding large log sources or expanding monitoring coverage.

See Why Is Wazuh Using High CPU? Troubleshooting Guide for resource optimization techniques.

UDP Packet Loss Prevention

UDP remains the most widely deployed syslog transport protocol, but it does not guarantee delivery.

When traffic volumes spike, UDP packets may be dropped due to:

Network congestion
Kernel buffer exhaustion
Interface saturation
Packet fragmentation
Queue overflows

To minimize packet loss:

Increase operating system network buffers
Reduce unnecessary logging verbosity
Distribute traffic across multiple collectors
Upgrade network bandwidth where necessary
Monitor packet-drop statistics

One of the original concerns identified in RFC 5426 (Syslog over UDP) is that UDP-based syslog may lose messages during congestion because there is no retransmission mechanism.

RFC 5426 Syslog over UDP: https://datatracker.ietf.org/doc/html/rfc5426

TCP Versus UDP Trade-Offs

Choosing the correct transport protocol has a significant impact on reliability and performance.

Feature	UDP	TCP
Delivery Guarantee	No	Yes
Connection Overhead	Low	Higher
Packet Loss Protection	No	Yes
Resource Usage	Lower	Higher
Scalability	Excellent	Good
Reliability	Moderate	High

UDP is generally preferred when:

Maximum throughput is required
Devices only support UDP
Occasional log loss is acceptable

TCP is generally preferred when:

Security events are critical
Compliance requirements exist
Message delivery must be guaranteed

Many security teams adopt a hybrid approach, using UDP for network infrastructure and TCP for critical systems.

Load Balancing Syslog Traffic

Large environments often exceed the capacity of a single syslog collector.

Common scaling strategies include:

Dedicated syslog relay servers
Multiple Wazuh Managers
Load-balanced TCP collectors
Regional log aggregation points

Benefits include:

Improved resilience
Reduced ingestion bottlenecks
Better fault tolerance
Higher throughput

For enterprise deployments processing millions of events per day, distributing syslog ingestion can significantly improve reliability.

Monitoring Queue Utilization

Even when packets reach the Wazuh server, internal processing queues can become overloaded.

Monitor for indicators such as:

Queue saturation warnings
Delayed event processing
Dropped messages
Increased memory consumption

Review:

tail -f /var/ossec/logs/ossec.log

Watch for messages indicating:

queue full
message dropped
buffer overflow

Queue-related warnings often signal that additional resources or architectural changes are needed.

See Fix Wazuh Logcollector Dropped Messages and How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes for additional performance optimization guidance.

Security Best Practices for Syslog Port 514

Because Port 514 accepts data from external devices, it should be treated as a sensitive service and secured accordingly.

A poorly secured syslog listener can become a source of false data, noise, or operational instability.

Restrict Allowed Senders

Only approved devices should be permitted to send syslog traffic.

Implement controls such as:

Firewall allowlists
Network ACLs
Security group restrictions
Dedicated logging VLANs

Limit access to:

Firewalls
Servers
Security appliances
Authorized infrastructure components

Blocking unauthorized senders reduces attack surface and minimizes log pollution.

Use Network Segmentation

Security experts consistently recommend separating log traffic from general user traffic.

Benefits include:

Reduced exposure
Easier troubleshooting
Improved performance
Better compliance alignment

Examples include:

Dedicated management networks
Logging VLANs
Security monitoring segments
Isolated collector subnets

Network segmentation also helps contain the impact of compromised devices.

Implement Encrypted Syslog When Possible

Traditional syslog over UDP and TCP transmits data in plaintext.

This creates risks such as:

Packet interception
Credential exposure
Log tampering
Data leakage

When supported by devices, consider:

Syslog over TLS
VPN tunnels
Encrypted log relays

The Internet Engineering Task Force (IETF) recommends transport-layer encryption for environments handling sensitive information.

RFC 5425 Transport Layer Security for Syslog: https://datatracker.ietf.org/doc/html/rfc5425

Monitor for Unauthorized Log Sources

Unexpected log sources can indicate:

Misconfigurations
Rogue devices
Network scanning activity
Potential security incidents

Regularly review:

Source IP addresses
Hostnames
Device inventories
Syslog volume baselines

Investigate any source that cannot be tied to an approved asset.

Regularly Audit Listener Configurations

Configuration drift is a common cause of future ingestion problems.

Periodically review:

Port assignments
Protocol settings
Firewall rules
Allowed sender lists
Listener status

Create documented change-control procedures whenever syslog configurations are modified.

See How to Configure Wazuh Log Retention for additional log management and operational governance best practices.

Monitoring and Validation After the Fix

Successfully restoring syslog ingestion is only the first step.

Continuous monitoring helps ensure that the issue does not return unexpectedly.

Verify Continuous Log Ingestion

After implementing fixes:

Monitor log flow for several days
Verify consistent event arrival
Compare expected versus actual log volumes
Check multiple source devices

Do not assume the problem is resolved based solely on a successful test event.

A healthy deployment should demonstrate sustained ingestion under normal operating conditions.

Confirm Alert Generation

Receiving syslog messages is not enough if alerts are not being generated.

Validate:

Decoder matching
Rule execution
Alert creation
Dashboard indexing

Regularly review:

/var/ossec/logs/alerts/alerts.log

Spot-check events from multiple device types to ensure the entire detection pipeline is functioning correctly.

Monitor Wazuh Manager Health

A healthy listener depends on a healthy Wazuh Manager.

Track:

CPU utilization
Memory consumption
Service uptime
Queue health
Disk usage

Useful commands include:

systemctl status wazuh-manager

and

journalctl -u wazuh-manager

Unexpected service restarts can cause intermittent syslog ingestion failures.

See Troubleshooting Wazuh Manager Core Dumps and Why Is Wazuh Using High CPU? Troubleshooting Guide for manager stability troubleshooting.

Track Syslog Volume Trends

Monitoring volume trends helps detect problems before they become outages.

Watch for:

Sudden traffic drops
Unexpected spikes
Missing device activity
Seasonal traffic changes

Establish baselines for:

Events per hour
Events per day
Device-specific logging rates

A sudden decrease often indicates a collection problem, while an unexpected increase may signal a security incident or configuration error.

Create Automated Ingestion Tests

Many experienced security teams implement automated validation checks to detect ingestion failures quickly.

Examples include:

Scheduled test syslog messages
Synthetic logging events
Alert validation workflows
Dashboard availability checks
Queue health monitoring

A simple scheduled Linux test might use:

logger "Automated Wazuh syslog ingestion validation"

Combined with alerting rules, this approach can detect ingestion failures before they affect security visibility.

Organizations operating mature security monitoring programs often treat log-ingestion validation as a critical operational control because missing logs can create blind spots that remain unnoticed for extended periods.

Troubleshooting Checklist

When troubleshooting Wazuh Syslog Port 514 ingestion issues, it’s easy to jump between multiple configuration files, devices, and network components.

The following checklist provides a structured workflow that helps isolate the root cause quickly.

Confirm Wazuh Is Listening on Port 514

Verify that Wazuh has successfully bound to the expected port and protocol.

Check:

ss -lun | grep 514

ss -ltn | grep 514

Confirm:

Port 514 is open
The correct protocol (UDP or TCP) is enabled
Wazuh Manager started successfully
No competing process is using the port

Verify Firewall Rules

Review all firewall layers between the sender and Wazuh Manager.

Validate:

Local host firewall rules
Cloud security groups
Network ACLs
Router filtering policies
VPN firewall rules

Ensure Port 514 traffic is permitted in both the expected direction and protocol.

Validate Network Connectivity

Confirm that traffic can reach the Wazuh server.

Useful tests include:

nc -vz SERVER_IP 514

telnet SERVER_IP 514

nmap -sU -p 514 SERVER_IP

Packet captures should confirm whether syslog traffic reaches the destination.

Check Syslog Sender Configuration

Review the source device configuration.

Verify:

Destination IP address
Destination port
Protocol selection
Logging level
Enabled log categories

Many ingestion failures originate from sender-side misconfigurations rather than Wazuh itself.

Review Wazuh Logs

Inspect:

/var/ossec/logs/ossec.log

Look for:

Listener startup failures
Permission errors
Decoder warnings
Queue issues
Service restarts

Manager logs frequently reveal the exact source of the problem.

Test with a Manual Syslog Message

Generate a controlled test event.

Example:

logger -n WAZUH_SERVER_IP -P 514 "Syslog ingestion validation test"

This removes uncertainty about the behavior of production devices.

Confirm Decoder and Rule Processing

If logs arrive but alerts do not appear:

Review archives.log
Test messages using Logtest
Validate decoder matches
Verify rule execution

Validate Dashboard Visibility

Finally, verify that alerts are indexed and searchable.

Check:

Dashboard event search
Index health
Alert timestamps
Rule IDs

If alerts exist in alerts.log but not in the dashboard, the issue may be unrelated to syslog ingestion.

Frequently Asked Questions (FAQ)

Question: What is Syslog Port 514 used for in Wazuh?

Port 514 is the traditional syslog port used by network devices, firewalls, servers, and security appliances to send log messages to the Wazuh Manager.

Wazuh receives these messages, analyzes them through decoders and rules, and generates alerts for security monitoring.

Question: Does Wazuh support both UDP and TCP on Port 514?

Yes. Wazuh can receive syslog traffic over both UDP and TCP.

UDP is commonly used by:

Routers
Switches
Firewalls

TCP is often preferred for:

Linux servers
Security appliances
High-volume logging environments

The protocol configured on the sender must match the protocol configured in Wazuh.

Question: Why is Wazuh not receiving syslog messages on Port 514?

The most common causes include:

Port 514 is not listening
Firewall rules are blocking traffic
Incorrect destination IP addresses
Protocol mismatches
Network routing problems
Sender configuration errors
Permission issues preventing Wazuh from binding to Port 514

Following the troubleshooting workflow in this guide will typically identify the root cause.

Question: How do I verify that Port 514 is open?

Use tools such as:

ss -lun | grep 514

ss -ltn | grep 514

netstat -tulpn | grep 514

You can also test connectivity remotely using nc, telnet, or nmap.

Question: Can firewall rules block syslog ingestion?

Yes.

This is one of the most common causes of syslog failures.

Potential blocking points include:

Linux firewalls
Windows Firewall
Cloud security groups
Network ACLs
Router policies
VPN filtering rules

Always verify every layer between the sender and the Wazuh Manager.

Question: Why do packets reach the server but no alerts appear?

If packets arrive successfully but alerts are missing, the issue usually exists after ingestion.

Common causes include:

Decoder failures
Rule mismatches
Parsing errors
Alert suppression
Indexing problems

Check:

archives.log
alerts.log
wazuh-logtest output

See Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive.

Is UDP or TCP better for Wazuh syslog ingestion?

Neither protocol is universally better.

UDP provides:

Lower overhead
Better scalability
Simpler device compatibility

TCP provides:

Reliable delivery
Retransmission support
Reduced packet loss

Most security-focused deployments prefer TCP when devices support it.

Can I use a port other than 514 for syslog?

Yes.

Wazuh can listen on alternative ports such as:

1514
2514
5514

This is often useful when:

Avoiding privileged ports
Running inside containers
Implementing custom logging architectures

Both the sender and receiver must use the same port.

How do I test syslog delivery to Wazuh?

The simplest method is sending a test message with the Linux logger command:

logger -n WAZUH_SERVER_IP -P 514 "Wazuh syslog test"

Then verify:

Packet capture visibility
archives.log entries
alerts.log entries
Dashboard indexing

This validates the entire ingestion pipeline.

How can I secure Syslog Port 514 in production?

Recommended security practices include:

Restrict allowed source IP addresses
Segment logging networks
Use encrypted syslog when possible
Monitor unauthorized senders
Regularly audit listener configurations
Review firewall rules periodically

Organizations subject to compliance requirements should strongly consider encrypted syslog transport rather than plaintext UDP.

Conclusion

Troubleshooting Wazuh Syslog Port 514 ingestion issues requires a methodical approach that examines every stage of the logging pipeline, from the source device all the way to alert generation and dashboard visibility.

In most environments, the root cause typically falls into one of a few categories:

Wazuh is not listening on Port 514
Firewall or network devices are blocking traffic
Sender configurations are incorrect
Privileged port binding issues prevent listener startup
Decoder or rule processing failures stop alert generation
Dashboard or indexing problems hide successfully ingested events

The most effective troubleshooting strategy is to validate each layer independently:

Confirm the listener is active.
Verify network connectivity.
Capture and inspect incoming traffic.
Review Wazuh processing logs.
Validate decoder and rule execution.
Confirm dashboard visibility.

By systematically testing each stage, administrators can quickly isolate the failure point and restore reliable log collection.

Going forward, organizations should continuously monitor syslog ingestion health, establish automated validation tests, audit listener configurations regularly, and implement secure transport mechanisms where possible.

These practices help ensure that critical security events are never lost and that Wazuh continues to provide accurate, real-time visibility across the environment.

Related:

Resources:

Wazuh Documentation: https://documentation.wazuh.com/
RFC 5424 Syslog Protocol: https://datatracker.ietf.org/doc/html/rfc5424
RFC 5425 Syslog over TLS: https://datatracker.ietf.org/doc/html/rfc5425