pfSense Hardware Requirements: Minimum vs Realistic

The published minimum for pfSense software is small enough to be misleading. Netgate lists a 64-bit amd64 CPU, 1 GB or more of RAM, an 8 GB or larger disk, one or more compatible network interface cards, and bootable installation media. That is the floor for getting the installer to finish, and the same documentation page immediately warns that the minimums “are not suitable for all environments”.

The gap between that floor and a build that holds up under load is not a matter of taste. Netgate’s own sizing figures make it arithmetic. This is what the numbers say.

The minimum is an install requirement, not a run requirement

Read the minimum list carefully and notice what it does not mention: no core count, no clock speed, no cryptographic instruction set, no network throughput figure. That is deliberate. The install requirement describes what the operating system needs to boot and write itself to disk. Everything that determines whether the firewall keeps up with your traffic is downstream of it.

Two consequences follow. First, a machine that meets the minimum can genuinely serve a small network doing plain routing and NAT. Second, the same machine will fall over the moment you enable the features most people install pfSense for. The published minimum is honest; it is just answering a different question than the one buyers are asking.

RAM: the state table sets the real floor

Every active connection through the firewall consumes two entries in the packet filter state table, one entering and one leaving. A firewall handling 100,000 simultaneous client connections therefore needs room for 200,000 states.

Netgate puts each state at roughly 1 KB of RAM and publishes the resulting table:

States	Connections	RAM required
100,000	50,000	~97 MB
500,000	250,000	~488 MB
1,000,000	500,000	~976 MB
3,000,000	1,500,000	~2900 MB
8,000,000	4,000,000	~7800 MB

The documentation’s own shorthand is that 100,000 states cost about 100 MB, so a million states cost about 1 GB. On top of that, the operating system and its services want at least 175 to 256 MB, and more once features are enabled.

Put those two figures side by side with the published 1 GB minimum. A one-million-state table alone would consume the entire minimum specification with nothing left for the system that maintains it. The floor is not wrong, it simply assumes a state table small enough that nobody bothered to mention it.

Network memory buffers add a second, less visible cost. The common fix for mbuf exhaustion on commodity hardware is raising the kern.ipc.nmbclusters loader tunable to one million, and Netgate notes that a fully allocated pool at that setting occupies roughly 2.3 GB of physical memory. That allocation appears in no minimum-requirements list anywhere, and on a 2 GB machine it is not available at all.

Inspection is the largest single multiplier

Netgate singles out packages that intercept or inspect traffic, naming Snort and Suricata, as the features most likely to reduce total throughput because they consume hardware resources that would otherwise move packets.

The cost is paid in two currencies. The rule set and the per-flow inspection state live in RAM, and the amount scales with how many rule categories are enabled and how many interfaces are inspected. Netgate’s own floor for either engine is 1 GB, and that is a floor rather than a working figure: it is the engine’s allocation alone, on top of the state table, the network buffers and the operating system. The inspection work itself is CPU time taken away from forwarding. Enabling every available category on every interface is the fastest way to turn a comfortable machine into one that swaps, drops packets, or kills processes under memory pressure.

If intrusion detection is part of the plan, it belongs in the sizing calculation from the start rather than as something to switch on later. Sizing pfSense hardware around what actually limits throughput covers which component each workload actually stresses.

Throughput is packets, not bits

The single most useful correction to a hardware shortlist is to stop thinking in megabits. Forwarding cost is per packet, so the same hardware moving the same number of packets per second delivers wildly different headline bandwidth depending on frame size. Netgate publishes the conversion at an example rate of 500,000 packets per second:

Frame size	Throughput at 500 Kpps
64 bytes	244 Mbps
500 bytes	1.87 Gbps
1000 bytes	3.73 Gbps
1500 bytes	5.59 Gbps

The same box is a 244 Mbps firewall or a 5.59 Gbps firewall depending entirely on what is crossing it. This is why vendor throughput claims quote both a maximum-frame figure and an IMIX figure, IMIX being an approximation of mixed real-world traffic built from sets of seven 40-byte packets, four 576-byte packets and one 1500-byte packet plus framing overhead.

A network dominated by bulk file transfer sits near the bottom of that table. A network full of small interactive packets, VoIP, gaming, DNS, or a busy VPN concentrator, sits near the top of the per-packet cost and nowhere near the top of the bandwidth column.

The network card matters more than the clock speed

Netgate is unusually direct about this: inexpensive low-end cards consume significantly more CPU than better-quality cards, the first bottleneck in firewall throughput is the CPU, and throughput improves significantly by pairing a better-quality NIC with a slower CPU. The inverse does not hold. Increasing CPU speed does not proportionally increase throughput when the card is poor.

That is a spending instruction, and it points the opposite way from most build lists. Between a faster processor and better network interfaces at the same budget, the interfaces win. Mature server-class drivers also avoid a long tail of documented card-specific problems: interrupt handling that behaves badly enough that Netgate documents disabling MSI-X as a diagnostic, offload features that need turning off, and multi-queue hashing that fails outright on PPPoE links.

Storage: 8 GB installs, 8 GB does not last

The 8 GB minimum disk is real, and it is also the specification most likely to cause trouble a year later. A running firewall writes continuously: system logs, traffic and status graphs, package data, and DNS resolver state. Package installation and version upgrades need working space on top of the installed footprint. Recent installations default to ZFS, which is worth having for its integrity checking and boot environments but is not free in RAM or in space.

Two practical implications. Size the disk so that logs and upgrades are never the constraint, and choose flash rated for sustained writes rather than the cheapest available, because continuous logging is exactly the workload that ends low-endurance media. Keep an exported configuration backup somewhere other than the firewall; restoring a configuration onto replacement hardware is a short job, and reconstructing one from memory is not.

Cryptographic acceleration is absent from the minimum list on purpose

The minimum requirements do not mention AES-NI or any other cryptographic instruction set, and pfSense installs and runs without one. That is a different question from whether a VPN will perform.

Netgate’s sizing guidance is explicit that encrypting and decrypting traffic is CPU intensive for every VPN type, that maximum throughput depends on the cipher chosen and whether the hardware can accelerate it, and that hardware cryptographic accelerators largely eliminate the performance difference between accelerated ciphers. For IPsec, AES-GCM is accelerated by AES-NI, and IPsec is additionally faster than OpenVPN because it avoids a separate authentication algorithm and carries less per-packet operating system overhead.

So the rule is: cryptographic acceleration is optional to install and close to mandatory to buy if a VPN is on the requirements list at all.

A realistic specification by role

None of the following is a benchmark. Each row is what the figures above imply once you commit to a workload.

Role	RAM	Storage	Notes
Published minimum	1 GB	8 GB	Installs and routes; no inspection, small state table
Gigabit routing and NAT, no inspection	4 GB	32 GB+ SSD	Room for a large state table plus mbuf headroom
Gigabit with Snort or Suricata	8 GB	64 GB+ SSD	Rule set and per-flow inspection state in RAM
Multi-gigabit with VPN and inspection	16 GB+	120 GB+ SSD	Cryptographic acceleration required, server-class NICs

The column that is not in the table is the network interface, because it is not a quantity. Choose interfaces with mature drivers first, then size RAM against the state table you expect, then buy CPU last.

Check your own numbers

Your state count, inspection footprint and VPN load are specific to your network, and the tables above are the inputs rather than the answer. The pfSense appliance sizer applies the same state-table and inspection figures to your own state count, WAN speed and inspection level.

Two follow-ups are worth reading before ordering anything. If you are still choosing between editions, note that both publish identical hardware minimums, so it is not a hardware decision: pfSense CE versus pfSense Plus covers what actually separates them. If the hardware is already in place and underperforming, finding the real bottleneck behind slow pfSense speeds works through the diagnostic order before you spend anything.

Common mistakes

Sizing RAM from the published minimum rather than from the expected state table. Adding an inspection engine to a build specified for plain routing. Quoting a throughput target in megabits without naming a frame size. Buying processor speed instead of network interfaces. Installing on 8 GB of low-endurance flash and discovering the limit during an upgrade. Treating cryptographic acceleration as optional on a firewall whose main job is a VPN.