Overview
The Wazuh integration added centralized endpoint and firewall telemetry to an environment that was already intentionally segmented.
The engineering objective was not simply to make monitoring agents connect.
The monitoring platform had to preserve the existing security architecture: OPNsense remained the authoritative inter-zone firewall, the SIEM remained outside the production routing path, management-zone access stayed narrow, CI did not gain additional production authority, and remote administration continued to require no public router ports.
The result is an operational security-monitoring foundation that provides centralized visibility without turning the management zone into a permissive telemetry network.
The problem
The environment needed a central security-monitoring capability able to receive security data from systems operating across several trust domains.
Those sources include administrative systems, Linux and Windows hosts, production infrastructure, CI, virtualization, and the network firewall itself.
The architectural risk was straightforward: monitoring requirements can easily become justification for broad firewall exceptions.
That design was rejected.
Instead, each telemetry path is treated as an explicit infrastructure dependency with a defined source, destination, protocol, and purpose.
Architecture
The SIEM resides in the dedicated management and security zone.
Its role is to consume and analyze telemetry.
It is not an inline routing device and it does not replace the firewall.
The simplified relationship is:
administrative endpoints ─┐
production systems ───────┤
edge infrastructure ──────┤
CI ───────────────────────┤
virtualization ───────────┤
↓
Wazuh
OPNsense filterlog ───────→ WazuhOPNsense remains responsible for inter-zone enforcement.
Wazuh provides visibility into activity crossing and occurring within those boundaries.
Narrow telemetry policy
Agent traffic uses the Wazuh communication and enrollment services required by approved endpoints:
TCP/1514
agent communication
TCP/1515
enrollment and authenticationFirewall policy is applied to approved sources rather than creating a broad:
any
↓
SIEMexception.
Firewall telemetry follows a separate path:
OPNsense filterlog
↓
UDP/514
↓
WazuhThis allows the monitoring platform to receive network-policy events without becoming part of the enforcement path.
Protected administration
Wazuh dashboard and SSH administration use Cloudflare Access-protected paths.
No public router forwarding is required.
The SIEM administrative surface also remains distinct from the normal Docker and Caddy application path.
That separation reflects the different trust level of a security-management platform compared with an ordinary hosted application.
Defense in depth
The Wazuh host has its own host firewall using default-deny inbound behavior with narrow required permits.
This host-level policy does not replace OPNsense segmentation.
Instead, it establishes a second enforcement boundary around a high-value management workload.
The design therefore uses layered policy:
inter-zone policy
↓
OPNsense
host-local policy
↓
SIEM host firewallThe reply-to failure
The most significant implementation problem involved connections from systems located on the same transit subnet as the OPNsense WAN interface.
Addressing was correct.
Forward routing existed.
The firewall rules appeared to permit the flows.
Wazuh services were listening.
The connections still failed.
Investigation remained focused on the dependency chain rather than immediately changing the architecture:
source addressing
↓
route selection
↓
OPNsense policy
↓
return path
↓
service listener
↓
host firewallThe root cause was OPNsense reply-to behavior.
For the affected rules, return traffic was being forced toward the configured WAN gateway rather than directly back toward the source on the transit subnet.
The effective failure looked like:
transit source
↓
OPNsense
↓
Wazuh
Wazuh response
↓
OPNsense
↓
reply-to selects incorrect next hop
↓
connection failsNarrow resolution
The correction was intentionally scoped to the affected Wazuh rules.
Disable reply-to was enabled only where the same-transit-subnet behavior required it.
The project deliberately did not respond by globally disabling reply-to, adding broad NAT workarounds, opening unrestricted management-zone access, or relocating the SIEM into a less protected network.
This preserved the original network architecture while correcting the actual return-path problem.
Firewall-log integration
OPNsense forwards filterlog events directly to Wazuh.
The stock Wazuh pf decoder was validated against live firewall events.
One implementation detail is that stock Wazuh rule descriptions can retain terminology associated with pfSense even when the underlying OPNsense filterlog event is decoded correctly.
That label is therefore not treated as evidence that the wrong firewall platform is producing the event.
Validation
The operational baseline validates that the central Wazuh services are active, the indexer health is acceptable, approved endpoint agents communicate, enrollment is available where required, OPNsense firewall logs arrive, protected dashboard and SSH administration are reachable, required routes persist, host firewall policy allows intended services, and the narrow reply-to exception corrects the affected return path.
Negative testing is part of the same acceptance model.
Unapproved sources should not reach Wazuh agent services.
The SIEM should not gain unrestricted reach into arbitrary private networks.
No direct public-router exposure should exist.
Monitoring requirements should not create broad management-zone access.
Operational outcome
The monitoring foundation now provides representative visibility across administrative systems, the production application environment, edge infrastructure, isolated CI, virtualization, and firewall activity.
The result is centralized telemetry while preserving the segmentation model around the management and security zone.
This is intentionally described as an operational monitoring foundation rather than a complete production SOC platform.
Enforcement ownership
A key architectural principle is that security products retain distinct responsibilities.
Wazuh observes and analyzes security events.
OPNsense enforces inter-zone network policy.
Cloudflare Access protects approved remote administrative entry points.
The SIEM host firewall provides local defense in depth.
Keeping these responsibilities explicit avoids turning a monitoring platform into an accidental routing, firewall, or general administrative control plane.
Current maturity
The Wazuh foundation is operational, but several areas remain active maturity work.
Independent recovery and rebuild capability still require further validation outside the same physical-host failure domain.
Retention and capacity policy still need to be based on measured telemetry ingestion.
Alert-noise tuning, notification and escalation design, additional continuity checks, selected SSH hardening, and other operational hardening remain open.
Future AI, ICS/OT, and Red Team telemetry will be introduced only when those workloads become active and explicit network policy is justified.
The website therefore does not represent those future integrations as current monitoring coverage.
Engineering lessons
A SIEM does not justify broad firewall exceptions.
Return-path behavior can be as important as the forward firewall rule.
Troubleshooting should identify the narrow mechanism causing the failure before changing architectural boundaries.
An operational security tool is not automatically a mature security capability; recovery, retention, alerting, and continuity are separate engineering requirements.
Monitoring and enforcement should remain separate architectural responsibilities.
Detailed evidence
The public Homelab Security Portfolio contains the detailed sanitized engineering evidence for this integration, including the full Wazuh case study, current SIEM architecture, network segmentation model, trust-boundary documentation, and SSH administrative model.