pfSense Requirements: Minimum & Recommended Hardware
See pfSense minimum and recommended CPU, RAM, storage, and NIC requirements for basic routing, VPN, pfBlockerNG, and Suricata IDS/IPS.
Affiliate disclosure: Some links below are Amazon affiliate links. We may earn a small commission at no extra cost to you. Components are selected from published specifications and vendor documentation, not from commission rates.
This requirements reference answers what CPU, RAM, storage, and NIC capacity pfSense needs. It starts with Netgate’s documented minimum of a 64-bit CPU, 1 GB of RAM, an 8 GB disk, and one supported NIC, then defines practical floors for routing, Suricata, pfBlockerNG, and VPN workloads. It does not rank appliances or models; readers with a target specification can compare concrete options in the pfSense hardware buying guide.
The documented minimum
Netgate’s minimum hardware requirements page lists the following for pfSense software running on hardware Netgate does not sell:
| Component | Documented minimum |
|---|---|
| CPU | 64-bit amd64 (x86-64) compatible processor |
| RAM | 1 GB or more |
| Disk | 8 GB or larger (SSD or HDD) |
| Network | One or more compatible network interface cards |
| Install media | Bootable USB drive, or a DVD/BD optical drive |
The same page carries its own warning: the minimum requirements are not suitable for all environments, and it points readers at the sizing guidance for anything real. Treat the table as a compatibility statement, not a shopping list.
Two details in it matter more than they look. “amd64” means all 64-bit x86 CPUs, Intel and AMD alike, and it also means 32-bit hardware is finished. “One or more” network cards is technically true because a single physical port can carry tagged VLANs, but a one-port install forces every network you own through one wire; see the pfSense VLAN configuration guide for when that trade is acceptable and when it is not. Two physical ports remains the sane floor.
One architecture note from the hardware selection docs: the ARM appliances Netgate sells, the 2100 and 3100 among them, are compatible with the Plus edition. The requirements above are an amd64 list, so those boxes are not a CE platform. If you want CE, you want an amd64 box, and that single fact eliminates a whole shelf of otherwise attractive ARM hardware.
CPU requirements: single-thread speed first, cores where they are actually used
Two different workloads share this CPU and they want different things. The forwarding path — pf, NAT, policy routing — and OpenVPN are effectively single-thread bound, so how fast one core runs matters more than how many cores exist, and a fast quad-core beats a slow eight-core for that work almost every time. Inline inspection is the exception: Suricata is natively multithreaded and does spread inspection across cores, while Snort’s real-world multicore behaviour on pfSense is less proven, which is one of the reasons Suricata is usually the right engine. Buy per-core speed first; treat extra cores as headroom for inspection rather than as a substitute for clock speed.
The number that actually governs sizing is packets per second, not megabits. Netgate’s sizing guidance publishes the conversion, and it is worth internalising because it explains why two connections at the same advertised speed can need very different hardware:
| Frame size | Throughput at 500,000 packets/sec |
|---|---|
| 64 bytes | 244 Mbps |
| 500 bytes | 1.87 Gbps |
| 1000 bytes | 3.73 Gbps |
| 1500 bytes | 5.59 Gbps |
The same CPU effort moves 244 Mbps of small packets or 5.59 Gbps of large ones. Bulk downloads are large-packet traffic and are cheap. VoIP, gaming, DNS floods, and anything under attack are small-packet traffic and are expensive. If your traffic mix skews small, size well above your advertised line rate.
Practical CPU floors, by what you plan to run:
- Routing, NAT, DHCP, and DNS on a 1 Gbps line: almost any modern dual-core, including low-power Atom-class parts, saturates gigabit. This is the cheap case, and it is the case most home networks are actually in.
- pfBlockerNG DNSBL and GeoIP: still cheap on CPU. The load is DNS lookups and table matching rather than per-packet inspection. See the pfBlockerNG setup guide for what the feeds cost in memory instead.
- Suricata or Snort inline IPS: the single biggest throughput killer. Inline inspection costs a large fraction of what the same box forwards with inspection off, and ruleset size matters as much as clock speed does. Budget a quad-core with strong per-core performance for 500 Mbps and up, and read Suricata vs Snort on pfSense before you commit, because the two engines use cores differently.
- VPN termination: AES-NI is effectively mandatory. Netgate’s guidance is blunt that hardware cryptographic acceleration is of utmost importance where VPN throughput matters, and that IPsec is nearly always faster than OpenVPN because it has less per-packet OS overhead. WireGuard is lighter still. The OpenVPN vs WireGuard comparison covers which one your CPU budget can afford.
To turn a line speed and a feature list into a concrete CPU class, run them through the pfSense hardware sizing calculator rather than guessing a tier.
RAM requirements: base, state table, packages
RAM is the one requirement you can compute almost exactly, which makes it the easiest to stop worrying about.
Base system. The OS plus core services need roughly 175 to 256 MB beyond the state table, per Netgate’s sizing guidance. In practice 2 GB is the working floor for any deployment you care about.
State table. Each connection through the firewall consumes two states, one inbound and one outbound, and each state takes approximately 1 KB of RAM. Netgate’s published table:
| States | Connections | RAM for states |
|---|---|---|
| 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 |
The useful shorthand from the same page: 100,000 states is about 100 MB, and 1,000,000 states is about 1 GB. A busy household rarely exceeds 100,000 states, so the state table is almost never what fills your RAM. Packages are.
Packages. Netgate’s sizing guidance puts Snort and Suricata at 1 GB minimum, with some configurations needing 2 GB or more, and that is on top of the operating system, the state table, and everything else installed. Both packages are configured and run per interface, so the figure scales with how many interfaces you inspect rather than being paid once: inspecting WAN, LAN, and a DMZ is three allocations, not one. pfBlockerNG holds DNSBL and GeoIP tables in RAM too, growing with the number and size of the feeds you subscribe to.
That produces three honest tiers:
- 4 GB: routing plus DHCP, DNS, and light pfBlockerNG. Comfortable.
- 8 GB: the floor once Suricata or Snort runs inline on one or two interfaces alongside pfBlockerNG.
- 16 GB: cheap headroom, and the right answer if you run IDS on several interfaces, keep large blocklists, or install on ZFS, which trades RAM for snapshots and rollback before updates.
NIC requirements: the part people get wrong
This is where budgets get misallocated. Netgate’s sizing guidance states it directly: inexpensive low-end cards consume significantly more CPU than better-quality cards such as Intel, throughput improves significantly by using a better NIC even with slower CPUs, and increasing CPU speed will not proportionally increase throughput when paired with a low-quality NIC.
Translated into a buying rule: spend on the NIC before you spend on the CPU.
- Use Intel. The
igb,igc, andixdrivers are the well-trodden path and are what Netgate and Protectli ship. Realtek works for light gigabit use but has a long FreeBSD history of throughput and stability problems under sustained load, and inline IPS via netmap frequently will not run on it at all. - Two ports minimum, more if you want a DMZ or physically separate networks rather than tagged VLANs on one trunk.
- Match the port speed to the line, not to the marketing. 1 GbE is still correct for the majority of home connections. 2.5 GbE matters if your ISP tier exceeds gigabit or you expect it to within the hardware’s life.
- 10 GbE only belongs in a firewall that routes between fast internal segments or terminates a multi-gig WAN. When you do need copper 10 GbE in a box with a spare PCIe slot, the Intel X550-T2 is the genuine dual-port Intel card the community standardises on; the marketplace is full of near-identical third-party clones built on the same controller with less predictable firmware.
Sealed fanless appliances usually cannot accept an add-in card. If port count or port speed might change within two years, buy the ports up front or buy a chassis with a slot.
Storage requirements
pfSense itself is small. What grows is logs.
- 8 GB is the documented minimum, and it is genuinely enough for a plain router that logs little.
- 32 GB or more is the practical requirement once Suricata alerts and pfBlockerNG feed logs are writing continuously, plus the RRD graph database.
- Use an SSD or NVMe drive, never a USB stick or SD card. IDS and blocklist logging is a sustained small-write workload, which is precisely what kills low-endurance flash. A dead boot device on a firewall takes the whole network with it.
- ZFS, where the installer offers it, buys you a snapshot and rollback before every update. It costs a little RAM and is worth it on any box with 8 GB or more.
Requirements by workload
The tiers below combine the CPU, RAM, NIC, and storage floors above into the four configurations most homelab firewalls actually land in.
| Workload | CPU class | RAM | NIC | Storage |
|---|---|---|---|---|
| 1 Gbps routing, NAT, DHCP, DNS | Modern dual-core, AES-NI | 4 GB | 2x Intel 1 GbE | 32 GB SSD |
| 1 Gbps plus pfBlockerNG DNSBL and GeoIP | Modern dual-core, AES-NI | 4-8 GB | 2x Intel 1 GbE | 32 GB SSD |
| 1 Gbps with inline Suricata IPS | Quad-core, fast cores, AES-NI | 8 GB | 2-4x Intel 1 GbE | 64 GB SSD |
| 2.5 Gbps or multi-gig with IPS and VPN | Quad-core i3/i5 class or better | 16 GB | Intel 2.5 GbE or 10 GbE | 128 GB NVMe |
Treat each row as a floor rather than a target. Buying one tier up costs less than rebuilding the firewall in eighteen months.
Power and thermal requirements
A firewall runs 24/7, so idle draw is a recurring cost rather than a spec-sheet curiosity. A fanless 10 W appliance and a repurposed desktop pulling 60 W differ by roughly 440 kWh a year, which is a real line on an electricity bill and a real difference in closet temperature and noise.
Two requirements follow. In a sealed cupboard or a living space, prefer a fanless design and confirm the vendor’s thermal rating covers your ambient temperature. And if you are choosing between candidate boxes on running cost rather than purchase price, measure rather than trust the label: a Kill A Watt P3 P4400 at the wall gives you the actual idle and loaded draw for whatever you already own, which converts directly into an annual cost you can compare.
Virtual machine requirements
Running pfSense as a guest changes the requirements list rather than shortening it:
- 2 vCPU and 4 GB RAM is a sane starting allocation, scaled up by the same package rules as bare metal.
- Pass through a physical NIC for the WAN using VT-d or equivalent, rather than bridging a virtual adapter. Bridging inherits virtio quirks and blurs the isolation boundary that makes a firewall a firewall.
- Budget one physical port per pfSense interface, which usually means the host needs a multi-port card of its own.
- Accept the dependency. A host reboot or storage fault now takes your internet down with it. The pfSense on Proxmox installation guide walks the passthrough configuration and the failure modes.
What the requirements list does not cover
The documented minimums say nothing about several things that decide whether a build is pleasant to live with: serial console access for headless recovery, whether the BIOS supports unattended power-on after an outage, whether the case has room for a second drive, and whether the vendor publishes firmware updates. None of these appear on a spec comparison, and all of them surface at the worst possible moment.
The list is silent on redundancy too. Every figure above sizes a single box, so a firewall that has to survive its own hardware failure is really two builds plus a spare interface on each node for the pfsync link, and the pfSense CARP high availability guide covers what that second box and the extra addressing actually cost.
Once you have a target CPU class, RAM figure, NIC type, and storage size, turn it into a shortlist with the pfSense hardware sizing calculator, then compare concrete models in the best hardware for pfSense guide or the narrower best mini PC for pfSense picks. If you have not installed yet, the pfSense initial setup guide covers what happens after the box arrives.
Sizing the same build for a different firewall? OPNsenseLab covers the OPNsense equivalents, and FirewallCompare has side-by-side appliance spec sheets for both platforms.
Related across the network
- Ceph Hardware Requirements: CPU, RAM, Disks, Network — cephclusterguide.com
- ComfyUI vs Automatic1111 vs Forge: Which to Run — comfyuiops.com
Sources
Related
pfSense Appliances: Netgate, Protectli, or DIY Build
What a pfSense appliance actually buys you, how Netgate, third-party boxes, and DIY builds differ, and the five checks to run before ordering any of them.
Best pfSense Hardware to Buy in 2026 by Use Case
A spec-based comparison of pfSense appliances, mini PCs, and used systems by WAN speed, IDS/IPS load, NICs, support, power use, and budget.
Best Mini PC for pfSense 2026: Buying Guide and Picks
What actually matters when picking a mini PC for pfSense in 2026: Intel NICs over Realtek, core count for IDS and VPN, RAM headroom, and which boxes fit.