Zenarmor (Sensei) on OPNsense: Free NGFW Setup and Tuning

Zenarmor (formerly Sensei) is a next-generation firewall plugin for OPNsense from Sunny Valley Networks. Where Suricata matches signatures, Zenarmor classifies applications — it can identify hundreds of apps and protocols by behaviour, sort traffic into web categories, and give you a live dashboard of who is talking to what. This guide covers a clean install, what the Free edition actually includes, and the tuning that keeps it from becoming your bottleneck.

First, set expectations about cost and capability. Zenarmor ships in tiers. The Free edition is genuinely free with no license and no expiry, but it limits you to editing a single default catch-all policy — you cannot create multiple per-VLAN or per-host policies. The paid Home edition unlocks multiple policies (three) and adds cloud threat intelligence such as blocking newly registered/suspicious domains and more reporting; Business adds TLS inspection, Active Directory integration, and longer reporting retention. For a single-LAN homelab the Free edition is a legitimate, useful starting point. If you need different rules for IoT vs trusted vs guest, you’ll hit the one-policy wall and need Home or above. Don’t install it expecting per-VLAN policy granularity for free.

Hardware reality

Zenarmor is a packet-classification engine and it is not lightweight. Sunny Valley’s own guidance is RAM-heavy: it caches classification data in memory, and the more flows you inspect, the more RAM it wants. As a practical homelab floor, give OPNsense 8 GB of RAM before enabling Zenarmor on a gigabit link, and prefer a quad-core Intel CPU. On a low-power dual/quad Atom box (J3160-class) Zenarmor runs, but expect it to be the limiting factor at gigabit. It also writes its reporting database continuously — use a real SSD, not a USB stick or low-endurance flash, or you’ll wear the disk out and the dashboard will crawl.

Install the plugin

Zenarmor is distributed as a vendor plugin. Two steps:

1. System → Firmware → Plugins → install os-sensei (the package name still reflects the old “Sensei” branding).
2. After install, a Zenarmor entry appears in the left menu. Open it and run the in-product installer/onboarding — it pulls the engine packages and, on first run, asks which reporting database to use.

For the reporting backend you choose between the bundled lightweight database (fine for a single home box) and an external Elasticsearch instance (for larger deployments or long retention). For a homelab, take the local database.

Pick the deployment mode and interface

Zenarmor inspects a chosen interface. The two questions mirror any inline inspection tool:

• Which interface. On LAN you see real internal client IPs, which makes the “who did this” reporting actually useful for attribution. On WAN you see post-NAT traffic. Most homelabs run it on LAN.
• Routed vs bridge mode. Routed mode is the normal OPNsense deployment and what you want unless you have a specific transparent-bridge requirement.

Start in monitoring/report-only behaviour: let it classify and log for a few days before you start blocking. This is the same staged-rollout discipline that keeps Suricata IDS/IPS from blocking something legitimate on day one.

Build the policy

Zenarmor → Policies. In the Free edition you edit the Default policy; that policy applies to all inspected traffic. Inside it you control:

• Application controls — block by app or app group (e.g., block BitTorrent, anonymizers/VPNs, or specific social apps).
• Web categories — block by category (adult, gambling, malware, phishing, etc.). This is category-based URL filtering across a large category set.
• Security controls — block known-malicious destinations using Zenarmor’s threat feeds.

Enable the security/malware categories first — those are the low-risk, high-value blocks. Treat broad category blocking (e.g., “streaming media”) as a deliberate policy decision, not a default, because it generates the most user complaints.

A note on HTTPS and TLS

Almost all traffic is encrypted. Without TLS inspection, Zenarmor classifies HTTPS flows using SNI (the server name in the TLS handshake), IP reputation, and behavioural signals — which is enough to identify most applications and apply category filtering by hostname. It cannot see inside the encrypted payload. Full TLS inspection (decrypt-inspect-re-encrypt) is a Business-edition feature and brings its own certificate-distribution and privacy considerations. For a home network, SNI/behavioural classification is usually sufficient; don’t assume you need decryption.

Verify it’s actually classifying

Confirm the engine is live before you trust the dashboard:

1. Engine status — the Zenarmor page shows the engine as running with a packet/flow counter that increments as you browse.
2. Live sessions — generate traffic from a LAN client (open a few sites, a video) and watch the Live Sessions / dashboard populate with classified apps and the originating client IP.
3. A block fires — once you’ve enabled a category block, browse to a site in that category from a test client and confirm it’s blocked and logged.

Tuning and when to back off

Two failure modes dominate. Memory pressure: if OPNsense starts swapping or the dashboard lags, you’re under-provisioned — reduce what you inspect (LAN only, not LAN+WAN), or add RAM. Over-blocking: an aggressive category or an app-group block that catches a dependency (CDNs, telemetry an app needs) makes things “randomly break.” The reporting view is your triage tool — find the blocked flow, identify the app/domain, and exempt it.

If your real need is signature-based intrusion detection (exploit attempts, C2 patterns), Zenarmor is not a replacement for Suricata — they solve different problems and many homelabs run both, CPU budget permitting. And if you only want DNS-based ad/tracker blocking, a lighter Unbound blocklist or AdGuard Home plugin is far cheaper than running a full classification engine. Reach for Zenarmor when you specifically want application visibility and category control with a real-time dashboard.

When Zenarmor is the wrong tool

On underpowered hardware Zenarmor will degrade routing performance for the whole network — if you can’t give it RAM and a quad-core, skip it. If you need different policies per network segment, budget for the Home edition rather than fighting the single-policy limit. And if your environment is heavy on encrypted DNS (DoH) you can’t control, hostname-based category filtering will be porous; pair it with a DNS chokepoint policy.

Comparing platforms? FirewallCompare ↗ looks at OPNsense’s Zenarmor against the pfSense ↗ approach to application filtering. See the official Zenarmor docs for OPNsense ↗ for the authoritative install reference.