Alright, let's get this out of the way: OPNsense isn't magic. You've taken some old desktop hardware or a retired SFF PC, slapped a few Intel NICs in it, installed OPNsense expecting pfSense-like "runs on anything" performance, and now you're staring at 30% CPU utilization just moving packets across VLANs at gigabit speeds. Sound familiar?
It's not that OPNsense is inherently slower, but its defaults and some of its "modern" conveniences are tuned for hardware that's at least from this decade. The kernel's different, the base is different, and a lot of the assumed work is now done in userspace where pfSense might have let the kernel handle it directly. You're paying for a prettier UI and a more structured plugin system with a few extra CPU cycles.
If you're running this on something like an old Core i5-3470 or even a j1900 board, you need to strip it back to the studs. Here's where I'd start, in order of likely impact:
* **Disable Hardware Crypto Offload where it's fake:** This is the biggest culprit on older chips. Go to `System > Settings > Advanced`. In the `Networking` tab, uncheck `Hardware Crypto`. Your AES-NI-less CPU is trying and failing to offload, creating more overhead. Let the kernel handle it in software; it's often faster on legacy silicon.
* **Tune the network stack:** SSH in and drop these into `/boot/loader.conf.local`. This isn't BSD of 2005 anymore.
```bash
# Increase network buffers for gigabit+ traffic
kern.ipc.nmbclusters="1000000"
kern.ipc.nmbjumboclusters="1000000"
# Tweak TCP for modern, high-speed links
net.inet.tcp.tso="0"
net.inet.tcp.rfc1323="1"
net.inet.tcp.sendbuf_max="2097152"
net.inet.tcp.recvbuf_max="2097152"
```
Reboot after. This alone can cut CPU usage on busy flows by a noticeable margin.
* **Murder the flowd inspector:** If you're *not* using Zenarmor or the deep packet inspection in the Sensei plugin, disable the built-in Netflow exporter. `System > Settings > Tunables`. Add a new tunable:
- **Tunable:** `net.graph.auto_cleanup`
- **Value:** `1`
- **Description:** `Disable flowd graph auto-init`
This stops the system from setting up flow tracking for every packet, which is a silent resource hog.
* **Audit your plugins:** Every plugin is another daemon, another web UI component, another thing polling. Do you *need* the Telegram notifier, the Mailwatch integration, the fancy dynamic DNS updater that checks every 30 seconds? Strip it out. Run the bare minimum. Monitor your RAM usage—if you're swapping on a 4GB box, you've already lost.
The bottom line is that OPNsense assumes a bit more overhead for its architecture. It's a trade-off. On modern 4+ core Celerons with AES-NI, you won't notice. On that old Xeon you pulled from a Dell R710, you absolutely will. Tune it like you'd tune a database server: disable anything you aren't actively using, adjust kernel parameters for your workload, and for heaven's sake, use an SSD. A spinning disk will make the web configurator feel like it's running on wet paper.
What's your hardware spec, and what's chewing up cycles? `top -aSH` and `netstat -Q` are your friends here. Let's see the actual numbers.
-- old salt
You're absolutely right about the hardware crypto offload. On older Intel chips without AES-NI, that checkbox is often a trap. The system attempts the handoff, fails, and falls back to software in a way that adds more overhead than just doing it in software from the start. I'd add that you should also check the specific cryptographic protocols in use on your VPN or inspection settings, as some are more CPU-intensive than others when done in software.
The shift to more userspace processing is a key difference from pfSense that doesn't get mentioned enough. It provides flexibility and security isolation, but the context switches add up, especially on older CPUs with smaller caches. The performance cost of the structured plugin system is real, even if you're not running many plugins, because the framework itself is always there.
One more thing to check on old hardware is power management. You want it set to "Maximum" or "Hiadaptive" in the system tunables to keep the CPU from constantly ramping down under what it misinterprets as low network load. An old desktop CPU dropping to 800 MHz will murder throughput.
Data > opinions