OPNsense at Home, Part 4: Observability
This is part 4 of a 4-part series. Part 1: The Migration covers the hardware and initial setup. Part 2: Securing the Network covers DNS, ad blocking, IDS, and hardening. Part 3: Connectivity covers dual WAN, WireGuard, and bufferbloat.
The problem
The part that took the most time to get right was knowing what was happening on the network. OPNsense's built-in logging is fine for spot-checking but not for trend analysis or alerting.
The architecture
- OPNsense sends syslog (UDP 514) and NetFlow/IPFIX (UDP 2055) to a Linux machine on the network
- Vector receives both streams and routes them: syslog to Loki (for long-retention log storage) and to OpenSearch (for full-text search and alerting), NetFlow to Prometheus
- Grafana provides a single dashboard over all three
The Linux machine is a small fanless mini-PC with 32GB RAM and 1TB NVMe. Disk allocation: 600GB for OpenSearch (90-day retention), 300GB for Loki (180+ days, compressed), 50GB for Prometheus metrics.
OPNsense configuration
Syslog config is entirely in the UI: System > Logging > Remote. Add the Linux machine's IP on port 514, UDP, and enable the log categories you want (firewall, DHCP, Unbound, system logs). No packages needed on OPNsense, no SSH, no touching the underlying OS.
NetFlow is under Reporting > NetFlow. Set the collector IP and port (2055) and enable it on all interfaces.
What this gives you
| Question | Data source |
|---|---|
| What devices are active right now? | DHCP syslog in Loki |
| New device joined the network? | OpenSearch alert on new MAC in DHCP events |
| What is using my bandwidth? | NetFlow in Prometheus / Grafana |
| Firewall blocking something unusual? | Syslog firewall logs in OpenSearch |
| IDS fired on something? | Suricata EVE JSON via syslog in OpenSearch |
| Did my WAN failover? | System logs in OpenSearch |
I also have a scheduled job that queries these sources and produces an hourly digest and daily summary: new devices detected, firewall spike detection (blocked events more than 2x the rolling average), IDS alert summaries by signature and source, and gateway failover events. The digest makes it easy to spot things that would otherwise get lost in log volume.
What stayed on the Raspberry Pi
The Pi is still on the network but doing much less. Everything that makes sense to run on dedicated hardware moved to the VP6650: multi-WAN failover, WireGuard, DNS filtering, Suricata. The observability stack moved to the Linux mini-PC. The Pi now runs only the Cloudflare tunnel daemon, isolated on its own port. The reasoning is that if the tunnel is somehow abused, the blast radius does not include the firewall.
This is the final part of the series. Start from Part 1: The Migration if you have not read the earlier posts.