Load Balancers and Network Devices

Although load balancers are typically associated with web traffic, they are increasingly deployed in front of syslog infrastructure to distribute traffic across multiple collectors, provide high availability, or terminate TLS connections.

When configured incorrectly, these devices can inadvertently modify or corrupt RFC5424 messages, including removing the mandatory PRI header.

If your Wazuh manager forwards logs through one or more intermediate network devices before they reach the destination, each hop should be considered a potential source of message modification.

TCP Stream Rewriting

Some load balancers and proxies inspect or reconstruct TCP streams before forwarding them to backend servers.

Depending on the platform and configuration, this process may:

• Reassemble fragmented syslog messages
• Convert between framing methods
• Rewrite message boundaries
• Strip leading characters that appear invalid
• Rebuild outbound payloads

If the parser does not fully understand RFC5424, the leading <PRI> value may be omitted during reconstruction.

This issue is more common when using application-layer (Layer 7) proxies rather than simple TCP pass-through configurations.

When troubleshooting, capture packets:

• Leaving the Wazuh manager
• Entering the load balancer
• Leaving the load balancer
• Arriving at the syslog collector

Comparing these captures helps identify exactly where the PRI header disappears.

Message Normalization

Many enterprise networking appliances include log normalization or message transformation features.

Examples include:

• Security gateways
• Log aggregation appliances
• Managed detection platforms
• Cloud-based logging services

These devices may:

• Remove unsupported fields
• Convert RFC5424 to RFC3164
• Rewrite timestamps
• Reformat structured data
• Replace message headers

While normalization can improve compatibility with legacy systems, improperly configured normalization rules may discard the PRI field entirely.

Always review any message transformation or normalization policies enabled on intermediary devices.

Header Truncation

Some appliances enforce maximum header lengths or apply filtering rules that inadvertently affect the beginning of a syslog message.

Potential causes include:

• Custom parsing rules
• Buffer limitations
• Incorrect framing detection
• Proxy software bugs
• Legacy compatibility settings

Since the PRI header appears at the very beginning of every RFC5424 message, truncation of even a few bytes can immediately invalidate the entire syslog frame.

If packet captures show that messages arrive without their opening angle bracket (<), header truncation should be investigated.

Expert insight: Engineers maintaining syslog-ng recommend validating the raw bytes on the wire during interoperability troubleshooting because intermediary devices may alter messages even when both the sender and receiver are configured correctly.

Custom Scripts That Remove PRI Values

Many organizations extend Wazuh by inserting custom scripts between the manager and downstream logging platforms.

While these scripts often enrich or transform events, they can also unintentionally remove the PRI header when rebuilding syslog messages.

Whenever custom automation is part of the forwarding pipeline, review the code carefully before assuming the issue lies with Wazuh.

Python Forwarding Scripts

Python is commonly used to:

• Receive Wazuh alerts
• Modify JSON payloads
• Enrich events
• Forward alerts to external SIEMs
• Convert formats

A common mistake occurs when developers manually construct a new RFC5424 message but forget to prepend the original priority field.

For example, a script may correctly rebuild:

• Timestamp
• Hostname
• Application name
• Message body

while accidentally omitting the required <PRI> value.

When reviewing Python forwarding code, verify that the complete RFC5424 header, not just the message body, is preserved.

Bash Wrappers

Simple Bash scripts are frequently used to:

• Pipe logs between applications
• Execute preprocessing commands
• Call external APIs
• Forward messages using tools such as logger, netcat, or socat

Commands that manipulate strings with utilities like sed, awk, cut, or grep can unintentionally remove the leading <PRI> field.

Examples include:

• Removing text before the first space
• Stripping angle brackets
• Extracting only the message body
• Trimming the beginning of each line

Even a seemingly harmless text-processing command can produce invalid RFC5424 output if the priority header is discarded.

Log Processing Pipelines

Many organizations build custom pipelines that perform multiple stages of log processing before forwarding events.

Typical stages include:

1. Receive Wazuh alert
2. Parse JSON
3. Enrich metadata
4. Convert formats
5. Forward to SIEM

Each transformation increases the risk of accidentally rebuilding the message incorrectly.

When debugging these pipelines:

• Compare the original and final messages.
• Preserve the complete RFC5424 header whenever possible.
• Avoid reconstructing syslog messages unless necessary.
• Add automated tests that validate RFC5424 compliance after code changes.

Maintaining the original message structure is generally more reliable than generating a new syslog frame from scratch.

Third-Party Integrations

Wazuh deployments often integrate with external data processing platforms that enrich, transform, or distribute logs before they reach the final destination.

Although these integrations provide significant flexibility, they also introduce additional opportunities for RFC5424 headers to be modified or removed.

When troubleshooting stripped PRI headers, inspect every integration in the forwarding path, not just Wazuh itself.

Elasticsearch Pipelines

Organizations sometimes send Wazuh events through Elasticsearch ingest pipelines before indexing or forwarding them elsewhere.

These pipelines can perform tasks such as:

• Field enrichment
• Timestamp normalization
• Data transformation
• Message reconstruction
• Metadata extraction

If a pipeline rebuilds the syslog message instead of preserving the original payload, the PRI header may be omitted.

Review ingest processors carefully to ensure they modify only the intended fields rather than replacing the entire syslog frame.

Kafka Connectors

Apache Kafka is commonly used to transport high-volume security logs between producers and consumers.

Kafka connectors may:

• Convert data formats
• Serialize events
• Parse message bodies
• Generate new output records

If the connector extracts only the message content while ignoring the original RFC5424 envelope, downstream consumers may receive logs without their PRI headers.

When using Kafka in a Wazuh forwarding architecture:

• Verify the original payload entering Kafka.
• Compare it with the payload leaving Kafka.
• Confirm that connectors preserve the complete syslog message instead of only selected fields.

Cloud Log Forwarders

Cloud-native logging services frequently act as intermediaries between on-premises Wazuh deployments and cloud-hosted SIEM platforms.

Examples include managed log forwarding services that:

• Collect syslog traffic
• Normalize records
• Enrich metadata
• Convert formats
• Forward events to analytics platforms

Some services automatically translate RFC5424 messages into proprietary formats before exporting them again. During this conversion, the original PRI header may not be retained unless explicitly supported by the forwarding configuration.

If you’re forwarding Wazuh alerts through a cloud logging platform, validate the message at each stage of the pipeline to determine whether the service is preserving RFC5424 compliance.

Related Guides:

• How to Configure Wazuh as a Centralized Syslog Server
• Fix Wazuh GCP Pub/Sub Ingestion
• How to Monitor AWS CloudTrail Logs Using Wazuh

How to Diagnose the Problem

Diagnosing stripped RFC5424 priority headers requires identifying exactly where the <PRI> field disappears.

Since a typical syslog forwarding pipeline may include Wazuh, relays, load balancers, log processors, and SIEM platforms, it’s important to inspect each stage rather than assuming Wazuh is responsible.

The most effective approach is to compare the message as it leaves the Wazuh manager with the message that ultimately reaches the destination.

Capture Raw Syslog Packets

Packet captures provide the most reliable evidence when troubleshooting RFC5424 formatting issues.

Instead of relying solely on application logs, capture the actual network traffic carrying the syslog messages.

Ideally, capture traffic at multiple locations:

• On the Wazuh manager
• Before any middleware
• After each relay or proxy
• On the destination syslog receiver

This allows you to pinpoint exactly where the PRI header is removed.

Using tcpdump

tcpdump is one of the quickest ways to inspect outbound syslog traffic.

For example:

sudo tcpdump -A -s0 port 514

If RFC5424 forwarding is working correctly, the captured payload should begin with something similar to:

<134>1 2026-07-16T15:40:11Z wazuh-manager ...

If the packet already lacks the <PRI> field when leaving the Wazuh manager, the problem is likely within the Wazuh configuration or the application generating the message.

Also, if the packet contains the PRI header on the manager but not on the receiver, an intermediate device is modifying the message.

Using Wireshark

Wireshark provides a graphical way to inspect RFC5424 messages.

Useful features include:

• Following TCP streams
• Inspecting packet payloads
• Comparing captures side-by-side
• Verifying message framing
• Exporting packets for analysis

When reviewing packets, pay particular attention to the very beginning of each syslog message.

If the first bytes are not:

<PRI>

the message is no longer RFC5424 compliant.

Comparing Sent vs Received Messages

One of the fastest ways to isolate the problem is to compare:

• Message leaving Wazuh
• Message arriving at the collector

Example:

Sent

<134>1 2026-07-16T15:40:11Z wazuh-manager ...

Received

1 2026-07-16T15:40:11Z wazuh-manager ...

If the only difference is the missing <134>, you’ve confirmed that something between the sender and receiver stripped the PRI header.

Inspect Wazuh Manager Logs

Before modifying any configuration, examine the Wazuh manager logs for forwarding-related errors.

Although missing PRI headers are usually caused by downstream components, manager logs may reveal:

• Configuration errors
• Failed forwarding attempts
• Invalid destinations
• Module startup failures
• Formatting issues

ossec.log

The primary Wazuh log file is:

/var/ossec/logs/ossec.log

Look for entries related to:

• Syslog forwarding
• Connection failures
• Configuration parsing
• Output modules
• Integration errors

If no forwarding errors appear here, the issue may exist after the manager transmits the message.

Related Guide: How to Configure Wazuh as a Centralized Syslog Server

Internal Debug Logging

If the issue cannot be reproduced easily, temporarily enable additional logging to gather more detailed information about the forwarding process.

Debug logging can help determine:

• Whether messages are generated correctly
• Which output module is used
• Whether formatting errors occur before transmission
• Whether forwarding succeeds without modification

Remember to disable verbose logging after troubleshooting, as it can significantly increase log volume.

Test Forwarding with logger

Before investigating Wazuh further, verify that the downstream infrastructure correctly handles standard RFC5424 messages.

The Linux logger utility provides an easy way to generate test syslog traffic.

Using logger Command

A simple example:

logger --rfc5424 "RFC5424 priority header test"

If the receiver correctly processes this message, the downstream infrastructure is likely functioning properly.

If the PRI header is still missing, the issue probably exists somewhere after the message leaves the sender.

Creating RFC5424 Test Messages

Generate multiple messages using different facilities and severities.

For example:

• Informational
• Warning
• Error
• Critical

Verify that each message arrives with its expected PRI value.

Testing multiple severity levels helps determine whether the receiver is recalculating priorities or discarding them entirely.

Verify Downstream Syslog Receiver

Once you’ve confirmed that Wazuh transmits valid RFC5424 messages, inspect the receiving system.

Many parsing issues originate here rather than on the sender.

rsyslog Configuration

Review rsyslog for:

• Custom templates
• Rewrite rules
• Message normalization
• Legacy compatibility options
• Forwarding actions

Templates that rebuild messages should include the PRI field explicitly when necessary.

syslog-ng Configuration

In syslog-ng, examine:

• Destination templates
• Rewrite rules
• Parser chains
• Filters
• RFC mode settings

Improper templates can accidentally remove the leading priority header while preserving the remainder of the message.

SIEM Parsing Rules

Finally, inspect the SIEM itself.

Some SIEM platforms:

• Expect RFC3164
• Expect RFC5424
• Auto-detect message formats
• Rewrite incoming events
• Normalize headers during ingestion

Verify that the configured parser matches the format being sent by Wazuh.

If necessary, compare the raw network packet with the event stored in the SIEM to determine whether modification occurred during ingestion.

Fixing Stripped Priority Headers

After identifying where the PRI header disappears, the next step is implementing a permanent solution.

In most environments, the fix involves preserving the original RFC5424 message throughout the forwarding pipeline rather than reconstructing it at intermediate stages.

The following best practices resolve the vast majority of stripped priority header issues.

Verify Wazuh Syslog Output Configuration

Start by confirming that Wazuh is configured to generate RFC5424-compliant syslog messages.

Review the relevant ossec.conf settings and ensure they match the requirements of the destination collector.

Check Output Format

Confirm that the configured output format matches what the receiving system expects.

Common mistakes include:

• Sending RFC5424 to an RFC3164-only receiver
• Mixing legacy and modern syslog formats
• Using incompatible forwarding templates

Consistency across the entire pipeline is essential.

Validate Destination Configuration

Ensure that:

• IP addresses are correct
• Ports are correct
• Protocols match
• TLS settings are compatible
• Firewalls allow the traffic

Connectivity problems can sometimes trigger fallback behaviors in intermediary software that alter message formatting.

Confirm RFC5424 Support

Not every syslog receiver fully supports RFC5424.

Before troubleshooting Wazuh, verify that the destination platform:

• Accepts RFC5424
• Preserves PRI values
• Supports structured data
• Does not automatically downgrade messages to RFC3164

Consult the vendor’s documentation if necessary.

Preserve Original Syslog Headers

Whenever possible, forward the original syslog message rather than rebuilding it.

Maintaining the original header reduces the likelihood of introducing formatting errors.

Forward Raw Events

Avoid unnecessary transformations between the sender and receiver.

Each additional processing stage increases the chance that required RFC5424 fields, including the PRI header, will be altered or removed.

Avoid Message Reconstruction

Instead of generating new syslog messages, pass the original message through the forwarding pipeline unchanged whenever practical.

This preserves:

• PRI
• Timestamp
• Hostname
• Structured Data
• Application name
• Message ID

Disable Header Rewriting

Many middleware platforms include optional header rewriting or normalization features.

Unless these features are explicitly required, disabling them reduces the risk of RFC5424 incompatibilities.

Configure rsyslog Correctly

If rsyslog is part of the forwarding chain, review its configuration carefully.

Focus on any custom actions or templates that generate outbound syslog messages.

Preserve PRI Values

Ensure that forwarding rules retain the original priority rather than assigning a new one.

This helps preserve the event’s intended facility and severity from source to destination.

Avoid Template Modifications

Custom rsyslog templates should be reviewed after upgrades or configuration changes.

Removing or altering header components may inadvertently strip the PRI field.

Whenever possible, use standard RFC5424 templates unless customization is required.

Forward Complete Messages

Rather than forwarding selected fields, transmit the complete syslog payload.

This minimizes compatibility issues and preserves standards compliance.

Configure syslog-ng Properly

syslog-ng offers extensive flexibility, but that flexibility also increases the likelihood of accidental message modification.

Review:

• Rewrite rules
• Destinations
• Templates
• Format options
• Parser chains

for anything that reconstructs outbound syslog messages.

Disable Header Reformatting

Unless absolutely necessary, avoid enabling options that regenerate syslog headers.

Passing the original message through unchanged is generally the safest approach.

Preserve RFC5424 Fields

Ensure that every required RFC5424 field remains intact, including:

• PRI
• Version
• Timestamp
• Hostname
• Application name
• Process ID
• Message ID
• Structured Data

Missing any mandatory field can cause downstream parsing failures.

Validate Templates

After editing templates, test with sample messages to confirm that the output still conforms to RFC5424.

Comparing template output with the RFC specification can help identify omitted fields before deployment.

Update Custom Parsing Pipelines

If custom scripts or processing pipelines are involved, review each transformation step.

Look for code that:

• Rebuilds messages
• Extracts only portions of the payload
• Removes leading characters
• Converts formats

Each transformation should preserve the original RFC5424 envelope unless a deliberate conversion is required.

Preserve Original Message

Whenever feasible, enrich events by adding metadata rather than reconstructing the entire syslog message.

This approach significantly reduces the chance of accidentally removing mandatory header fields.

Avoid Regular Expressions That Remove <PRI>

Regular expressions can unintentionally strip the priority header.

Common examples include patterns that:

• Remove text between angle brackets
• Trim everything before the first space
• Extract only the message body
• Replace the opening portion of each line

Review parsing expressions carefully whenever message reconstruction is performed.

Validate Transformations

Before deploying changes to production, validate every transformation stage by comparing:

• Original message
• Intermediate message
• Final message

Even a single processing step can introduce formatting errors that affect downstream parsing.

Verify End-to-End Delivery

After implementing fixes, perform a complete end-to-end validation.

Generate test events and confirm that every system in the forwarding pipeline preserves the PRI header.

Compare Raw Packets

Repeat packet captures after making configuration changes.

If the captured traffic now begins with:

<134>

throughout the entire pipeline, you’ve confirmed that the issue has been resolved.

Confirm RFC5424 Compliance

Use representative test messages to verify that:

• Required fields are present.
• The PRI header appears first.
• Structured data is preserved.
• Timestamps are correctly formatted.
• Downstream collectors parse the messages without errors.

Validating against the RFC5424 specification helps ensure long-term interoperability across heterogeneous logging environments.

Test Multiple Severity Levels

Finally, generate events with different severity levels, such as Informational, Warning, Error, and Critical, and verify that each arrives with the expected PRI value.

Testing multiple facilities and severities confirms that:

• Priority calculations remain accurate.
• Routing rules function correctly.
• SIEM dashboards display the proper severity.
• Alerting workflows continue to operate as expected.

Example Configuration

The best way to prevent stripped RFC5424 priority headers is to maintain a consistent syslog format from the Wazuh manager all the way to the final SIEM or log collector.

The following examples demonstrate how a typical forwarding pipeline should preserve the PRI header throughout the entire process.

Wazuh Syslog Output Example

Wazuh forwards alerts through the manager configuration file:

/var/ossec/etc/ossec.conf

A typical syslog output configuration should define:

• Destination address
• Destination port
• Transport protocol
• Syslog format requirements

Example:

<syslog_output>
  <server>192.168.1.100</server>
  <port>514</port>
  <format>default</format>
</syslog_output>

After enabling syslog forwarding, restart the Wazuh manager:

systemctl restart wazuh-manager

Then verify that forwarded events contain the PRI header:

<134>1 2026-07-16T16:20:30Z wazuh-manager Wazuh 1001 - - Authentication failure detected

The important element is the first field:

<134>

If this value is missing before the message leaves the Wazuh manager, the problem exists within the Wazuh forwarding configuration or message-generation process.

rsyslog Forwarding Example

If rsyslog is used as a relay between Wazuh and the destination SIEM, ensure that forwarding rules preserve RFC5424 formatting.

Example:

module(load="omfwd")

action(
    type="omfwd"
    target="192.168.1.200"
    port="514"
    protocol="tcp"
    template="RSYSLOG_SyslogProtocol23Format"
)

The RSYSLOG_SyslogProtocol23Format template preserves RFC5424-compatible formatting.

Avoid custom templates that only forward the message body:

template(name="BadTemplate" type="string" string="%msg%\n")

The above example removes the syslog header entirely, including the PRI field.

A safer approach is to preserve the complete message structure:

template(name="RFC5424Template" type="string" string="<%pri%>%protocol-version% %timestamp:::date-rfc3339% %hostname% %app-name% %procid% %msgid% %structured-data% %msg%\n")

syslog-ng Forwarding Example

syslog-ng uses templates to define how messages are formatted before forwarding.

A basic RFC5424-compatible forwarding configuration may look like:

destination d_wazuh_forward {
    syslog(
        "192.168.1.200"
        transport("tcp")
        template("${ISODATE} ${HOST} ${MSG}\n")
    );
};

log {
    source(s_local);
    destination(d_wazuh_forward);
};

However, custom templates can accidentally remove required fields.

For example:

template("${MSG}\n");

This forwards only the message body and discards:

• PRI
• Timestamp
• Hostname
• Application metadata

When forwarding RFC5424 messages, ensure the destination template preserves the complete syslog structure.

Sample RFC5424 Message Before and After the Fix

Comparing raw messages before and after a configuration change is one of the fastest ways to confirm that the PRI header issue has been resolved.

Before the Fix

The forwarded message arrives without a priority header:

1 2026-07-16T16:25:12Z wazuh-manager Wazuh 1001 - - Failed SSH authentication attempt

Problems:

• Missing <PRI>
• Invalid RFC5424 format
• Receiver cannot determine facility or severity
• SIEM parser may fail

After the Fix

The corrected message contains the PRI field:

<131>1 2026-07-16T16:25:12Z wazuh-manager Wazuh 1001 - - Failed SSH authentication attempt

Now the receiver can correctly identify:

Facility = 16 (local0)
Severity = 3 (Error)
PRI = 131

The message is now compliant with RFC5424 and can be processed correctly by downstream systems.

Troubleshooting Checklist

Use the following checklist when diagnosing Wazuh RFC5424 forwarding issues involving missing priority headers.

Working through each step systematically helps identify whether the problem exists in Wazuh, the network path, middleware, or the final SIEM.

Verify RFC5424 Output Format

Confirm that Wazuh and all forwarding components are configured to use RFC5424 rather than an incompatible legacy format.

Check:

• Syslog version
• Output templates
• Destination requirements
• Parser expectations

Confirm PRI Header Exists at the Source

Before troubleshooting downstream systems, verify the message leaving Wazuh.

A valid RFC5424 message must begin with:

<PRI>

Example:

<134>1 2026-07-16T16:30:00Z ...

If the header is already missing at the source, investigate Wazuh configuration first.

Capture Packets with tcpdump

Use packet captures to inspect the actual syslog traffic:

tcpdump -A -s0 port 514

Confirm whether the PRI header exists on the wire.

This eliminates uncertainty caused by application-level logs.

Compare Transmitted and Received Messages

Compare the message:

• Leaving the Wazuh manager
• Arriving at the collector

If the PRI header disappears between these points, investigate:

• Load balancers
• Relays
• Proxies
• Middleware
• Network appliances

Review Intermediary Log Processors

Inspect every component in the forwarding chain:

• rsyslog
• syslog-ng
• Logstash
• Fluentd
• Fluent Bit
• Kafka pipelines
• Cloud forwarding services

Any component capable of rewriting messages can remove the PRI header.

Validate rsyslog/syslog-ng Templates

Custom templates are one of the most common causes of stripped headers.

Review:

• Output templates
• Rewrite rules
• Message formatters
• Forwarding actions

Avoid templates that send only %msg% or equivalent message-body fields.

Check Firewall or Load Balancer Behavior

Network devices can sometimes modify syslog traffic.

Verify:

• TCP proxy settings
• TLS termination
• Message inspection features
• Payload rewriting
• Connection handling

Capture traffic before and after these devices if necessary.

Test with logger-Generated Messages

Use Linux logger to send known RFC5424 messages.

Example:

logger --rfc5424 "PRI header validation test"

If these messages also arrive without PRI values, the issue likely exists outside Wazuh.

Enable Debug Logging

Temporarily enable additional debugging to determine:

• Whether Wazuh generates the correct output
• Whether forwarding succeeds
• Whether errors occur during transmission

Disable debug logging after testing to avoid unnecessary resource usage.

Confirm Downstream Parser Compatibility

Ensure that the receiving SIEM or syslog collector expects RFC5424.

Verify:

• Parser type
• Syslog version
• Required fields
• Normalization rules
• Custom extraction logic

A correct RFC5424 message can still fail if the receiver expects another format.

Related Guide: Troubleshooting wazuh-logtest: Why Alerts Are Missing from JSON Output

Best Practices for Reliable RFC5424 Syslog Forwarding

Maintaining reliable Wazuh syslog forwarding requires more than fixing missing PRI headers once.

A strong logging architecture should preserve RFC5424 compliance throughout the entire lifecycle of every event.

The following practices help prevent future forwarding failures.

Preserve Original Syslog Messages

Whenever possible, avoid rebuilding syslog messages manually.

Preserving the original message maintains:

• PRI values
• Severity levels
• Facilities
• Timestamps
• Metadata fields
• Structured data

Every transformation step introduces additional risk.

Use RFC5424 End-to-End

Use RFC5424 consistently across the entire pipeline:

Wazuh
  ↓
Syslog Relay
  ↓
SIEM
  ↓
Storage Platform

Mixing RFC3164 and RFC5424 increases the chance of:

• Header conversion
• Parsing failures
• Lost metadata
• Incorrect severity values

Avoid Unnecessary Message Rewriting

Only modify syslog messages when there is a clear operational requirement.

Avoid unnecessary:

• Templates
• Regex replacements
• Format conversions
• Field extraction and reconstruction

The safest syslog pipeline is usually the simplest one.

Validate Configurations After Updates

Software upgrades can change:

• Default templates
• Syslog modules
• Parser behavior
• Configuration syntax

After updating:

• Wazuh
• rsyslog
• syslog-ng
• SIEM connectors

perform RFC5424 validation tests.

Related Guide: How to Upgrade a Wazuh Agent

Monitor Syslog Forwarding Regularly

Do not wait for a security incident to discover broken forwarding.

Monitor:

• Forwarding failures
• Collector ingestion rates
• Parsing errors
• Dropped messages
• Severity distribution changes

Unexpected drops in high-severity events should trigger investigation.

Test with Multiple Syslog Receivers

Different receivers interpret RFC5424 differently.

Test forwarding against multiple platforms when possible:

• rsyslog
• syslog-ng
• SIEM platforms
• Cloud logging services

This helps identify compatibility issues before production deployment.

Document Custom Forwarding Pipelines

Maintain documentation for:

• Data flow diagrams
• Syslog formats
• Middleware components
• Templates
• Custom scripts
• Transformation rules

When troubleshooting, knowing every component between Wazuh and the SIEM dramatically reduces investigation time.

Automate Configuration Validation

Automated checks can detect problems before they impact security monitoring.

Consider automating:

• RFC5424 format validation
• PRI header checks
• Syslog connectivity tests
• Parser validation
• Template verification

A simple automated test that confirms every forwarded message begins with a valid PRI value can prevent silent logging failures.

Related Guide:

• How to Test Wazuh Rules
• Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Reliable RFC5424 forwarding ensures that Wazuh alerts maintain their intended severity, routing information, and metadata from detection through investigation.

By preserving the PRI header and avoiding unnecessary message transformations, organizations can maintain accurate SIEM visibility and dependable security monitoring.

Frequently Asked Questions (FAQ)

Question: Why is the PRI header missing from forwarded Wazuh syslog messages?

The PRI header is usually missing because a component in the forwarding pipeline removed or replaced the original RFC5424 message header.

Common causes include:

• Incorrect Wazuh syslog output configuration
• Custom rsyslog or syslog-ng templates
• Log processors rebuilding messages incorrectly
• Load balancers modifying TCP streams
• Custom scripts extracting only the message body
• SIEM connectors normalizing syslog events

The first troubleshooting step is determining whether the <PRI> value exists when the message leaves the Wazuh manager.

If the header exists at the source but disappears later, the issue is caused by an intermediary component rather than Wazuh.

Related Guide: Troubleshoot Wazuh Syslog Port 514 Ingestion

Question: Does Wazuh generate RFC5424 priority headers automatically?

Wazuh can generate syslog messages containing priority information when configured for syslog forwarding.

The PRI value is part of the syslog message header and contains:

• Facility
• Severity
• Priority calculation

However, the final message received by a SIEM depends on the entire forwarding path.

Even if Wazuh generates a correct RFC5424 message, another component can remove or rewrite the header before delivery.

Administrators should validate the complete pipeline:

Wazuh Manager
      ↓
Syslog Relay
      ↓
Network Device
      ↓
SIEM Collector

Every stage must preserve RFC5424 fields.

Question: Can rsyslog remove priority headers?

Yes.

rsyslog can remove PRI headers if administrators use custom forwarding templates that do not include the syslog header.

For example:

template(name="MessageOnly" type="string" string="%msg%\n")

This forwards only the message body and discards:

• PRI
• Timestamp
• Hostname
• Application metadata

When forwarding RFC5424 messages, use standard syslog templates or explicitly include the required header fields.

Question: Can syslog-ng rewrite RFC5424 messages?

Yes.

syslog-ng can rewrite RFC5424 messages through:

• Templates
• Rewrite rules
• Parsers
• Destination configurations

A custom destination template that only outputs ${MESSAGE} may unintentionally remove the PRI header.

To maintain RFC5424 compliance:

• Avoid unnecessary rewrites
• Preserve original messages
• Validate destination templates
• Test forwarded messages after configuration changes

Question: How do I verify whether PRI headers are being transmitted?

The most reliable method is capturing the actual syslog traffic.

Useful tools include:

tcpdump

Example:

sudo tcpdump -A -s0 port 514

A valid RFC5424 message should begin with:

<PRI>

Example:

<134>1 2026-07-16T17:00:00Z wazuh-manager ...

Wireshark

Wireshark allows you to:

• Follow TCP streams
• Inspect packet payloads
• Compare sender and receiver traffic

If the PRI header exists leaving Wazuh but disappears later, investigate intermediary systems.

Question: Does TCP or UDP affect RFC5424 priority headers?

TCP and UDP do not directly remove PRI headers.

The PRI field is part of the syslog message format, not the transport protocol.

However, protocol differences can indirectly contribute to issues.

Examples:

• TCP proxies may rewrite message streams
• UDP relays may apply different parsing rules
• TLS termination devices may reconstruct messages
• Framing differences may trigger normalization

When troubleshooting, verify both:

• Transport protocol
• Syslog message format

Question: Can Logstash or Fluent Bit strip PRI headers?

Yes.

Both Logstash and Fluent Bit can remove PRI headers if they parse and rebuild messages without preserving the original syslog structure.

Common causes include:

• Extracting only the message field
• Applying transformations
• Converting formats
• Generating new syslog events

For example, a pipeline may receive:

<134>1 2026-07-16T17:10:00Z wazuh-manager ...

but output:

2026-07-16T17:10:00Z wazuh-manager ...

The message content remains, but RFC5424 compliance is lost.

Review all filters, parsers, and output plugins involved in the forwarding process.

Question: What tools can validate RFC5424 compliance?

Several tools can help validate RFC5424 messages:

tcpdump

Useful for verifying raw network traffic.

Wireshark

Useful for packet inspection and stream analysis.

logger

Useful for generating test RFC5424 messages.

Example:

logger --rfc5424 "RFC5424 validation test"

Syslog collectors

Tools such as:

• rsyslog
• syslog-ng

can help test parsing behavior.

Custom validation scripts

Organizations can also create automated checks that verify:

• PRI presence
• Header formatting
• Timestamp structure
• Required RFC5424 fields

Question: How do I preserve original syslog messages in Wazuh?

The best approach is to minimize message transformations.

Recommended practices:

• Forward complete events instead of rebuilding messages
• Avoid unnecessary parsing pipelines
• Preserve the original syslog envelope
• Avoid templates that output only the message body
• Validate every intermediary component

If a relay or SIEM integration requires transformation, ensure the PRI value is explicitly preserved.

Question: What is the difference between RFC3164 and RFC5424 priority headers?

Both RFC3164 and RFC5424 use the same basic PRI calculation:

PRI = (Facility × 8) + Severity

The main difference is the surrounding message structure.

RFC5424 is generally preferred for modern SIEM integrations because it provides more consistent parsing and richer metadata.

Conclusion

RFC5424 priority headers are a small but critical component of reliable syslog forwarding.

The <PRI> value provides downstream systems with essential information about an event’s facility and severity, allowing SIEM platforms, log collectors, and security automation tools to correctly classify, route, and prioritize alerts.

When Wazuh syslog forwarding produces messages without PRI headers, the issue is usually not the detection engine itself.

More often, the header is removed somewhere in the forwarding pipeline through:

• Incorrect syslog output configuration
• Custom rsyslog templates
• syslog-ng rewrites
• Logstash transformations
• Fluent Bit processing
• Custom scripts
• Load balancers or network devices
• SIEM ingestion pipelines

The most effective troubleshooting strategy is to validate every stage of the logging path:

Wazuh Manager
      ↓
Syslog Forwarder
      ↓
Middleware / Relay
      ↓
Network Infrastructure
      ↓
SIEM Receiver

Capture raw packets, compare transmitted and received messages, and verify that the PRI header remains intact from beginning to end.

Regular configuration reviews are especially important after:

• Wazuh upgrades
• SIEM migrations
• Syslog relay changes
• Network architecture updates
• Middleware configuration changes

By preserving original RFC5424 messages, avoiding unnecessary rewriting, and continuously validating forwarding pipelines, organizations can maintain accurate severity classification, dependable alert routing, and reliable security monitoring across their entire Wazuh environment.