pfSense Network Security

pfSense Throughput and State-Table Sizer

Estimate state-table RAM and inspection allowances, with CPU and VPN planning tiers to check against your workload.

WAN Connection Speed (Gbps)

Peak State Table Entries (2 states per connection)

Snort / Suricata IDS/IPS Rulesets

Encrypted WireGuard / IPsec Tunnels

Recommended RAM

7 GB

Minimum CPU Cores

4 Cores (AES-NI)

VPN Ceiling · 5 tunnels

2.1 Gbps

How these numbers are derived

The estimates above are built from the figures Netgate publishes in its hardware sizing guidance, not from bench measurements taken here. The three inputs that move the result are the state table, the inspection engine and the cipher, and each has a documented cost.

State table memory

Every connection through the firewall consumes two states, one entering and one leaving, and each state occupies roughly 1 KB of RAM. Netgate's published 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 operating system and its services want at least 175 to 256 MB on top of that, and more once packages are enabled. The RAM figure above is therefore not the bare arithmetic: it is a flat 4 GB base plus 1 GB per million states plus the inspection allowance below, rounded up. The 4 GB base is deliberately generous against Netgate's 175 to 256 MB, because a current install is ZFS by default and because a network buffer pool raised to one million clusters occupies roughly 2.3 GB on its own.

Throughput is packets, not bits

Forwarding cost is charged per packet. The same hardware at the same packet rate produces very different headline bandwidth depending on frame size, which is why a target in gigabits means little without the traffic shape behind it. 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

A network dominated by bulk transfer sits near the bottom of that table. One full of small interactive packets sits near the top of the per-packet cost and nowhere near the top of the bandwidth column.

Inspection and encryption

Netgate names packages that intercept or inspect traffic, such as Snort and Suricata, as the features most likely to reduce total throughput, because the rule set and the per-flow inspection state occupy RAM and the inspection work itself takes CPU time away from forwarding. For VPN traffic the dominant variable is whether the chosen cipher can be accelerated in hardware; accelerators largely eliminate the performance difference between accelerated ciphers, and IPsec with AES-GCM benefits directly from AES-NI.

That maps onto the inputs as follows. The inspection setting adds 2 GB for a standard rule set and 4 GB for a maximal one, against Netgate's stated 1 GB minimum for Snort or Suricata, because the 1 GB figure is the engine's own allocation and not a working total. The core figure is a tier rather than a calculation: four cores once the target passes 2.5 Gbps or inspection is enabled at all, eight at 10 Gbps or with a maximal rule set. The VPN row is a planning ceiling, not a measurement: it allows 15 per cent of the WAN rate for encapsulation and per-packet overhead and assumes a cipher the hardware can accelerate. A single tunnel is flagged separately because a single tunnel carrying one flow typically cannot be spread across many cores, so extra cores raise the total across many simultaneous connections without raising the ceiling for one.

What this estimate is not

It is a starting specification, not a benchmark. Estimating throughput for third-party hardware is difficult and inaccurate by Netgate's own description, and the most reliable comparison points are the published figures for appliances of a similar class. Treat the output as the floor to shop above.