Enough. Not more.
A starting point for your own hardware, not a performance promise. Final sizing is confirmed during the assessment, because real load follows the features you turn on.
Your box, or ours
The insides are the same: same software, same configuration, same support contract. The only difference is who decides the specification of the box. The appliance cannot be ordered yet.
| Scale | CPU cores | Memory | Storage | Notes |
|---|---|---|---|---|
| Up to 25 users | 2 | 8 GB | 128 GB SSD | One small office or clinic. Enough for firewall, VPN and DNS filtering. |
| 25–100 users | 4 | 16 GB | 256 GB SSD | Turning on IDS/IPS here costs memory, not extra cores. |
| 100–500 users | 8 | 32 GB | 512 GB SSD | Start considering an HA pair. Storage grows with logs and reporting. |
| 500+ users or data centre | 8+ | 64 GB | 1 TB SSD | Designed case by case. Throughput follows the network cards and rule count, not the user count. |
Every row assumes a CPU with AES-NI. Without crypto acceleration, IPsec and WireGuard throughput drops several times over, and no core count recovers it.
What actually moves the number
A single-line throughput figure is almost always measured at best case: large frames, no rules, no inspection. Your real load is not that. Here is what changes it, and which way.
- Frame size
- The largest effect and the most often hidden. A 64-byte frame forces the device to make decisions far more often than a 1518-byte frame at the same bandwidth. Published vendor figures are nearly always large frames.
- Firewall ruleset size
- A handful of rules barely registers. Dozens with complex matching does. What matters is not the count alone but how many have to be evaluated before a packet matches.
- IDS/IPS enabled
- Inspection forces every packet to be read for content, not just headers. It demands memory and cuts throughput far more sharply than adding cores recovers.
- State count
- Thousands of concurrent connections demand memory, not CPU. This is the one usually mis-measured: the device holds up in a synthetic test, then runs out of state table at a real busy hour.
- Tunnel encryption
- IPsec and WireGuard depend on crypto acceleration in the CPU. A processor without it can drop by several times over, and that is invisible from the core count.
We do not publish throughput figures because we have not measured them ourselves on units we run. Numbers borrowed from another vendor would not describe your configuration, and presenting them as our measurements would be the easiest lie for you to check. At the assessment we measure against your load.
The part most often gotten wrong
- Use server-class chipsets
- Server-class Intel and Chelsio cards behave most consistently. Cheap consumer cards are a common source of packet loss that is painful to trace.
- Avoid USB interfaces
- USB adapters do not belong on a production path. Not even at a small site.
- Leave one port spare
- One idle interface saves you the day you need out-of-band management or a second WAN.
- SSD, not a memory card
- Logs and reports write constantly. Cheap flash wears out sooner than you expect.
Being compiled
We only list units we actually run in production, with versions and the problems we hit. That list is not ready, so it is not up. Meanwhile, send the specs you are considering and you get an honest read.