Wazuh is an open-source security platform that combines Extended Detection and Response (XDR) and Security Information and Event Management (SIEM) capabilities into a unified security monitoring solution.
It enables organizations to collect, analyze, and respond to security telemetry across endpoints, servers, cloud workloads, and network devices in real time.
Wazuh is widely adopted for threat detection, log analysis, vulnerability detection, and compliance monitoring across enterprise environments.
OPNsense, on the other hand, is a powerful open-source firewall and routing platform built on FreeBSD.
It provides enterprise-grade network security features such as stateful firewalling, VPN support, traffic shaping, and intrusion detection/prevention through integrations like Suricata.
OPNsense is commonly deployed as an edge firewall or internal segmentation control point in modern network architectures.
Integrating Wazuh with OPNsense creates a centralized network security observability layer, where firewall and IDS events are correlated with endpoint and server telemetry.
This significantly improves detection accuracy and reduces blind spots in perimeter security monitoring.
From an operational perspective, this integration enables:
- Firewall event monitoring: Track allow/deny traffic patterns and suspicious connections in real time
- Intrusion detection correlation: Combine Suricata alerts from OPNsense with Wazuh rule-based detection for higher fidelity alerts
- Compliance logging (ISO 27001, PCI-DSS): Centralize security logs for audit readiness and regulatory reporting
For deeper context on log analysis strategies, you may also find this useful:
Architecture Overview
The integration between Wazuh and OPNsense is primarily built on log forwarding and centralized event processing, where OPNsense acts as a log source and Wazuh functions as the analysis and correlation engine.
How OPNsense Generates Logs
OPNsense produces multiple types of security-relevant logs, including:
- Firewall logs: Packet filtering decisions (allow/deny, source/destination IPs, ports, protocols)
- System logs: Authentication events, system services, and administrative actions
- Suricata IDS/IPS logs (optional module): Network intrusion detection alerts, protocol anomalies, and signature-based threat detections
These logs are typically exported via syslog, which allows external systems like Wazuh to ingest them in real time.
How Wazuh Ingests Data
Wazuh supports multiple ingestion methods depending on the architecture:
- Agent-based collection: Installed on endpoints for local telemetry
- Syslog ingestion: Remote devices (like OPNsense) forward logs directly to the Wazuh manager
- Centralized log processing: Wazuh decoders parse incoming logs into structured events
- Rule engine correlation: Security rules evaluate events and trigger alerts based on predefined logic
In the case of OPNsense, syslog forwarding is the primary integration method, making it lightweight and agentless on the firewall side.
High-Level Integration Flow
The architecture can be summarized as follows:
OPNsense → Syslog → Wazuh Manager → Decoders & Rules → Alerts
- OPNsense generates logs from firewall rules, system events, and optional IDS modules
- Logs are forwarded via syslog to the Wazuh manager or a log collector
- Wazuh decoders parse raw log formats into structured JSON-like events
- Wazuh rules evaluate event behavior, such as repeated connection attempts or known attack patterns
- If conditions match, Wazuh generates security alerts and dashboards
This model allows organizations to unify network-level and host-level security telemetry into a single SIEM/XDR layer.
For related detection and correlation strategies, see:
Prerequisites
Before integrating Wazuh with OPNsense, you need to ensure both systems are properly deployed and capable of exchanging logs reliably.
This integration depends on stable syslog transport and a correctly configured Wazuh manager pipeline for decoding and correlation.
Required Components
- Running Wazuh Manager (Server-Side Setup)
Wazuh must be installed and operational, including the manager, indexer, and dashboard components. The manager is responsible for receiving syslog data from OPNsense and processing it through decoders and rules. - Access to OPNsense Admin Panel
You need administrative access to the OPNsense web interface to configure remote logging targets and enable syslog forwarding. - Network Connectivity Between OPNsense and Wazuh Server
Ensure bidirectional network reachability between OPNsense and the Wazuh manager. This typically includes:- Firewall rules allowing syslog traffic
- Open UDP/TCP ports (commonly 514 or a custom port)
Optional (Recommended for Production Environments)
- TLS / Secure Syslog Configuration
In production environments, syslog should ideally be encrypted using TLS (syslog over TLS) to prevent log interception or tampering during transit. - Suricata Enabled on OPNsense
If you plan to correlate intrusion detection events, enabling the Suricata IDS/IPS module on OPNsense significantly enhances detection fidelity when combined with Wazuh rule correlation.
For additional context on detection tuning, see:
Configure OPNsense for Log Forwarding
OPNsense supports native syslog forwarding, which allows firewall and system logs to be sent directly to external log collectors such as the Wazuh manager.
Enable Remote Syslog on OPNsense
To begin forwarding logs:
Navigate to:
System → Settings → Logging / Targets
This section controls all remote logging destinations and severity/category filtering.
Configure Syslog Target
Add a new syslog target with the following parameters:
- Syslog Server IP: IP address of your Wazuh manager
- Port: Typically
514(UDP or TCP), or a custom port depending on your Wazuh syslog configuration - Protocol: UDP is common for simplicity; TCP is preferred for reliability
- Transport Security (optional): Enable TLS if your environment supports secure syslog transport
Select Log Categories
Ensure you enable the relevant log sources for security monitoring:
- Firewall logs (core for traffic analysis and threat detection)
- System logs (authentication, services, configuration changes)
- DHCP logs (useful for IP-to-device mapping correlation)
- VPN logs (if applicable) (critical for remote access monitoring and anomaly detection)
Apply and Validate Configuration
After saving:
- Apply changes in OPNsense
- Generate test traffic (e.g., blocked connection attempt)
- Verify syslog forwarding is active using live log view or packet inspection tools
For deeper log ingestion strategies, you may also reference:
- Internal link: How to Configure File Integrity Monitoring (FIM) in Wazuh
Configure Wazuh to Receive OPNsense Logs
Once OPNsense is forwarding logs, the next step is ensuring the Wazuh manager is correctly configured to receive, store, and process them.
Enable Syslog Listener on Wazuh Manager
Wazuh must be configured to accept incoming syslog traffic from external devices.
Depending on your setup, this may involve:
- Ensuring the Wazuh manager is listening on the configured syslog port (commonly 514 UDP/TCP or custom port)
- Verifying that rsyslog or a similar syslog daemon is properly integrated (in many deployments, Wazuh relies on system-level syslog ingestion before processing)
Open Required Firewall Ports
Make sure the following ports are open between OPNsense and the Wazuh server:
- UDP 514 (common syslog transport)
- TCP 514 (preferred for reliability in enterprise setups)
- Any custom syslog ports defined in your configuration
Without proper firewall rules, logs will not reach the Wazuh ingestion pipeline.
Verify Log Ingestion
After configuration, confirm that logs are being received and processed.
Check the following files on the Wazuh manager:
/var/ossec/logs/archives/archives.json- Contains raw, unprocessed events (useful for verifying ingestion)
/var/ossec/logs/ossec.log- Contains Wazuh manager operational logs, including decoding and rule processing status
If logs are flowing correctly, you should see OPNsense-generated events appearing in near real time.
For deeper visibility into detection logic, see:
Create or Enable Wazuh Decoders for OPNsense
Once logs from OPNsense are being ingested, the next critical step is ensuring Wazuh can correctly parse and structure those logs into meaningful fields.
This is handled by decoders in the Wazuh analysis engine.
Default Syslog Decoder Behavior
By default, Wazuh uses a generic syslog decoder to process incoming logs. This decoder:
- Extracts basic syslog metadata (timestamp, host, process, message body)
- Attempts to classify logs based on known patterns
- Passes unrecognized log formats into raw event storage for further analysis
However, OPNsense logs are semi-structured and often require more granular decoding to extract actionable security fields such as source IP, destination IP, action type, and protocol.
For background on rule and decoder architecture, see:
Custom Decoder Considerations for OPNsense
To fully leverage OPNsense telemetry, custom Wazuh decoders are often required.
These decoders allow you to map raw syslog messages into structured fields that can be used by Wazuh rules.
Firewall Allow/Deny Events
Firewall logs typically include key security fields such as:
- Action (pass/block/reject)
- Source IP
- Destination IP
- Source/Destination ports
- Interface name
Custom decoders should extract these fields so Wazuh can evaluate traffic behavior patterns rather than just raw text logs.
NAT Logs
Network Address Translation (NAT) events require special handling because they include:
- Original source/destination mapping
- Translated IP addresses
- Port remapping information
Proper decoding of NAT logs enables correlation between internal hosts and external traffic patterns, which is critical for incident investigation.
IDS/IPS Events (Suricata Integration)
If Suricata is enabled on OPNsense, its logs typically include:
- Signature ID (SID)
- Threat classification
- Protocol metadata
- Alert severity
Wazuh decoders should map Suricata alerts into structured fields so they can be correlated with endpoint or firewall events for enriched detection context.
Example Log Structure Parsing
A typical OPNsense firewall log entry may resemble:
- Timestamp
- Interface
- Action (pass/block)
- Source IP → Destination IP
- Protocol/port information
A properly designed decoder transforms this into structured fields such as:
srcipdstipactionprotocolsrcportdstport
This structured format is essential for rule-based correlation in Wazuh.
Define Wazuh Rules for OPNsense Events
Once logs are normalized through decoders, Wazuh rules determine how events are evaluated, correlated, and escalated into alerts.
Detect Security-Relevant Patterns
Wazuh rules should focus on identifying abnormal or malicious behavior patterns originating from OPNsense logs.
Blocked Inbound Traffic Spikes
A sudden increase in blocked inbound connections may indicate:
- External reconnaissance activity
- Automated scanning tools
- Distributed attack attempts
Rules can be configured to trigger alerts when block events exceed a defined threshold within a time window.
Port Scanning Behavior
Port scanning detection is typically based on:
- Multiple connection attempts to different ports from a single source IP
- Sequential or randomized port probing patterns
- Repeated denied connection attempts
Wazuh can correlate these events to flag potential reconnaissance activity.
Repeated Authentication Failures (VPN/SSH)
If OPNsense is handling VPN or SSH access logs, Wazuh can detect:
- Brute-force login attempts
- Credential stuffing behavior
- Repeated failed authentication from the same IP or subnet
These rules are typically assigned higher severity due to their strong correlation with intrusion attempts.
Assign Severity Levels
Each rule should be assigned a severity level based on risk impact:
- Low: Informational traffic anomalies
- Medium: Suspicious scanning or repeated blocked events
- High: Confirmed attack patterns (brute force, exploit attempts)
Proper severity tuning is essential to avoid alert fatigue while preserving detection fidelity.
Trigger Alerts and Notifications
When rules are matched, Wazuh can trigger:
- Real-time dashboard alerts
- Email notifications
- SIEM integrations (e.g., Slack, webhook, SOAR platforms)
This ensures that OPNsense-generated security events are not only logged but actively monitored and acted upon.
Visualization in Wazuh Dashboard
After ingestion and rule processing, the final layer is visualization.
This allows security teams to interpret firewall and IDS data at scale.
Indexing OPNsense Logs in Wazuh Indexer (OpenSearch)
Wazuh uses an OpenSearch-based indexer to store and query security events. Once OPNsense logs are decoded and processed:
- Events are indexed in near real time
- Fields are searchable (srcip, action, rule.id, etc.)
- Correlated alerts are grouped for investigation
This enables fast querying of network behavior patterns and historical analysis.
Creating Dashboards for Security Monitoring
Wazuh dashboards can be customized to visualize OPNsense telemetry in multiple ways.
Top Blocked IPs
This visualization highlights:
- IPs generating the most denied connections
- Potential scanning sources
- Repeat offenders over time
Useful for identifying persistent external threats.
Firewall Deny Trends
This chart tracks:
- Volume of denied connections over time
- Traffic spikes correlated with potential attacks
- Changes in baseline network behavior
It is particularly useful for detecting anomaly-based security events.
Geographic Traffic Distribution (GeoIP Enabled)
If GeoIP enrichment is enabled, Wazuh can visualize:
- Source countries of inbound traffic
- Geographic clustering of suspicious activity
- Regions with high attack frequency
This helps security teams understand global threat exposure and prioritize defensive measures accordingly.
For broader monitoring concepts, see:
- Internal link: How to Monitor AWS CloudTrail Logs Using Wazuh
Be First to Comment