The short answer to how much RAM for OPNsense firewall hardware is 8 GB. That is OPNsense’s own recommended specification, with room for NAT, Unbound, WireGuard, a ZFS install and one heavy service such as Suricata or Zenarmor. 4 GB still runs a plain router. Buy 16 GB only when Zenarmor’s local reporting and Suricata share one box, or past 250 devices.
RAM does not track WAN speed. It tracks what you switch on: inspection engines, reporting databases, alias tables and the filesystem cache. “Just get 16 GB” is a habit, not a sizing method, and each of those consumers has a documented cost. If the hardware is not chosen yet, the Intel N100 firewall build guide covers NICs and storage alongside memory.
How much RAM does OPNsense officially require?
Three tiers: 3 GB minimum, 4 GB “reasonable” and 8 GB recommended. OPNsense’s hardware sizing page adds that the installer itself needs at least 3 GB of memory, which rules out 2 GB boards even for a bare install.
| Tier | CPU | RAM | Storage | Throughput band | Users | Features |
|---|---|---|---|---|---|---|
| Minimum | 1 GHz dual-core | 3 GB | 4 GB SD/CF, nano image | 11–150 Mbps | 10–30 | Reduced |
| Reasonable | 1 GHz dual-core | 4 GB | 40 GB SSD | 151–350 Mbps | 30–50 | All |
| Recommended | 1.5 GHz multi-core | 8 GB | 120 GB SSD | 350–750+ Mbps | 50–150+ | All |
Treat the throughput column as a proxy for how busy the network is, not a memory formula. The same page gives the real per-connection cost: about 1 kB of RAM per state-table entry, so 1,000 states occupy about 1 MB. The minimum row assumes the nano image with logs in RAM, an embedded profile rather than a new build.
What actually uses RAM on an OPNsense firewall?
Five consumers matter: the pf state table, alias and blocklist tables, the inspection engine, Zenarmor’s reporting database and the ZFS ARC. Unbound and the base system are small beside them; Unbound’s upstream defaults are a 4 MB message cache and a 4 MB RRset cache, per unbound.conf(5). Several figures below come from Netgate’s pfSense documentation, which describes the same FreeBSD pf and ZFS stack.
| Consumer | Documented figure |
|---|---|
| pf state table | About 1 kB per state; 100,000 states is about 100 MB |
| Alias and blocklist tables | About 1 kB per entry, conservatively; must fit twice during a reload |
| Suricata or Snort | 1 GB minimum; 2 GB or more for some configurations, before OS and states |
| Zenarmor engine | 1 GB minimum |
| Zenarmor plus local Elasticsearch | At least 8 GB of system RAM |
| ZFS ARC, automatic maximum | Half of RAM or RAM minus 1 GB, whichever is greater |
States are cheap. Netgate’s hardware sizing guidance uses the same 1 kB figure and puts 100,000 states at roughly 100 MB, a rounding error on 8 GB. OPNsense shows its default for Firewall Maximum States in that setting’s help text, per its firewall settings documentation.
Tables are where blocklists bite. Netgate’s notes on firewall maximum table entries warn that alias data must fit twice over during a reload, because the new list loads before the old one is dropped. pfSense defaults to a 400,000-entry ceiling; at 1 kB each, that is about 400 MB, or 800 MB mid-reload. Stacked GeoIP country aliases and IP blocklists are how a home ruleset grows toward it. OPNsense exposes the same limit as Firewall Maximum Table Entries and suggests raising it “when using a lot of large aliases.”
Inspection is the big step. Netgate budgets 1 GB minimum for Snort or Suricata, and 2 GB or more for some configurations, “not counting RAM used by the operating system, firewall states, and other packages.” OPNsense’s IPS is Suricata running inline over netmap, per the OPNsense IDS/IPS manual, so plan with Netgate’s number and expect it to move with every rule category you enable.
Zenarmor scales with devices and with its database. The Zenarmor hardware requirements set minimum memory by active device count:
| Active devices | Max WAN bandwidth | Minimum RAM |
|---|---|---|
| 0–50 | 300 Mbps | 1 GB |
| 50–100 | 500 Mbps | 4 GB |
| 100–250 | 1 Gbps | 8 GB |
| 250–1,000 | 1–2 Gbps | 16 GB |
| 1,000–2,000 | 1–2 Gbps | 32 GB |
The footnote outweighs the table: Zenarmor says you need at least 8 GB of RAM to run Elasticsearch alongside it. A 30-device household sits on the 1 GB row, but with local Elasticsearch reporting it is an 8 GB box. Offloading the reporting database to an external system is the documented route on low-memory hardware.
Why does OPNsense show so much memory in use on ZFS?
Because the ZFS ARC, the in-RAM read cache, is allowed to grow large by default. Netgate’s ZFS tuning page gives the automatic maximum as half of RAM or total RAM minus 1 GB, whichever is greater: 7 GB on an 8 GB firewall. A high dashboard percentage on a ZFS install is usually cache, not a leak.
The FreeBSD Handbook documents vfs.zfs.arc.max as the ARC’s upper bound, where the default of 0 lets ZFS size it from installed memory. A firewall gets little from a large read cache, which is Netgate’s argument for tuning it down; its conservative advice on low-RAM systems is a cap of 25% of total RAM or less. Add it under System ‣ Settings ‣ Tunables, in bytes:
| Installed RAM | 25% cap | vfs.zfs.arc.max value |
|---|---|---|
| 4 GB | 1 GB | 1073741824 |
| 8 GB | 2 GB | 2147483648 |
Reboot so the cache starts under the new ceiling. Cap it on 4 GB hardware, or on 8 GB when Zenarmor’s Elasticsearch runs locally; on 16 GB, leave the default. Do not dodge ARC pressure by reinstalling on UFS. The OPNsense install and first-boot guide explains why ZFS boot environments are worth keeping.
4 GB, 8 GB or 16 GB: which should you buy?
Buy 8 GB unless your plan clearly matches the 4 GB or 16 GB rows below. Each row follows from the documented figures above.
| Profile | What runs on it | Buy |
|---|---|---|
| Plain router | NAT, Unbound, WireGuard, 2–4 VLANs, no inspection | 4 GB works; 8 GB if buying new |
| Typical home firewall | The above plus ZFS, IP blocklists, and Suricata or Zenarmor for up to 250 devices | 8 GB |
| Everything on one box | Zenarmor with local Elasticsearch plus Suricata, large GeoIP and blocklist tables | 16 GB |
| Small office | 250 to 1,000 devices under Zenarmor | 16 GB |
| Larger site | 1,000 or more devices under Zenarmor | 32 GB, so not an N100 |
On an N100, 16 GB is also the ceiling. Intel’s N100 specification lists a 16 GB maximum on a single memory channel, DDR4-3200, DDR5-4800 or LPDDR5-4800, with no ECC support. With one channel, a single module is the normal configuration, not a compromise. Check whether a box uses a SO-DIMM slot or soldered memory before ordering; the fanless N100 mini PC picks cover what to confirm with the vendor.
None of the OPNsense, Netgate or Zenarmor sizing tables specifies memory speed, so buy capacity, not MT/s. RAM also adds no packet-processing cores; Suricata throughput on four N100 cores is a CPU question, covered in OPNsense vs pfSense on an N100. If the plan needs 16 GB and heavy inspection at once, check the N100 vs N305 vs N5105 comparison first.
How do you check whether OPNsense needs more RAM?
Check swap, ARC size and state count from a shell, either console option 8 or SSH. If swap is near zero and the ARC still has room to shrink, the box does not need more memory, whatever the dashboard percentage says.
# Memory summary; ZFS installs show an ARC line
top -b -o res | head -n 20
# Current ARC size and configured cap, in bytes
sysctl kstat.zfs.misc.arcstats.size vfs.zfs.arc.max
# Swap in use
swapinfo -h
# Current pf states, then limits for states, frags and table entries
pfctl -si | grep -i entries
pfctl -sm
# Processes killed for lack of memory
dmesg | grep -i "out of swap"- Swap filling, ARC large: cap
vfs.zfs.arc.max. Netgate calls a little swap beside a big ARC normal, but high or nearly full swap means real contention. - Swap filling, ARC already small: add RAM, or move Zenarmor’s reporting database off the box.
- States near the
pfctl -smlimit: raise Firewall Maximum States and budget about 1 kB per extra state. - Any “out of swap” kill: the killed service needs memory it did not get; size up before re-enabling it.
Run the set once before enabling Suricata or Zenarmor and again after, with normal traffic flowing. The difference is what inspection costs on your ruleset, which no sizing table can tell you.
FAQ
Is 4 GB of RAM enough for OPNsense?
Yes, for a plain router. OPNsense lists 4 GB as its reasonable tier, which supports the full feature set at moderate load. It gets tight once Suricata, local Zenarmor reporting or an uncapped ZFS ARC joins in, so on 4 GB hardware set vfs.zfs.arc.max to 1 GB, enable the swap file and keep inspection rule categories lean.
Does OPNsense need ECC RAM?
No. None of OPNsense’s hardware tiers calls for ECC memory, and Intel’s specification lists the N100 without ECC support, so the question does not arise on these boxes. A firewall’s configuration is one XML file you can back up, and its state table starts empty after every reboot, which makes ECC a lower priority than on a storage server.
Should I enable swap on OPNsense?
Enable it on 4 GB hardware and treat it as a safety net elsewhere. OPNsense’s Miscellaneous settings can create a 2 GB swap file, which the documentation says can increase performance at the cost of storage wear, especially on flash. A little swap use beside a large ZFS ARC is normal; swap that keeps filling means cap the ARC or add RAM.
How much RAM should an OPNsense VM get?
Size an OPNsense VM like bare metal: 4 GB for routing and VPN, 8 GB once Suricata or Zenarmor runs, and never less than the 3 GB the installer needs. Use a fixed allocation rather than ballooning, and cap the ZFS ARC inside the guest, since a firewall gains little from a large read cache.
Related across the network
- OPNsense Hardware Requirements: CPU, RAM & Storage — opnsenserouter.com
- pfSense Requirements: Minimum & Recommended Hardware — pfsenselab.com
