Firewall Hardware Sizing Guide

Before Starting

The following hardware sizing guide was written initially and mainly for the pfSense® CE and OPNsense® operating systems.

Anyone interested in learning more about the differences will find a comparative pfSense® CE VS OPNsense® technique at this link.

However it is possible to extend these concepts also for Zeroshell, ipFire.

Useful tools: fast sizing of the devices

Below we will expand on some technical concepts to explain and motivate our conclusions in the Instant dimensioning table.
If the navigator does not want to read the entire technical part, he can immediately jump to: Instant sizing.

Here you can find the link to the NEW HARDWARE CONFIGURATOR of our equipment: with just a few clicks it will allow you to understand which device to buy.

Equipment hardware configurator.
N.B. Under “Select product category”: select “Firewall”.


To size a hardware firewall based on pfSense® CE / OPNsense® from 2.4.X / 18.X onwards it is necessary to keep in mind 3 main factors:

1.Required throughput

2.Features or additional packages of pfSense® / OPNsense® used

3.Number and type of NIC (Network Interface Card) required

These 3 factors mainly affect RAM, CPU, mass memory and of course NIC quantities. In the lower part we will provide our experience in hardware sizing.

Also keep in mind that pfSense® from version 2.4 DOES NOT SUPPORT systems on CF anymore (in particular it no longer supports i386 images), which OPNsense® continues to do.

1. Considerations on the requested throughput

By definition, throughput of a communication channel is meant its transmission capacity actually used.

Throughput is not to be confused with link capacity. Both capacity and throughput are expressed in bit / s, but while the first expresses the maximum transmission frequency at which data can travel, throughput is an index of the actual use of the link capacity. Throughput is the amount of data transmitted in a unit of time and depends exclusively on how much information is entered on the transmission channel.

Before considering troughput considerations, we need to consider the fact that both pfSense® and OPNsense® can operate both as a firewall and as a router or both. It will therefore be necessary to consider the overall throughput of the system we want to achieve for the choice of the apparatus.

For example, if we need to build a firewall, we can consider the sum of the WAN throughputs as throughput.

If instead we have to create a Router that joins networks together we have to sum up the throughput of all the interfaces, both WAN and LAN.

CPU type

It is important to determine the throughput of a network before installing a pfSense® / OPNsense® firewall / router as it determines the type of CPU to use and in some cases the type of NIC.

If less than 10 Mbps are required then the minimum hardware requirements can be used. For higher throughputs we strongly advise you to follow the sizing suggested by the following table, based on tests actually performed in the field. The table below is designed to avoid reaching the maximum level of hardware load, so as not to run into problems.

If for example I have to build a Router or a Firewall with 10 Gbit ports, I won’t be able to use a less powerful CPU than a Quad Core XEON. In fact, when the NICs reach 10 Gbit of traffic the Core of the appliance goes to 100% and the machine goes into crisis.

For these uses we recommend A2-Server o A3-Server.

It should be noted that the pfSense development team has announced that as of version 2.5 it will NOT BE MORE POSSIBLE to install and even less to update the versions of pfSense on hardware without CPUs with AES-IN instructions. The reason (always declared by pfSense) is that to support the increase in CPU loads resulting from cryptography it was necessary to use the set of AES-NI instructions that are used to optimize encryption and decryption algorithms on certain processors Intel and AMD.

This does not concern the OPNsense developers who declare that the execution of the AES-IN instructions can be done either via hardware (with CPUs having AES-IN instructions) or via software, as is the case with current versions of both distributions without any particular problems.

Minimum system requirements for pfSense® up to version 2.4.X:

CPUNot less than 1GHz
Installation su Hard Disk16 GB
EmbeddedCF not supported

Minimum system requirements for pfSense® CE version 2.5.X:

CPUNot less than 1 GHz, CPU with AES-IN
Installation on Hard Disk16 GB
EmbeddedCF not supported

PfSense® CE/OPNsense® sizing based on Throughput

Suggested hardware requirements
Suggested product
1-20 MbpsNot less than 1000 MHz CPU Single CoreFIREWALL ENTRY LEVEL
APU1 Entry Level
APU2 Entry Level
10-100 MbpsNot less than 2.4 GHz CPU Quad CoreFIREWALL CORPORATE
Compact Small UTM 3
Appliance Small UTM 3
Almost nothing (*)
450 – 1000 MbpsNot less than 3,5 GHz Quad CoreFIREWALL DATACENTER
Medium (*)
Up to 10 GbpsNot less than 3,5 GHz Xeon Quad/Octa CoreFIREWALL DATACENTER
Medium (*)

Sizing pfSense® CE/OPNsense® based on Cluster version Throughput

Suggested hardware requirementsSuggested productNoisiness
1-20 MbpsNot less than 1000 MHz CPU Single CoreFIREWALL ENTRY LEVEL
Nano Cluster APU2
10-100 MbpsNot less than 2.4 GHz CPU Quad CoreFIREWALL CORPORATE
Compact Small UTM 3
Appliance Small UTM 3
Power Cluster
Low (*)
450 – 1000 MbpsNot less than 3,5 GHz Quad/Octa CoreA2-Server Cluster
A3-Server Cluster
Medium (*)
Up to 10 GbpsNot less than 3,5 GHz Xeon Quad/Octa CoreA2-Server Cluster
A3-Server Cluster
Medium (*)

(*) The Power Cluster and APUTM models with Intel I7 CPU have a Medium noise level only if they are subjected to strong and continuous workloads.

2. Features or additional packages of pfSense®/OPNsense® used

Many features of pfSense® CE/OPNsense® greatly influence hardware sizing.

VPN: the heavy use of the VPN service greatly increases the CPU requirements. Encryption and decryption of packets increases the load on the CPU. The number of connections is a less troubling factor than throughput.

  • 266 MHz CPU supports approximately 4 Mbps of IPsec traffic
  • 500 MHz CPU supports about 10-15 Mbps of IPsec traffic
  • New-generation I7 or I3 CPUs support almost up to 200 Mbps of IPsec traffic
  • New generation XEON CPU for loads over 400 Mbps

Squid – Squidguard – outbound proxy traffic control: both packages use a lot of CPU and disk writes. Therefore, it is strongly discouraged to use the Entry level, Entry level APU1 and Entry Level APU2.
For this type of work it is strongly recommended to use Appliance Small UTM 3, Compact Small UTM 3, A2SUTM, A1-Server, A2-Server, A3-Server or APUTM with SSD or Classic disks.
However, it is also possible to use optimized with only the squid package on Entry level APU1 and Entry Level APU2 provided that you use the writing on the disk support sparingly and in any case to the detriment of performance.

pfBlockerNg: pfBlockerNG is a package for pfSense® that allows extending the functionality of the firewall beyond the traditional L2 / L3 / L4 firewall. pfBlockerNG allows you to configure the firewall to allow / deny traffic based on elements such as the geo location of an IP address, the domain name (for example to block Facebook and the like) or Alexa’s assessments of certain websites.

This package requires an increase in CPU and RAM from 15% to 25%.

To learn more about this package, you can consult the guide we have created and published in our guide area.

Captive Portal: Environments with hundreds of connections require a lot of CPU. With reference to the throughput table it will be necessary to increase users by 15-20% to get the recommended platform.

Large state tables: Each entry in the state table requires 1 KB. The state table, when full, has 10,000 entries, so about 10 MB of RAM. For larger state tables, with hundreds of thousands of connections it will be necessary to properly size the RAM.

Packages: many packages significantly increase the amount of RAM used. For example, snort and ntop should not be installed on hardware platforms with less than 512 MB of RAM and at least 32 GB of disk.

Version of pfSense®/OPNsense® to be installed

The difference between the two types of installations that can be made with pfSense® / OPNsense® on different devices should be emphasized.

We remind you that as far as pfSense® is concerned, the last version that can be installed on CF (ie the embedded version) is 2.3.5, while for OPNsense® the termination of the support is not envisaged.

  • The Embedded solution (firewall Entry Level) DOES NOT allow the writing of log files on the memory (C.F. or DOM) and in any case it is strongly discouraged to do so. On this version it is not possible to install some of the additional packages of pfSense® / OPNsense®.
  • The solution that installs on a hard disk (normally on UTM or higher Appliance solutions) has the ability to save the logs inside it. On this version it is possible to install all the additional packages supplied for pfSense® / OPNsense®.
  • We remind you that pfSense 2.5.X will be installed only on hardware with a CPU with AES-IN support

3. Deepening on the network card chipsets

Choosing a network card is essential for those who are designing a medium / large system.

As you can see from the product descriptions, we always specify very well if the devices integrate Intel or Realtek chipsets internally.

From about mid-2016 onwards virtually all our devices are equipped with Intel chipsets.

The Realtek chipset is less powerful than the Intel chipset and is suitable mainly for less intense workloads. However, for a company that does not require high throughputs (like 85% of Italian companies) it remains the ideal choice.

The Intel chipset, on the other hand, offers greater performance in the event of heavy traffic: in fact, it offers several advanced features such as queue management and, from the pfSense® 2.2 version, also improved multi-core support. This results in higher throughput and less CPU load.

To be precise, full support for multicores has been introduced on FreeBSD, that is, by S.O. father of pfSense® and OPNsense®, so the same argument made for pfSense® is valid and will apply to OPNsense® in the future.

If you are still using pfSense® 2.1.x, we have published an in-depth study on optimizing Intel NICs by tuning the driver and settings. However, we specify that up to now our appliances do not need such optimization. However, we insert it for completeness.

On the current versions of pfSense® / OPNsense® it does not seem necessary to make changes.

If you think your appliances have performance problems arising from NICs, you can use this guide to diagnose the problem.

4. Sizing according to the noise of the equipment

To provide the right product, you need to think about where the firewall will be placed.

If the device is placed near people who work, it will be necessary to choose a machine with a low noise level or it will be necessary to purchase a silent silent kit!

Lately, due to Intel’s new 25-nanometer technology, the absorbed power has greatly reduced and consequently the dissipated heat has also decreased.

From the design point of view, we preferred to maintain the fan in the high-end models (typically used in data centers or CEDs). This is because, if the board or CPU detects high temperatures, using the fan would bring the temperature back to acceptable levels in a few seconds.

Below is a table showing indicative data on the noise level of the equipment:

Band ApparatusNoise level
Entry Level / APU1 Entry Level / APU2 Entry Level / Appliance Small UTM 3 / Compact Small UTM 3 / NanoCluster / A2SUTM / Small ClusterLevel 0 (completamente fan less)
A1-ServerLevel 1 (rumore quasi impercettibile)
A2-Server / A3-Server
Power Cluster / APUTM
Level 4 (rumore udibile from 4/5 meters)

Notes on noise::
a device that dissipates heat well, will certainly last longer and will be more stable and reliable!
That’s why our high-end devices are designed in such a way that the airflow “invests” the internal components by cooling them.

5. RAID function

One of the functions most appreciated by pfSense® CE/OPNsense® in terms of hardware reliability is the Raid functionality directly implemented by the FreeBSD operating system.
This function guarantees a higher level of reliability of the application as in the event of a disk failure the application will continue to function as if nothing had happened.
This function is supported by: Appliance Small UTM 3 / Compact Small UTM 3, A2SUTM, A1-Server, APUTM, A2-Server, A3-Server and in all the Cluster versions of our devices except the NanoCluster.
For those wishing to deepen the subject, we published a guide that explains how it works and how to intervene on the equipment in case of failure. You can find it under the guide menu.

6. When should I use a Cluster system?

A Cluster system is a solution composed of a system having two completely independent hardware devices. There are 3 versions of Cluster solutions, one for small offices and the other for heavy traffic and / or medium/large structures.

  • NANOCluster: compact 1U solution, designed for small offices
  • Small Cluster: 2U solution for SMEs and / or small Datacenters that do not want to give up high reliability
  • Power Cluster: 2U solution for companies and organizations that need high reliability
  • A2-Server Cluster and A3-Server Cluster: 2U Datacenter-level solution that provides high reliability

The Small Cluster and the Power Cluster are 2U devices, consisting of 2 independent drawers, while the NanoCluster is composed of two Entry Level devices.
Using pfSense® CE or OPNsense® you can get a real passive active Cluster configured to obtain high reliability between the 2 devices that become in effect the cluster nodes.
The others S.O. they do not have (hopefully for now) a function like the CARP of pfSense® CE / OPNsense® but they can still be configured in such a way that the user can manually switch off one of the two systems and turn on the other. We can therefore say that it is a Cluster system that in the case of pfSense® CE and OPNsense® is automatic and in the case of other S.O. it’s manual. This system should be used in environments where high reliability is mandatory.

7. Instant sizing

Based on our experiences we have compiled a classification of the installations we have followed over the years. This classification is not only the result of the experience made during the installation of the firewall, but also of the technological evolution that the user requires to the device during the years of use.

The results are linked, for example, to the technological evolution that every company / entity undergoes or requires over the years for different needs. For example, small businesses initially require the installation of a simple firewall. Normally it does not take much time to submit requests such as VPN, content filtering or navigation rules.

For this reason, based on the number of “active devices” (ie devices connected to the Internet) we have elaborated the following table which also takes into account the above concepts:

Firewall modelN.of active devices
Entry Level o NanoClusterfrom 1 a 5 users
Entry level APU1 o Entry Level APU2 o NanoClusterfrom 1 a 10 users
Appliance Small UTM 3 o COMPACT SMALL UTM o A2SUTM o Small Clusterfrom 8 a 35 users
Appliance Small UTM 3 o Compact Small UTM 3 o A1-Server o Small Clusterfrom 20 a 60 users
A1-Server o Power Clusterfrom 50 a 350 users
A2-Server o APUTM o Power Clusterfrom 100 a 2000 users
A3-Server o APUTM o Power Clusterfrom 100 a 3500/5000 users
A3-Serverfrom 500 a 10.000 users

8. Devices performance analysis

ALIX86,60 Mbps87,10 Mbps0,123 ms86,57 Mbps88,40 Mbps0,122 ms
APU474,00 Mbps735,00 Mbps0,028 ms474,00 Mbps535,00 Mbps0,037 ms
CASUTM595,00 Mbps653,00 Mbps0,033 ms595,00 Mbps535,00 Mbps0,037 ms
AUTM5754,50 Mbps735,00 Mbps0,024 ms551,20 Mbps560,00 Mbps0,035 ms
Power Microcluster939,00 Mbps784,00 Mbps0,029 ms942,00 Mbps784,00 Mbps0,025 ms
APUTM939,00 Mbps784,00 Mbps0,029 ms942,00 Mbps784,00 Mbps0,025 ms
ALIX13,43 Mbps18,00 Mbps0,052 ms12,30 Mbps16,00 Mbps0,048 ms14,67 Mbps20,00 Mbps0,095 ms
APU68,20 Mbps60,00 Mbps0,055 ms58,63 Mbps55,00 Mbps0,073 ms79,33 Mbps68,40 Mbps0,057 ms
CASUTM62,77 Mbps75,50 Mbps0,038 ms56,10 Mbps65,30 Mbps0,064 ms71,93 Mbps87,10 Mbps0,040 ms
AUTM580,20 Mbps94,10 Mbps0,026 ms69,40 Mbps80,25 Mbps0,042 ms97,10 Mbps114,80 Mbps0,040 ms
135,24 Mbps121,74 Mbps0,024 ms116,16 Mbps106,88 Mbps0,031 ms153,79 Mbps138,41 Mbps0,029 ms
APUTM135,24 Mbps121,74 Mbps0,024 ms116,16 Mbps106,88 Mbps0,031 ms153,79 Mbps138,41 Mbps0,029 ms
ALIX15,27 Mbps16,00 Mbps0,105 ms13,73 Mbps14,00 Mbps0,116 ms14,10 Mbps15,00 Mbps0,106 ms8,62 Mbps9,00 Mbps0,089 ms
APU49,00 Mbps70,00 Mbps0,061 Mbps45,60 Mbps54,20 Mbps0,028 ms44,60 Mbps58,20 Mbps0,083 ms26,53 Mbps32,00 Mbps0,051 ms
CASUTM60,13 Mbps67,20 Mbps0,042 ms56,03 Mbps63,20 Mbps0,049 ms56,87 Mbps66,10 Mbps0,057 ms34,43 Mbps37,10 Mbps0,042 ms
AUTM574,22 Mbps80,40 Mbps0,079 ms68,60 Mbps73,50 Mbps0,064 ms69,70 Mbps71,30 Mbps0,074 ms37,80 Mbps40,00 Mbps0,023 ms
109,54 Mbps106,77 Mbps0,039 ms103,72 Mbps96,06 Mbps0,035 ms105,99 Mbps95,01 Mbps0,039 ms62,82 Mbps54,86 Mbps0,024 ms
APUTM109,54 Mbps106,77 Mbps0,039 ms103,72 Mbps96,06 Mbps0,035 ms105,99 Mbps95,01 Mbps0,039 ms62,82 Mbps54,86 Mbps0,024 ms
ALIX15,27 Mbps16,00 Mbps0,105 ms13,73 Mbps14,00 Mbps0,116 ms8,62 Mbps9,00 Mbps0,089 ms
ALIX + Card (*)
48,33 Mbps39,10 Mbps0,061 ms48,07 Mbps39,10 Mbps0,078 ms48,57 Mbps39,10 Mbps0,049 ms
Gain [%]

(*) These measurements were made using the compression hardware module.

  ti posso interessare anche
WordPress Appliance - Powered by TurnKey Linux