NexusSec.A familiar story: a new firewall goes in, someone enables intrusion prevention and TLS inspection, and on Monday the internet feels slow. The features are turned off "for now", and the firewall spends the next three years as an expensive router. The cause is rarely a fault. It is a sizing decision made against the wrong number.
Why security features cost throughput
Passing a packet based on its addresses and ports is cheap. Everything a next-generation firewall adds is more expensive: identifying the application means reassembling the stream, intrusion prevention means matching it against signatures, malware scanning means rebuilding files, and TLS inspection means decrypting and re-encrypting every session. Each of those is real work for the processor, and the work grows with the amount of traffic.
Stacked engines and single-pass inspection
One way to build a firewall is to chain separate engines: the packet passes the firewall engine, then the IPS engine, then the antivirus engine, each decoding the traffic for itself. It works, and it is how many products grew as features were added over time. Its cost is that the same traffic is unpacked several times.
A single-pass design decodes the connection once, identifies the application, user and content, and runs the security checks against that one decoded stream. The aim is that switching on another check adds less load than adding another engine would. Vendors approach the problem differently: Palo Alto Networks describes its design as single-pass parallel processing, Fortinet offloads work to its own security processors, and Sophos uses a fast path for traffic that has already been inspected and trusted. What matters to you is not the label but the measured throughput with your features enabled.
Size on the number that matches your configuration
Datasheets usually lead with plain firewall throughput, measured with nothing inspected. Further down are the figures that matter: throughput with intrusion prevention, with the full threat-protection set, and with TLS inspection. These can be a small fraction of the headline. Our guide to reading a firewall datasheet goes through each line.
- Decide which features you will run on day one and which you expect to add within the life of the box.
- Find the throughput figure measured with that set of features, and check the test conditions in the footnotes.
- Compare it with your internet bandwidth and the traffic between internal zones that the firewall will route, not just the internet link.
- Leave room for growth: bandwidth goes up during a firewall's life, and the box will not get faster.
Test before you trust
If you can, run a pilot with your real traffic and the features switched on, and watch processor load and latency during the busiest hour of the week. A firewall that is comfortable at 9 pm and saturated at 11 am on month-end is undersized, whatever the datasheet says. If a vendor offers a proof of concept, ask for it with inspection enabled.
A note on NXSgate
NXSgate, the firewall NexusSec is building, is designed around single-pass inspection at every zone boundary. It has not been released, and we do not publish performance figures for it. Everything above applies to whichever firewall you are choosing today.
