Hardware Sizing Guidance¶

When sizing hardware for pfSense® software, required throughput and necessary features are the primary factors that govern hardware selection.

Throughput Considerations¶

The minimum requirements are enough if less than 100 Mbps of unencrypted throughput is required. For higher throughput requirements, follow these guidelines based on extensive testing and deployment experiences.

The hardware referenced in this section is available from the Netgate Store. The general specifications of the hardware can be found in Table pfSense Hardware. Network interfaces marked with “*” are integrated Switched Ethernet ports. Interfaces maked with “SFP” require SFP modules. Some models may have additional expansion cards available, check the Netgate Store pages for details.

pfSense Hardware¶
Model	CPU	Clock (Cores)	RAM (GB)	NIC Speed
SG-1100	ARM Cortex A53	1.2 GHz (2)	1	3x1G*
SG-3100	ARMv7 Cortex-A9	1.6 GHz (2)	2	2x1G, 4x1G*
SG-5100	Intel Atom C3558	2.2 GHz (4)	4-16	6x1G
XG-7100	Intel Atom C3558	2.2 GHz (4)	8-24	2x10G SFP, 8x1G*
XG-1537	Intel Xeon-DE D-1537	1.7 GHz (8)	8-32	2x10G SFP, 2x1G
XG-1541	Intel Xeon-DE D-1541	2.1 GHz (8)	16-32	2x10G, 2x1G

The Table Maximum Throughput by Model (1460 Byte Packets) compares throughput between several hardware models. The table contains throughput for TCP packets with a payload size of 1460 bytes as measued by iPerf3 with pf enabled. Speed is tested across all available base model ports. These numbers tend to be larger since it’s a best-case scenario where all packets are full-size for typical 1500-byte MTU links.

Warning

The numbers below are sample results of ongoing testing and do not accurately reflect the full potential throughput of each device.

Maximum Throughput by Model (1460 Byte Packets)¶
Model	TCP - 1460B
SG-1100	656 Mbit/s
SG-3100	2.44 Gbit/s
SG-5100	3.65 Gbit/s
XG-7100	6.81 Gbit/s
XG-1537	14.48 Gbit/s
XG-1541	14.63 Gbit/s

In real networks the traffic flow will likely contain packets of varying size, not all this large, but it completely depends on the environment and the type of traffic involved. IMIX testing attempts to approximate a mixture of traffic that more closely resembles real-world environments. Simple IMIX traffic is sets of 7 (40) byte packets, (4) 576 byte packets, 1 (1500) byte packets, plus Ethernet framing overhead.

The Table Maximum Throughput by Model (IMIX) compares throughput between several hardware models, but using IMIX style mixtures of packet sizes. Speed is tested across all available base model ports. These numbers tend to be lower due to the increased load from handling smaller packet sizes.

Warning

The numbers below are sample results of ongoing testing and do not accurately reflect the full potential throughput of each device.

Maximum Throughput by Model (IMIX)¶
Model	IMIX
SG-1100	190 Mbit/s
SG-3100	1.04 Gbit/s
SG-5100	1.84 Gbit/s
XG-7100	1.85 Gbit/s
XG-1537	5.00 Gbit/s
XG-1541	6.10 Gbit/s

As a general reference, table 500,000 PPS Throughput at Various Frame Sizes lists a few common packet sizes and the throughput achieved at an example rate of 500,000 packets per second.

500,000 PPS Throughput at Various Frame Sizes¶
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

Performance difference by network adapter type¶

The choice of NIC has a significant impact on performance. Inexpensive, low end cards consume significantly more CPU than better quality cards such as Intel. The first bottleneck with firewall throughput is the CPU. Throughput improves significantly by using a better quality NIC with slower CPUs. By contrast, increasing the speed of the CPU will not proportionally increase the throughput when coupled with a low quality NIC.

Feature Considerations¶

Features, services and packages enabled on the firewall can lower the total potential throughput as they consume hardware resources that could otherwise be used to transfer network traffic. This is especially true for packages that intercept or inspect network traffic, such as Snort or Suricata.

Most base system features do not significantly factor into hardware sizing but a few can potentially have a considerable impact on hardware utilization.

Large State Tables¶

Active network connections through the firewall are tracked in the firewall state table. Each connection through the firewall consumes two states: One entering the firewall and one leaving the firewall. For example, if a firewall must handle 100,000 simultaneous web server client connections the state table must be able to hold 200,000 states.

VPN (all types)¶

The question customers typically ask about VPNs is “How many connections can my hardware handle?” That is a secondary factor in most deployments and is of lesser consideration. That metric is a relic of how other vendors have licensed VPN capabilities in the past and has no specific direct equivalent in pfSense. The primary consideration in hardware sizing for VPN is the potential throughput of VPN traffic.

Encrypting and decrypting network traffic with all types of VPNs is CPU intensive. pfSense offers several cipher options for use with IPsec. The various ciphers perform differently and the maximum throughput of a firewall is dependent on the cipher used and whether or not that cipher can be accelerated by the hardware.

Hardware crypto accelerators greatly increase maximum VPN throughput and largely eliminate the performance difference between accelerated ciphers. Table IPsec throughput by hardware model illustrates the maximum throughput for various hardware available from the pfSense store when using IPsec.

For IPsec, ciphers may be accelerated by onboard cryptographic accelerators. For example, AES-GCM is accelerated by AES-NI and it is faster not only for that, but because it also does not require a separate authentication algorithm. IPsec also has less per-packet operating system processing overhead than OpenVPN, so for the time being IPsec will nearly always be faster than OpenVPN.

Warning

The numbers below are sample results of ongoing testing and do not accurately reflect the full potential throughput of each device.

IPsec throughput by hardware model¶
Model	IPsec Crypto	TCP 1460B	IMIX
SG-1100	AES-128-CBC + SHA1	74.2 Mbit/s	46 Mbit/s
SG-3100	AES-128-CBC + SHA1	453 Mbit/s	108 Mbit/s
SG-5100	AES-128-GCM	923 Mbit/s	380 Mbit/s
XG-7100	AES-128-GCM	1.28 Gbit/s	385 Mbit/s
XG-1537	AES-128-GCM	2.77 Gbit/s	2.10 Gbit/s
XG-1541	AES-128-GCM	2.82 Gbit/s	2.81 Gbit/s

Where high VPN throughput is a requirement for a firewall, hardware crypto acceleration is of utmost importance to ensure not only fast transmission speeds but also reduced CPU overhead. The reduction in CPU overhead means the VPN will not lower the performance of other services on the firewall. The current best available acceleration is available by using a CPU which includes AES-NI support combined with AES-GCM in IPsec.

Packages¶

Certain packages have a significant impact on hardware requirements, and their use must be taken into consideration when selecting hardware.

Snort/Suricata¶

Snort and Suricata are pfSense packages for network intrusion detection. Depending on their configuration, they can require a significant amount of RAM. 1 GB should be considered a minimum but some configurations may need 2 GB or more.

Suricata is multi-threaded and can potentially take advantage of NETMAP for inline IPS if the hardware offers support.

Squid¶

Squid is a caching HTTP proxy server available as a pfSense package. Disk I/O performance is an important consideration for Squid users since it determines cache performance. In contrast, disk speed is largely irrelevant for most pfSense firewalls since the only significant disk activity is boot time and upgrade time; it has no relevance to network throughput or other normal operation.

Even for Squid any hard drive will suffice in small environments. For 200+ user deployments, a high-quality SSD from a Tier-1 OEM is a must-have. A low-quality SSD may not be able to endure the numerous writes involved with maintaining cached data.

The size of the squid cache also factors into the amount of RAM required for the firewall. Squid consumes approximately 14MB of RAM per 1GB of cache on amd64. At that rate, a 100GB cache would require 1.4GB of RAM for cache management alone, not counting other RAM needs for squid.

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