OPNsense Hardware Requirements: How to Size a Box

Most people asking what hardware an OPNsense router needs are really asking two separate questions at once: what will the software refuse to run on, and what will be fast enough for the connection in front of it. The project answers the first question narrowly and the second one with tiers rather than a single number, and the gap between those two answers is where nearly all bad purchases happen.

The architecture question comes first

OPNsense is published for x86-64 (amd64) only. The documentation states this plainly under supported hardware architectures, and it settles a question that comes up constantly: a Raspberry Pi 4, a Pi 5, or any other ARM single-board computer cannot run it. There is no ARM image to install, so the answer is not “it will be slow” but “there is nothing to boot”. The same applies to 32-bit x86 machines, which are also out of scope.

That constraint is worth stating early because it removes an entire class of cheap hardware from consideration. If a low-power ARM board is the fixed requirement, the decision is not which OPNsense build to use, it is which platform to use instead.

Beyond the instruction set, OPNsense inherits FreeBSD’s hardware support wholesale. The documentation is explicit that all FreeBSD drivers are included in the OPNsense kernel and compatibility is therefore identical to FreeBSD’s. That single sentence is the most useful hardware-compatibility rule available: if the FreeBSD hardware compatibility list covers a network card, OPNsense covers it, and if it does not, no amount of configuration in the web interface will change that.

The official specification tiers

The project publishes four levels rather than one minimum. They are worth reading as descriptions of feature availability, not just as numbers.

Tier	CPU	RAM	Install target	What it covers
Basic	-	-	-	Substantially narrowed functionality; no CPU, RAM or disk figures are published for it
Minimum	1 GHz dual-core	3 GB	SD or CF card, 4 GB minimum, nano image	All standard features except those needing disk writes
Reasonable	1 GHz dual-core	4 GB	40 GB SSD	Every feature functional, but not at high load or user count
Recommended	1.5 GHz multi-core	8 GB	120 GB SSD	Every feature functional, fits most use cases

The important detail is buried in the minimum tier: it excludes anything that writes to disk. A caching proxy needs a cache, and intrusion detection needs somewhere to store its alert database. Installing to a 4 GB card and then enabling Suricata is a configuration that the sizing table already told you would not work.

The documentation also notes that a minimum of 3 GB of memory is needed for the installer itself to run, which occasionally surprises people trying to revive very old hardware with 2 GB fitted.

The throughput table, and how to read it

The same page maps throughput bands onto those tiers:

Throughput	Tier	Feature set	Users / networks
11-150 Mbps	Basic or Minimum	narrowed or reduced	10-30
151-350 Mbps	Reasonable	all	30-50
350-750+ Mbps	Recommended	all	50-150+

Read at face value these numbers look far too conservative for anyone with a gigabit connection, and that is the single most misread table in OPNsense sizing. It is not a measurement of how fast the packet filter can forward traffic on modern silicon. It is a guidance table that combines throughput with feature set and user count, and its ceiling is set by the expensive features, not by plain routing and NAT. A recent quad-core desktop CPU doing stateful NAT with a modest ruleset is not the case this table is describing.

The practical reading is: pick the tier that matches the features you intend to enable and the number of people behind the box, then treat raw forwarding capacity as a separate question driven by single-thread CPU performance and network interface quality.

RAM: base, plus states, plus inspection

Memory is the one dimension where OPNsense gives an arithmetic rule instead of a tier. The documentation states that each state table entry requires roughly 1 kB of RAM, so a state table holding 1,000 connections occupies about 1 MB.

That scales in a way that is easy to underestimate. A household of a few dozen devices, several of them making many short-lived connections, can sit in the low tens of thousands of states without anything unusual happening. Half a million states, a figure that is routine on a busy network or under any kind of scanning activity, is roughly 500 MB before the operating system, the web interface, or any service has been accounted for.

Intrusion detection is the other large consumer. Suricata holds its enabled rule set in memory along with flow and stream tracking state, and the size of that footprint is a direct function of how many rule categories are switched on. Enabling everything on a 4 GB box is a reliable way to produce an out-of-memory condition on a device whose entire job is to stay up.

Because that calculation is tedious to do by hand, this site publishes an interactive state table and bandwidth sizer that takes a target state count, an intrusion detection tier and a WAN speed and returns a memory and core figure. It is a planning aid built on the same 1 kB-per-state figure the documentation gives, not a measurement of a specific machine.

Storage

Disk sizing follows from what writes to it. A plain routing and firewalling installation writes very little: configuration changes, logs, and updates. Add a caching proxy, add intrusion detection alerts, add long log retention, and the write volume changes character entirely.

The 40 GB SSD in the reasonable tier and the 120 GB SSD in the recommended tier reflect that. Spinning disks are supported, and so are SD and CF cards through the nano images, but flash cards have finite write endurance and the features that need disk are exactly the features that will consume it. An inexpensive SSD is the low-drama choice.

Network interfaces

The documentation’s advice on network cards is unusually direct: it points at the FreeBSD hardware lists and recommendations and states that Intel chipset network cards deliver higher throughput at reduced CPU load. This is the reason experienced builders keep repeating the same advice about NIC chipsets, and it is not brand loyalty. Driver maturity on FreeBSD is uneven, and the failure mode of a poorly supported card is not a clean refusal but intermittent throughput collapse, watchdog resets, or offload bugs that look like an application problem three layers up.

Port count is a separate decision from chipset. A router needs one WAN-facing interface and one LAN-facing interface at minimum, but VLANs let a single physical port carry many logical networks, so a two-port box plus a managed switch covers a surprising number of designs. Adding physical ports is worth it when segments need physical separation, when a second WAN is planned, or when a link needs a dedicated path.

CPU: clock speed, cores, and crypto

Two properties matter more than core count for a router.

The first is single-thread performance. A single TCP flow is generally handled on one queue, so the ceiling on a single large transfer tracks single-core speed rather than total core count. Many cores help with many simultaneous flows, with intrusion detection, and with several VPN tunnels at once.

The second is cryptographic acceleration, and here the choice of VPN protocol changes the answer. IPsec and OpenVPN commonly negotiate AES-based ciphers, which benefit directly from the AES-NI instructions present in most modern x86 CPUs. WireGuard does not negotiate anything: its cryptography is fixed, and its data channel uses ChaCha20-Poly1305 rather than AES. That is a deliberate design choice in the protocol, and its practical consequence for hardware buying is that AES-NI does not accelerate WireGuard traffic the way it accelerates an AES-GCM IPsec tunnel. Clock speed carries more of the load instead. The tradeoffs between the three protocols are covered in OPNsense VPN: WireGuard vs OpenVPN vs IPsec.

Virtual machines

Running OPNsense as a guest is supported and common. The sizing rules do not change, but two additional considerations appear. Interface handling becomes a hypervisor question: paravirtualised adapters, passed-through physical cards, and bridged software switches all behave differently under load, and passing a physical Intel card through to the guest removes an entire layer of uncertainty. And the availability of the whole network now depends on the availability of the host, which matters if the same host also runs the storage that the host boots from.

Where sizing goes wrong

The recurring mistakes are consistent enough to list.

Buying for the connection speed alone and then enabling inspection, proxying and logging, all of which the throughput table already warned would move the requirement up a tier. Fitting the minimum RAM and then turning on features the minimum tier explicitly excludes. Choosing a network card by port count and price without checking the chipset against FreeBSD’s list. Installing to a small flash card and then wondering why an alert database will not fit. And sizing for today’s state count with no headroom, so that the first burst of scanning traffic fills the table.

The opposite error is real but cheaper: a large server as a home router works fine and simply costs more in power than a small fanless box would.

Once the hardware is chosen

The next decisions are configuration, not purchasing. Start with how OPNsense firewall rules, NAT and interfaces actually work, because the interface and rule model determines how the ports on the box you just bought get used. If a VPN is part of the plan, the protocol choice above changes the CPU calculation, and if a WireGuard tunnel refuses to come up once the box is built, OPNsense WireGuard not connecting works through the causes in order of frequency.