Choosing an NGFW for Real Traffic: Performance Assessment

Why the “gigabits in the brochure” are often not about your network

NGFW specs usually list three numbers: throughput, concurrent sessions and CPS (connections per second). The problem is these figures are often measured under conditions far from your real network: large packets, simple rules, minimal checks, no encryption and no heavy security profiles.

When you enable IPS, antivirus, application control or SSL/TLS inspection, the device stops acting like a “fast router.” It has to parse traffic, assemble flows, match signatures, apply policies, write logs, and sometimes decrypt TLS to inspect content and then re-encrypt it. In practice that means the “gigabits in the brochure” can easily turn into very different numbers.

Performance issues rarely look like a complete failure. More often they are a set of symptoms: latency increases, micro-losses appear, VoIP and video stutter, VPN becomes unstable, users complain of a “slow internet.” A worrying sign is when an admin is forced to temporarily disable inspection or simplify policies to “get speed back.”

Belief in datasheet gigabits often leads to decisions that are expensive to correct later. For example, choosing a model with no headroom for traffic or rule growth, planning to enable SSL inspection “later” while the hardware already can’t handle it, or sizing only to average link load and ignoring peaks and CPS. Another common mistake is testing “light” traffic in the pilot and then being surprised in production.

If choosing an NGFW for real traffic matters to you, treat datasheet numbers as a starting point, not a guarantee. Real assessment starts when you reproduce your conditions: your applications, your peaks, your security policies and, importantly, your share of TLS traffic.

What actually “eats” performance in an NGFW

Datasheet numbers often show performance for “bare” filtering by IP and port. In real networks an NGFW usually runs multiple functions: application control, IDS/IPS, antivirus, URL filtering and sometimes sandboxing. Each module adds processing and queues, so “10 Gbps firewall throughput” can easily drop to 1–3 Gbps with the full feature set. That’s why choosing a device by a single brochure line is risky.

Where CPU goes and why it’s not just “signatures”

The heaviest operations are those where the device must understand what it’s seeing, not just pass packets.

Typical resource consumers:

• session assembly and reassembly (especially with many short connections);
• unpacking and parsing content (archives, Office/PDF, attachments);
• IPS checks: signature matching and additional contextual checks;
• application and URL classification when deeper inspection is required.

Load grows not only from raw bandwidth but from traffic structure. 500 Mbps of large downloads and 500 Mbps made of thousands of short HTTPS sessions stress an NGFW very differently.

Why latency and loss matter, not just “speed”

Even if an NGFW shows the right megabits in a test, users can still experience hangs. The cause is often increased latency and micro-losses: queues overflow at peaks, even if the average load seems fine.

Example: video calls, cloud sync and updates all start at once. The link may be only 60–70% utilized, but the NGFW hits limits in session counts and inspection depth. Critical apps feel the delay first.

Another trap is rule and object growth. The more policies, groups, exceptions, security profiles and routes you have, the more checks are performed for every new session. So in a pilot it’s important to test a configuration close to production, not “one nice policy.”

SSL inspection: the most common source of surprises

SSL/TLS inspection (often called “HTTPS decryption”) turns the NGFW from a header filter into a system that must decrypt a stream, run it through rules (IPS, antivirus, URL filter, DLP—whatever is enabled) and then re-encrypt. This is heavier than normal filtering: cryptographic operations, session handling and state for a large number of connections are added.

It’s important to distinguish two modes. Outbound inspection (users to the Internet) typically generates the heaviest load: many sites, many short connections, constantly new TLS sessions. Inbound inspection (traffic to your services) is usually steadier in profile, but requirements for latency and availability are higher and misconfiguration hurts availability more.

Performance depends on details the brochure gigabits don’t show:

• share of HTTPS and number of new connections per second (CPS);
• TLS versions and cipher suites, and exception logic;
• certificate chain size and complexity, caching and check frequency;
• which checks run after decryption (IPS and antivirus are usually heavier than simple application control).

A typical reaction to initial problems is to “temporarily” disable inspection for categories like updates, cloud services, video or whole subnets. Speed returns, but blind spots grow: malicious downloads and phishing in HTTPS pass unchecked, and incidents become “unexplained.”

To make a pilot honest, decide in advance what you will decrypt and what you will consciously exclude. For example, you can enable inspection for web surfing and downloads but exclude banking portals and some corporate SaaS for compliance. Then measure not only Mbps but also latency, CPS, TLS session break rates and CPU load during peak hours.

Traffic parameters that matter more than link bandwidth

Saying “we have a 1 Gbps link” sounds clear, but for an NGFW that says very little. The firewall counts not only megabits but how many connections you have concurrently, how often they’re created, what applications are inside, and whether deep checks are required (IPS, AV, app control, SSL inspection).

Mixed traffic is always heavier than “smooth” traffic. In the same office there can be video calls, cloud access, branch VPNs, web browsing, remote access and file sync. By megabits this might be “only” 300–400 Mbps, but in processing complexity for the NGFW it can be like a full gigabit or more.

What in traffic truly loads the NGFW

Short, frequent sessions are usually worse for performance than one long stream. Web pages, mobile apps and many cloud services create many small requests. Backups and updates create long flows that are easier to handle, even if they’re heavy on bandwidth.

Useful metrics for load assessment:

• CPS (connections per second);
• concurrent sessions;
• average packet size (small packets add overhead);
• share of traffic subject to heavy profiles (IPS/SSL/AV);
• direction balance: north-south (Internet) vs east-west (between segments, branches, VPN).

Peaks matter more than the average

Average daily load often soothes and misleads. The NGFW must handle peaks: morning logins, end-of-day uploads, mass mailings, scheduled updates, and occasional incident-driven spikes.

Example: at 9:30 everyone opens mail and CRM, video calls run to branches over VPN, and workstation updates start. Bandwidth may not spike dramatically, but CPS and concurrent sessions can jump many times. If your pilot only tests raw throughput with iperf, you’re testing the wrong thing.

Prepare for the pilot: what to collect before powering the device

Treat the pilot as a small project, otherwise you’ll get neat numbers but surprises after rollout.

First, document real scenarios in your network. A common mistake is testing only internet access and forgetting east-west traffic, data center access and VPN. If you have branches, remote users, separate zones (office, server room, Wi‑Fi, guest), each zone needs its own latency and availability expectations.

Next, list the functions you definitely plan to enable in production. If your pilot tests a “clean firewall” and you later add IPS and SSL inspection, the pilot is meaningless. Choose the exact set of policies: which web categories to filter, which IPS profiles, whether to inspect attachments, and whether unknown-file analysis (if offered) is needed.

Define measurable success criteria before launch. They should be concrete, not just “it shouldn’t slow down”: allowable extra latency on key apps, no noticeable VPN drops, stable operation without queue growth or errors, and acceptable drop rates during peaks.

Gather baseline network data to compare “before and after”:

• NetFlow/sFlow for a typical week (peaks, averages, top apps and directions);
• current gateway stats (CPU/memory, sessions, CPS, interface volumes);
• incident and block logs (what is already being caught, known false positives);
• route and zone map (NAT, east-west, critical services);
• a “gold list” of 5–10 critical business applications to check.

Agree in advance pilot rules: run on real traffic (or on a mirror but with identical security profiles), take measurements in comparable time windows, and log any “easings” (disabling SSL, simplifying IPS) as separate scenarios, not as the final result.

Step-by-step: how to run a correct NGFW pilot

The goal of a pilot is not to see maximum numbers but to understand how the solution behaves in your network with IPS and SSL inspection enabled.

1) Deploy the pilot as it will run in production

Decide how to put the device on the path. Mirroring is safe and convenient but doesn’t show real latency or failure behavior. Inline deployment gives an honest picture; a parallel-path setup helps compare routes and policies.

Port the key rules and routing without “cosmetic” simplifications. A frequent mistake is simplifying policies during the test or excluding subnets. The pilot then becomes too light and misleading.

2) Enable features in stages and record changes

Practical sequence:

• basic filtering and NAT (to let traffic flow);
• application control and basic user policies;
• IPS on key directions (Internet, east-west);
• SSL inspection first on a small group, then wider;
• additional checks (AV, sandbox, DNS filter) if planned.

Keep equal observation windows between stages (for example, 1–2 working hours) for fair comparisons. Simultaneously run typical workloads: video conferences, CRM/ERP, file sharing, mail, backups, mass updates. Prefer usual busy times (morning, lunch, end of day) for testing.

Agree on which metrics to collect and from where. Common metrics: latency and loss, CPU and memory, active sessions, CPS, VPN establishment speed and page load times for representative sites.

The result should be a “before/after” table for each stage and a sizing conclusion: which mode runs without degradation, where peaks occur, and what headroom remains for growth.

Common mistakes and traps when evaluating performance

The most frequent pilot failure is measuring something different from production. The NGFW “holds gigabits” in a throughput test, but after enabling IPS and SSL inspection it starts dropping packets and increasing latency.

Typical patterns:

• testing only raw throughput (e.g., iperf) and ignoring real checks and logging;
• using simplified policies with broad allows and exceptions;
• testing during quiet times and missing heavy periods (updates, video calls, backups);
• forgetting VPN and the cost of encryption/decryption;
• looking only at “speed” and ignoring latency, losses and stability under load.

A subtle trap is “tight sizing.” Today everything works, and in six months new services, a higher TLS share or additional IPS rules erase the buffer.

Minimum monitoring set:

• average and 95th percentile latency on key directions;
• drop/error rates and overload signs (queues, CPU growth, exhausted sessions);
• session establishment speed and max concurrent sessions during peaks.

Short checklist: is capacity enough for you

A quick “download at max speed” test tells almost nothing about IPS, SSL inspection and real user sessions.

If you don’t have concrete numbers for two or three of the points below, the risk of under-sizing is high:

• recorded peaks for concurrent sessions and CPS, not only average link usage;
• testing with the heavy profiles enabled in the exact combination that will be used;
• SSL inspection tested on real scenarios (browsing, portals, updates, messengers, video), not a single test site;
• measured latency and loss before and after enabling security policies (latency, packet loss, jitter);
• a clear headroom plan for 12–24 months for CPU, memory and session tables.

Also verify services that often break under inspection and filtering: online banking, government portals, medical systems, EDI, portals with client certificates. Check not only “opens/doesn’t open” but stability over a working day.

Capacity is “enough” when peak hours leave headroom, critical services run without surprises, and latency doesn’t degrade user experience.

Practical example: a pilot for an office with branches and VPN

A company with 400 employees: headquarters, 6 branches, a shared Internet link and permanent VPN tunnels. During work hours there are video calls, cloud services, mail, updates, plus accounting and CRM. “There is enough bandwidth,” but security needs strengthening: enable IPS everywhere and SSL inspection for some categories (unknown sites and file sharing), while excluding banks and government resources.

The NGFW is placed inline at the head office and branch traffic is mirrored via VPN to make the test realistic. The first stage enables only basic functions to get a clean baseline, then workloads are added one by one.

A couple of days measure traffic profile without heavy checks, then IPS is enabled on key rules, and only after that SSL inspection is added for selected categories. Measurements are taken during peak hours (typically 10:30–12:00 and 15:00–17:00), not at night.

The team records not only megabits but also bottleneck symptoms: CPS on web and during mass updates, queue growth and drops on interfaces, increased latency (especially visible on video), CPU usage from IPS and SSL, and behavior during spikes (throughput drops and recovery time).

In this case the surprise came from CPS spikes and SSL: after enabling decryption for some users latency rose and CPU hit peaks, though average utilization seemed acceptable. Graphs showed short throughput drops and increased response times when many attachments and updates started.

Outcome: they built headroom into capacity and distributed functions by policy instead of enabling everything for everyone: SSL inspection is applied where it provides the most value, IPS stricter for inbound and east-west traffic and relaxed for trusted directions, and branches get separate rules and limits so one office doesn’t consume all resources.

If an integrator supports the pilot, agree in advance which metrics mean “red zone,” so decisions are based on data. In Kazakhstan, GSE.kz handles such tasks as a system integrator: from pilot methodology and measurements to deployment and ongoing support.

Next steps: fix sizing and move to deployment

After the pilot don’t just say “it works”; lock results into numbers and the conditions under which they were obtained.

Translate expectations into measurable requirements. Describe key scenarios (office Internet, VPN, cloud access, east-west traffic), enabled functions (IPS, SSL inspection, antivirus, app control) and 3–5 KPIs to avoid drowning in detail: minimum stable throughput in peak hour with protection enabled, maximum acceptable latency for critical apps, allowable share of dropped sessions and tunnel breaks, and headroom for CPU and memory in peaks.

Document the methodology. The report should let anyone repeat the measurements and obtain comparable figures: which policies are enabled, which exceptions were made (e.g., domains excluded from decryption), which test suite ran, where metrics were captured (on the NGFW and on clients), and what was considered “normal.” If two solutions are tested under different rules, comparison is unfair.

Build in headroom and a scaling path. Don’t rely on today’s average load. Estimate growth in users, remote work, TLS share and new services. Often it’s wiser to pick a model with a 20–30% buffer and decide up front how to expand: clustering, HA, or role separation (for example, a separate node for SSL inspection or VPN).

Before deployment prepare a short artifact pack: final sizing with assumptions (peak traffic, TLS share, feature set), a policy and exception matrix for SSL inspection, an HA and failure-test plan, a phased deployment plan and acceptance criteria.

If your team lacks time or experience, engage an integrator. The goal is not to “measure gigabits,” but to produce a reproducible methodology and final sizing that will hold up under real load.