Check Point Quantum 6200/6400 Performance: Testing and Rule Growth

What are you really measuring: speed or stability

When evaluating Check Point Quantum 6200/6400 performance, it’s important to separate two concepts: "fast in the lab" and "stable in the real network." Enabled security profiles (IPS, Anti-Bot, Anti-Virus, URL Filtering, Application Control) change the picture far more than people expect. Part of the traffic goes into deep inspection, load on CPU, memory and the logging subsystem grows, and the "peak throughput" becomes the "throughput under your settings."

For business, the priority is usually not the maximum gigabits per second but stability: so that latency doesn’t spike at peak hours, packets aren’t dropped, and critical applications (telephony, video conferencing, ERP, payments) don’t degrade.

Keep three metrics together:

• Throughput: how much traffic passes with specific profiles and a specific traffic mix.
• Latency: how packet transit time changes under load.
• Packet loss: whether drops, TCP retransmissions and user complaints appear.

Mistakes when comparing models usually start with datasheet numbers. It’s important to clarify the test conditions: without TLS inspection, without detailed logging, without VPN and sometimes with a simplified policy. Another common self-deception is comparing only "gigabits" and ignoring connection setup rate (CPS) and concurrent session counts. For short requests (web, APIs) CPS and the session table often become the bottleneck.

What is often "forgotten" in tests but almost always enabled in production: detailed logging (especially into SmartEvent or an external SIEM), IPS in Prevent mode, site-to-site VPNs and TLS inspection. Simple example: during the day you have 2 Gbps of "visible" HTTPS. After enabling inspection, the device starts decrypting and analyzing content, resource headroom disappears, even though the traffic graph hardly changes.

What inputs to collect before calculation and testing

To make the Quantum 6200/6400 performance estimate reflect reality, first record what the gateway will do in production. If you measure only "TCP speed" on the bench and later enable IPS and inspection, the numbers won’t match.

Start with a list of security profiles and their modes. Details matter: which blades are active, which profile is chosen (Recommended, Strict, Custom), what exceptions are allowed, which categories and signatures must always run.

Separate out TLS inspection. This is the main multiplier of load because it changes the nature of traffic handling. It’s enough to fix two parameters: what share of traffic will be decrypted (percentage) and what portion of that traffic is latency-sensitive (for example, video conferencing or payment terminals). If unclear, collect statistics on top domains, applications and SNI for at least a few working days.

Next, describe the traffic profile: who initiates, where they go, and what the peaks are. The same "1 Gbps" can be light (long flows, few sessions) or heavy (many short connections and high CPS).

Useful inputs to list briefly:

• Peaks by traffic and by new sessions (during work hours and backup windows).
• Traffic shares: office users, servers, branches, remote employees, east-west datacenter traffic.
• Critical applications and allowable latency (ERP, video conferencing, internet banking, medical services).
• Logging policy: what we log, where we send it, retention period, whether detailed URL/App logs are required.
• Network specifics: NAT, VPN, asymmetrical routing, presence of a DMZ.

Logging is frequently underestimated. If you enable detailed logs for URL Filtering and App Control and forward them to centralized storage, load can shift from CPU to disk and log queues, especially at peak times.

An example that helps to "ground" the test: 800 users at headquarters, 12 branches via VPN and a datacenter with ERP and video conferencing. Activity peaks at 11:00 and 16:00, backups run overnight. The lab should reflect these behavior windows, not the "daily average," otherwise the choice between 6200 and 6400 becomes random.

Load scenarios: how to describe traffic without guessing

A load scenario for an NGFW is not "how many gigabits" but a clear description of what actually happens: directions, applications, number of sessions, peaks, and how much is encrypted. Without this the test doesn’t answer the real performance question.

Rely on confirmed data for 2–4 weeks (a month with typical load is better): interface graphs, NetFlow/sFlow, reports from the current firewall, VPN statistics. Record not only averages but short peaks: they often consume CPU headroom and session table entries.

Minimum dataset to collect:

• Average and peak traffic by direction (internet, branches, datacenter, cloud).
• Concurrent sessions and their creation rate (CPS), at least estimates.
• Typical flow characteristics: many small requests (web, DNS, API) or a few large ones (backups).
• Share of east-west in the datacenter and inter-segment crossings through policies.
• VPN: number of site-to-site tunnels and concurrent remote users.

Don’t limit yourself to a single test. Describe 3–5 scenarios where not only Mbps changes but also traffic "character": working day (short web sessions and SaaS), night window (replications and backups), Monday peak (mass logins and CPS growth), failover (traffic shifts to the backup link).

Also fix high-availability behavior. In Active-Standby some resources are used for synchronization, and on failover the load falls on a single device. In Active-Active you need to understand how traffic will split and which flows can’t be evenly distributed. Without these details results may look "nice" but be useless for model selection.

Step-by-step approach to load testing

A load test is not for report numbers only, but to see if the device will handle your peaks with the planned security profiles and SLA for latency. Define measurable goals: what traffic peak and CPS must be sustained, what latency is acceptable, and which services must not be disrupted (site-to-site VPNs, telephony, key databases).

Testbed preparation

Before running tests, fix conditions as close to production as possible, especially when comparing 6200 and 6400.

• Build a reference policy: real networks, NAT, VPN, objects, exceptions, rule order.
• Enable only the security profiles that you plan for production and in the same modes.
• Prepare the load source: a traffic generator or a testbed of real servers and clients so there are "live" sessions and multiple protocols.
• Record software version, logging parameters, TLS inspection settings.
• Define measurement points: where to measure latency and losses (before/after FW, on client, on server).

Runs and measurements

Move from simple to complex to see the "cost" of each function.

• Run 1: baseline traffic without inspections (control level to understand hardware limits).
• Run 2: the same traffic profile with security profiles enabled.
• On each run capture throughput, latency, CPU and memory, drops, session table utilization, and interface errors.
• Separately test "heavy" cases: many short sessions (web), long sessions (RDP/VDI), encrypted traffic.
• Pinpoint the degradation moment: at what traffic or session level latency rises or losses begin.

Then repeat tests with "real-life" logging and increase policy complexity (for example, +30–50% rules). Verify connection setup time and latency remain within SLA.

How to account for security profiles and their resource cost

The main sizing mistake is measuring "naked" throughput and then enabling security profiles and being surprised by the drop. For a realistic assessment of 6200/6400 it’s useful to calculate the cost of functions individually and in combination, because they compete for CPU, memory and accelerators.

How to measure the "cost" of profiles

Start from the baseline: traffic with the same routing and NAT but without Threat Prevention. Then enable functions one by one and note what changes: maximum throughput, latency, CPU load, concurrent connections and CPS.

Most expensive features usually are:

• IPS: Prevent mode is almost always heavier than Detect. The broader the profile and the fewer exceptions, the higher the load. After signature updates it’s useful to run a short control test.
• Threat Prevention: check what is really enabled in your blade set and policy. Sometimes checks are left "just in case," while risk-wise targeted coverage of critical segments would suffice.
• TLS inspection: makes sense where risk is higher (mail, web services, SaaS). For heavy flows (backups, large uploads) targeted exceptions are usually needed, otherwise resources are spent decrypting without practical benefit.
• URL Filtering and App Control: load increases when you actively use many categories and rules, not just by having the blade enabled.
• Logging: detailed logs (especially on Accept) increase load and traffic to the log server. Decide in advance the level of detail, event frequency and storage destination.

What’s often forgotten

Security profiles can’t be evaluated in isolation. Their cost depends on traffic mix (many small sessions vs a few large ones), the number of web apps and the presence of peaks. Record not only averages but behavior during the worst hour and allow headroom for signature updates and an increase in enabled controls.

Calculating rule growth for 3 years: a simple method

To avoid underprovisioning, forecast not only traffic but policy growth. In practice rule count, objects and log volume often consume the headroom and hit performance once security profiles are enabled.

Count growth separately in four buckets: access rules, NAT, objects (hosts, networks, services) and groups. Dynamics differ: objects and groups often grow faster due to new systems, while rules grow due to exceptions and temporary accesses that remain.

Calculation steps (15–30 minutes for a draft)

1. Record current state: number of Access Control and NAT rules, count of objects and groups, average daily log volume.
2. Describe drivers of growth for 3 years: new segments, branches, services, contractors, datacenter/cloud migrations, enabling TLS inspection.
3. Set a pace: baseline monthly growth and occasional project spikes (migrations, branch launches, new systems).
4. Account for complexity: share of exception rules, growth of TLS bypasses, increased logging detail.
5. Tie each bucket to traffic scenarios: how many new flows and events will appear due to changes.

Then create three scenarios and calculate the totals for the end of each year:

• Conservative: +1–2 rules/month, +10% objects/year, no major projects.
• Realistic: +3–6 rules/month, 1–2 project spikes/year, +20–30% objects/year.
• Aggressive: +8–12 rules/month, 3–4 spikes/year, rapid growth in TLS inspection and logs.

How to "translate" rule growth into load: more rules and objects mean more match checks, more group usage, more sessions passing through App Control/IPS/AV, and higher log volume. So tests should account for not only Mbps but also increased match rate, CPS, concurrent sessions and logging.

How to interpret results and choose 6200 or 6400

Look at results as answers to "how stably does the device handle your worst-hour traffic," not as a nice average number. If latency rises at peak, drops appear, and CPU stays near its limit, headroom is already consumed even if average utilization looks "normal."

Compare 6200 and 6400 only under identical conditions: same policy, same security profiles, same application mix, same session characteristics and packet sizes. Different settings easily produce "convenient" numbers that won’t replicate in production.

What to look for in the test report

Record not only throughput but what it costs:

• CPU at peaks (95–99th percentiles are more useful than the mean).
• Latency under load and during bursts of new sessions.
• Concurrent sessions and connection rate.
• Memory and its growth with profiles enabled.
• Logging subsystem: queues and drops when increasing detail.

If you hit CPU limits, most expensive consumers are IPS/Anti-Bot/Threat Emulation and especially TLS inspection.

How to decide

Run an additional test: increase the share of traffic under TLS inspection (for example from 20% to 50% or to the target) and observe CPU and latency. If peak CPU headroom drops below 30–40% or latency noticeably increases, moving to the 6400 is usually justified.

Example: under current policy the 6200 handles the peak, but when TLS inspection is expanded CPU goes to 85–90% and latency rises. That’s a sign that in a year or two (policy growth, more encryption, signature updates) the device will run on the edge. In that case choose 6400 or reduce policy cost: narrow TLS inspection scope, reduce unnecessary logs, add exceptions for low-risk flows.

Common mistakes when assessing performance

The most common reason for a wrong choice is simple: relying on the specification and expecting the same numbers in the real network. In practice, Quantum 6200/6400 performance is almost always defined by what’s enabled and what traffic passes through.

Mistakes that break the assessment

• Comparing raw maximum throughput without accounting for IPS, Anti-Bot, URL Filtering and TLS inspection which reduce throughput and increase latency.
• Testing synthetic traffic (one packet size, one protocol, no encryption) while production is a mix: video, SaaS, backups, short sessions and heavy HTTPS.
• Not counting logging cost: detailed logs, delivery to storage, retention and reporting create I/O and CPU load. The bottleneck ends up in event recording and processing, not filtering.
• Mixing branch and datacenter requirements into one averaged profile. Branches often have many short sessions and VPN, datacenters have large east-west flows. Averages hide peaks.
• Planning growth only by rule count, not related entities: objects, groups, exceptions, NAT, routes, VPN communities. Policy complexity increases and each packet faces more checks.

Short example

A company enables TLS inspection for some users and gradually adds exceptions for banks, government portals and internal services. After a year rules are +20%, objects and exceptions doubled. On a lab test "by rules" everything seemed fine, but in reality match processing and log handling load increased: CPU stayed high and latency fluctuated.

To avoid this trap, record separately: traffic profile (protocols and shares), enabled security profiles, logging requirements and a growth forecast not only for rules but for objects, exceptions and VPN.

Quick checklist before procurement and deployment

Before buying a Quantum 6200/6400, agree in advance which profiles will be enabled on day one and which later. A common mistake is testing pure L3/L4 and then enabling IPS, App Control, Anti-Bot and TLS inspection in production.

Check traffic and encryption inputs:

• Peak Mbps and CPS are estimated, and the share of TLS you’ll actually inspect is known.
• Application types are identified: web, mail, VPN, backups, VoIP, updates.
• "Bad days" are recorded: quarter closes, mass updates, perimeter attacks.

Decide on high availability behavior. Active-Standby and Active-Active behave differently, and synchronization and failover also consume headroom. If the requirement is "survive a failure without noticeable degradation," include that in acceptance.

Acceptance metrics should be recorded and measured consistently in test and pilot:

• Throughput and latency on representative flows.
• Drops, CPU/RAM, session table utilization.
• Stability under load (not 5 minutes but 1–2 hours).

And don’t forget planning horizon. Make three 3-year growth scenarios for rules, objects and log volume. If you currently have 900 rules and add 20 rules per month, in three years you’ll have about 1,620, and logging and storage needs will grow accordingly.

Example scenario: organization with branches and a datacenter

Company with two sites: main office and a datacenter in another city. There are 8–10 branches and some remote workers. Internet bandwidth varies: 1 Gbps at the office, 2 Gbps in the datacenter, plus a 500 Mbps inter-site link. On a typical day 900–1,100 users are active, 200–300 may connect via VPN at peak.

Policies require segmentation: separate zones for users, servers, guest network and contractors. Contractors get access only to specific services (ticketing system and one admin server), and strict east-west rules are applied between user VLANs and the server zone.

Security profiles are enabled almost everywhere: IPS and filtering (URL/Anti-Virus) on all directions. TLS inspection is applied selectively, for example only for finance and several cloud apps to avoid breaking special services and wasting resources where it’s unnecessary.

Load tests for this scenario should be built around real peaks:

• Morning peak: web, mail, updates, SaaS, with branch backups running concurrently.
• VPN simulation: 200–300 simultaneous VPN users and a surge in new sessions.
• Application traffic: latency and jitter for video conferencing, ERP/CRM responsiveness, stability for RDP/VDI.
• Link failover: simulate one internet link dropping in the datacenter and increased load on the remaining link.
• A separate run with TLS inspection on selected categories.

Three-year growth is usually in complexity rather than raw internet speed. Services, segments (for example an IoT/ACS zone) and exceptions appear. Practical estimate is to provision +15–25% rules per year and growth in objects (groups, networks, NATs, exceptions) as branches expand.

If, under enabled profiles, CPU and CoreXL are not hitting limits, there are no packet losses, and video conferencing and ERP latency remain within agreed values, the 3-year headroom looks realistic. If needed, an integrator like GSE.kz can help collect inputs and run a pilot so results reflect your network, not lab assumptions.

Next steps after calculation and testing

After calculations and bench runs, consolidate the result so the same discussions won’t recur in six months. You need a clear answer: will the platform handle real traffic with enabled security profiles and policy growth?

Package results briefly and agree them with InfoSec, operations and service owners. Then follow a clear sequence:

• Approve 2–3 load scenarios as the reference (peak hours, failover, updates).
• Run a pilot on a testbed or in a test segment and fix acceptance criteria.
• Describe a baseline configuration: which profiles are always enabled and which are selective.
• Introduce change control: who adds rules, how reviews are done, when obsolete rules are removed.
• Create a 3-year plan: licenses, HA/cluster, log server, storage.

To prevent the pilot from becoming "looks like it works," define acceptance metrics in advance. Usually 4–5 measurable indicators suffice:

• average and peak CPU and memory under your scenarios;
• latency increase when key profiles are enabled;
• fraction of dropped packets and session stability;
• logging throughput and completeness under load;
• policy install time.

Then continue the routine: monthly control of rulebase growth, quarterly review of obsolete rules, checking log quality and storage consumption, especially with detailed eventing.