Sizing pfSense Hardware: What Actually Limits Throughput

Choosing hardware for a pfSense firewall goes wrong in a predictable way: people buy for the wrong bottleneck. Plain routing, encrypted tunnels and deep packet inspection each stress a different part of the machine, so the right build depends entirely on which of them you will actually run.

Plain routing is cheap

Forwarding packets between interfaces with stateful filtering is not demanding work for a modern processor. What matters more is the network interface hardware and how packets are distributed across CPU cores. Server-grade Ethernet controllers with mature drivers behave well under load and offload work sensibly; some consumer controllers are supported but are known for higher interrupt overhead and stability quirks under sustained traffic. If you are choosing where to spend, spend on the NICs before the CPU.

Packet size also matters. A link saturated by large transfers is easy. The same link filled with very small packets means far more per-packet work for the same bandwidth, which is the situation that exposes weak hardware. Netgate publishes the conversion: at 500,000 packets per second, 64-byte frames deliver 244 Mbps while 1500-byte frames deliver 5.59 Gbps from the same packet rate.

Cheap controllers do not merely perform worse, they charge the cost to the CPU. Netgate’s guidance is that low-end cards consume significantly more CPU than better-quality ones, that the first bottleneck in firewall throughput is the CPU, and that a better card paired with a slower processor beats a faster processor paired with a poor card. If an existing build is already underperforming, work through the diagnostic order for slow pfSense speeds before replacing anything.

VPN throughput is single-connection bound

Encrypted tunnels are the usual reason a firewall feels slow. Two things dominate.

First, hardware acceleration for the cipher in use. A processor with dedicated instructions for the relevant encryption does that work far more efficiently than one without, so check for it before buying.

Second, and less obvious, a single tunnel or a single connection typically cannot be spread across many cores. Extra cores raise the total the box can handle across many simultaneous connections, but they do not raise the ceiling for one transfer. A high core count with a low per-core clock can therefore be the wrong choice for a site-to-site link carrying one big flow.

Inspection consumes memory

Running an intrusion detection or prevention engine changes the memory picture. The engine holds its rule set and per-flow state in RAM, and the requirement scales with how many rule categories you enable and how many interfaces you inspect. Enabling everything on every interface is the fastest way to make a comfortable machine start swapping or killing processes.

State table size is the other memory consumer. Every connection through the firewall consumes two states, one entering and one leaving, and Netgate puts each state at roughly 1 KB of RAM, so a million states costs about 1 GB before the operating system takes its share. Default limits are derived from installed memory, so undersizing RAM quietly caps how many connections the firewall will hold. The full arithmetic, and how far it sits above the published floor, is in pfSense hardware requirements, minimum versus realistic.

Storage and reliability

The operating system itself is small, but logging, traffic statistics and package data write continuously. Low-quality flash storage is a common source of firewalls that work for months and then fail to boot. Use storage rated for sustained writes, and keep an exported configuration backup somewhere off the device. Restoring a configuration onto fresh hardware is quick; reconstructing it from memory is not.

If uptime matters, a redundancy protocol lets two firewalls share a virtual address and synchronise state so that connections survive a failover. That requires a second machine, a dedicated link between them, and a network design that accounts for it, so decide before you build rather than after.

Where extra spending does nothing

More cores will not speed up a single encrypted transfer. More RAM will not help if the bottleneck is a saturated uplink or a weak network controller. A faster CPU will not fix packet loss caused by a bad cable or a duplex mismatch. And no firewall hardware improves an internet connection that is already the limiting factor.

Nor does the software edition change any of this. Both editions publish the same hardware minimums, and the differences that do exist are covered in pfSense CE versus pfSense Plus.

Turn this into a number

The sections above describe which component each workload stresses. To convert that into a specification, the pfSense appliance sizer takes a target WAN speed, an expected state count and an inspection level, and returns a memory figure built on the same 1 KB-per-state arithmetic plus a core-count tier. It prints the tables it uses, so the output can be argued with rather than accepted.

Common mistakes

Buying for peak bandwidth while ignoring cipher acceleration. Enabling every inspection rule category on a machine sized for plain routing. Using consumer flash storage for a device that writes logs continuously. Leaving the firewall behind an upstream router that also performs address translation. Planning high availability after the addressing scheme is already in production.