OPNsense Hardware Requirements: CPU, RAM & Storage

OPNsense needs a 64-bit x86 (amd64) processor. The official minimum is a 1 GHz dual-core CPU, 3 GB RAM and a 4 GB flash card, enough for everything except disk-writing features. Every feature needs 4 GB RAM and a 40 GB SSD; the recommended build is a 1.5 GHz multi-core CPU, 8 GB RAM and a 120 GB SSD.

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.

Official OPNsense hardware requirements

The official documentation answer is the manual’s Hardware sizing & setup page, and it publishes four levels rather than one minimum. They are worth reading as descriptions of feature availability, not just as numbers.

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.

x86-64 only, and the ARM question

OPNsense is published for x86-64 (amd64) only. The documentation states this plainly under supported hardware architectures, and 32-bit x86 machines are out of scope as well. That settles a question that comes up constantly: the project ships no image for a Raspberry Pi 4, a Pi 5 or any other ARM single-board computer, so on the official release path there is nothing to boot, not merely something slow.

An unofficial path does exist. The community opnsense-tools fork by yrzr builds aarch64 images for the Raspberry Pi 3B, 3B+ and 4B and NanoPi boards, and its author’s release notes call them “NOT official releases”, to be used at your own risk. The maurice-w/opnsense-vm-images fork builds aarch64 virtual machine images for the 26.7 series. Neither is part of the project’s own release process.

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 real decision is whether a community build is acceptable on the device guarding the network, or 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 sizing page links the FreeBSD 14.1 hardware notes, but the current 26.7 series, released July 15, 2026 with 26.7.4 out on September 15, is built on FreeBSD 15.1-RELEASE, so the FreeBSD 15.1 hardware notes are the list to check.

The throughput table, and how to read it

The same page maps throughput bands onto those tiers:

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.

ZFS ARC memory

The installer offers UFS or ZFS, and the installation guide calls ZFS “in most cases the best option” for reliability. ZFS also brings the ARC, an in-memory read cache that by default may grow to half of physical memory; a core issue opened in March 2026 asked for a 10% ceiling instead and was closed as not planned. On an 8 GB box that is up to 4 GB reported as ARC. It is cache, not a leak, but on a 4 GB machine that also runs Suricata it is the first thing worth capping.

The cap is a tunable under System > Settings > Tunables, with the value in bytes. A forum thread from September 2025 reported that vfs.zfs.arc.max did nothing on a 16 GB machine, while the older underscore name vfs.zfs.arc_max set to 8589934592 (8 GB) worked. Reboot, then confirm the ARC figure rather than assuming the tunable took. UFS installs have no ARC to manage.

Storage and disk size

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 installation guide supplies the flash and swap floor figures, and the Hardware sizing & setup page supplies the SSD tiers, which together translate into four practical sizes:

• 4 GB flash: the nano image targets USB drives, SD or CF cards of at least 4 GB and “stores logging and cache data in memory only”, which spares low-endurance media.
• 16 GB or more: the installer’s swap prompt is “usually fine” to accept unless the target is smaller than 16 GB, and ZFS needs “a couple of gigabytes at least”.
• 40 GB SSD: the reasonable tier, every standard feature.
• 120 GB SSD: the recommended tier, with room for IDS alerts, proxy cache and long log retention.

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.

Intrusion prevention adds a stricter test. The IPS documentation explains that IPS mode runs Suricata over netmap, needs real interfaces that support it, and requires every hardware offloading option under Interfaces > Settings to be disabled. The FreeBSD 15.1 netmap(4) manual lists native support in cxgbe, em, igb (through iflib), ix, ixl, re and vtnet; other cards run in an emulated mode the manual describes as inferior to native.

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, such as a hub terminating multiple WireGuard site-to-site tunnels.

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.

OPNsense firewall hardware: what Deciso’s appliances show

Deciso, the company that develops OPNsense, sells its own appliances, and their spec sheets are the most direct vendor data on how the software scales across hardware. List prices on shop.opnsense.com, checked September 2026:

The DEC677 and DEC697 isolate the variable the documentation’s tiers are about. Same CPU, same ports, same 5 Gbps firewall rating; €80 more buys 8 GB of RAM instead of 4 GB and a 256 GB NVMe drive instead of 32 GB of flash. Deciso says the cheaper unit is “not intended for applications that demand disk writes such as a web proxy, intrusion detection or local net flow recording”, and rates it at 3 million concurrent sessions against 7 million. That is the sizing page’s minimum-versus-reasonable line, drawn by the vendor on its own hardware.

The other lesson is the IPS column. The DEC750 moves 8.5 Gbps as a firewall and about 1 Gbps with intrusion prevention, roughly an eighth. Anyone planning gigabit with Suricata inline should size against the IPS figure, not the headline one.

Checking a mini PC or used desktop

For a self-built box, four checks cover the requirements above:

1. Confirm a 64-bit x86 CPU; ARM boards and 32-bit machines fall outside the official images.
2. Fit 8 GB of RAM if Suricata or a ZFS install is planned; 4 GB covers every feature at light load.
3. Use an SSD of at least 40 GB, or 120 GB with IDS, a proxy cache or long log retention.
4. Look up each NIC’s driver in the FreeBSD 15.1 hardware notes: igc(4) covers Intel’s I225 and I226 2.5 GbE controllers, re(4) the Realtek RTL8111 and RTL8168. For IPS mode, check the netmap list above as well.

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. For inline IPS in a guest, note that VirtIO’s vtnet driver is on the native netmap list.

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.

FAQ

how much ram does opnsense need?

OPNsense needs 3 GB of RAM to run the installer and the reduced minimum tier, 4 GB to run every standard feature, and 8 GB for the recommended build. Add roughly 1 MB per 1,000 firewall states, plus headroom for Suricata rules and, on ZFS installs, an ARC cache that can grow toward half of RAM.

how much disk space does opnsense need?

Plan on a 40 GB SSD for a full install that runs every feature, or 120 GB for the recommended build. The absolute floor is 4 GB for the nano image, which runs from USB, SD or CF media and keeps logs in RAM; a full install accepts the installer’s swap default from 16 GB up.

what cpu does opnsense need for gigabit?

For plain routing and NAT, a modest quad-core is enough: Deciso rates its 1.8 GHz AMD G-Series DEC697 at 5 Gbps firewall throughput. Intrusion prevention is what demands more; the same box manages about 541 Mbps with IPS, while the 2.2 GHz Ryzen Embedded DEC750 reaches about 1 Gbps.

where are the official opnsense hardware requirements?

The official figures are on the Hardware sizing & setup page of the OPNsense manual, docs.opnsense.org/manual/hardware.html. It lists minimum, reasonable and recommended specifications, a table mapping throughput to those tiers and the 1 kB-per-state memory rule. Its compatibility link still points at FreeBSD 14.1, while OPNsense 26.7 runs on FreeBSD 15.1.