Maximum throughput figures in datasheets may not represent real project performance when multiple security services are enabled. Internet speed should be evaluated together with concurrent sessions, application traffic, SSL inspection and VPN load.
Services such as IPS/IDS, web filtering, application control, DNS security, anti-malware and SSL inspection consume appliance resources. The features that will actually be enabled should be defined early.
For site-to-site VPN, remote-access VPN and multi-site designs, tunnel count, user count, authentication and MFA requirements affect sizing.
If high availability is required, appliance pairs, connectivity and failover scenarios should be designed separately. Sizing should include reasonable headroom for expected growth.
Actual sizing, licensing, security or architecture decisions should be based on the existing environment, vendor support conditions and project requirements.
No. The guide explains general evaluation criteria. Actual product, license or architecture decisions should be based on the existing infrastructure and a requirements assessment.
User/device counts, current products or infrastructure, capacity, license terms and expected growth information can speed up the quotation process.
Firewall sizing should use actual traffic with intended inspection, VPN, TLS and HA features, rather than headline throughput. Concurrent sessions, connection rate and small-packet behavior matter alongside link speed. Compare Sophos, FortiGate, Check Point, Palo Alto and Linux-based options against the same requirements.
For an illustrative 500 Mbit/s link, test peak traffic with security profiles enabled. Run web use, VPN and backup together. After losing one HA node, measure remaining capacity and session behavior; do not choose a model solely from user count.
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Speed tests pass but peak access degrades | Small packets, TLS load, session limits or logging queues may constrain performance. | Measure CPU, sessions, drops and p95 latency under a representative peak mix. |
| Expected legitimate operation is blocked | Rule scope or exceptions may match incorrectly; disabling the entire control hides the cause. | Inspect decision logs for one test identity and resource, and reproduce the condition in a pilot. |
| Access persists after policy changes | Existing sessions, tokens or alternate access paths may have different enforcement timing. | Test new and existing sessions separately; verify that direct access cannot bypass enforcement. |
| Alert exists but cannot be investigated | Missing fields, clock differences or collection gaps can prevent correlation. | Match source and central records, and demonstrate end-to-end traceability. |
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
The guide is based on evaluation criteria used by Doz Teknoloji's technical team when reviewing enterprise firewall and network-security requirements.
About Doz TeknolojiSizing is reviewed across real traffic, enabled security services, VPN, SSL inspection, session capacity, interfaces, HA and growth headroom. The guide is cross-checked against NIST, CISA and vendor technical documentation.
The purpose is to help teams avoid selecting a firewall only by internet speed and instead consider real capacity requirements while security services are enabled.
Primary sources and firewall-sizing criteria were reviewed again.
Continue with the relevant technical guide, product/licensing page or project scenario.
Explore the related service and solution pages to plan implementation.
Share your current infrastructure, users or workload information so product, licensing or project scope can be clarified around your requirements.
Start a Technical Request