Workload sizing for pfSense starts with peak state counts, inspection settings and encrypted traffic. These inputs describe the work the firewall must do; a WAN subscription speed alone does not. This guide turns Netgate’s published resource figures into a capacity plan for routing, VPN and IDS workloads.
For installation prerequisites, see pfSense minimum and recommended requirements. Record those separately from the workload allowances below.
Define the workload before choosing a capacity tier
Write down the expected peak states, inspected interfaces and rule categories, VPN protocol and cipher, and target throughput through the firewall. Include whether the target describes one large transfer or many concurrent flows. Netgate identifies required throughput and enabled features as the primary sizing inputs.
Use those inputs to budget memory first, then check packet processing and encryption capacity. An allowance for inspection should be explicit so it can be revised when the ruleset changes.
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.
A one-million-state table therefore needs about 1 GB for state tracking alone. Budget the operating system, packages and buffers separately; the state-table total is not the firewall’s total RAM requirement.
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. pfSense throughput bottlenecks in routing, VPN and IDS 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: leave capacity for logs and upgrades
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.
VPN sizing depends on the cipher and acceleration path
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 capacity plan by workload
These are planning inputs derived from the resource costs above, not measured throughput tiers or a replacement for installation requirements.
| Workload | Memory input | Throughput input |
|---|---|---|
| Routing and NAT | Peak states plus system and buffer use | Packet rate, frame sizes and NIC overhead |
| Snort or Suricata | Add the inspection engine’s allocation | Inspected interfaces and enabled rules |
| VPN traffic | Keep state and package allowances | Protocol, cipher and available acceleration |
| VPN with inspection | Budget both workloads together | Encryption and inspection running at the same time |
Record the NIC and driver alongside this plan. Memory capacity cannot establish a throughput guarantee, and a port’s link speed does not establish the rate available with inspection and encryption enabled.
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 throughput and state-table sizer combines the documented state-memory estimate with this site’s planning allowances for your WAN speed and inspection level. Treat its core and VPN figures as assumptions to validate on your own traffic.
Two follow-ups help complete the plan. pfSense CE versus pfSense Plus covers release, support and feature differences to check alongside the workload. 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.
