Every router, firewall, and UTM gateway ships with a throughput figure. It's on the box, on the spec sheet, and in every vendor comparison table. It is also, in most real deployments, almost completely irrelevant.
Image description
This isn't a niche complaint. It's a structural problem with how network appliance performance is measured and marketed — and understanding it matters whether you're buying a home router or specifying a UTM for a branch office.
The measurement problem
Throughput figures are measured in labs, under controlled conditions, with minimal configuration. The analogy: electric vehicle range ratings. Manufacturers advertise range under ideal conditions — flat roads, constant speed, no climate control. Real-world range is routinely 30–40% lower. Network appliance throughput is the same.
Part 1: Routers
Routing table size
A router with 10 static routes makes forwarding decisions almost instantly. A router running full BGP may carry 900,000+ routes. Spec sheet figures: measured with minimal routing tables.
Dynamic routing protocols
OSPF, BGP, RIP consume CPU cycles continuously. Under active protocol load, fewer cycles are available for packet forwarding. Spec sheet figures: measured with static routes.
The upshot
There is no correct single throughput figure for a router. There is a figure for a specific routing table size, specific protocol load, and specific traffic pattern.
Part 2: Firewalls
Ruleset complexity
Rules are evaluated sequentially until a match is found. A packet matching rule 400 costs 400 evaluations. Spec sheet figures: measured with minimal rulesets.
State tables
Lab test: ~100 concurrent connections, clean state table
Your network: 10,000–100,000 concurrent connections
Spec sheet figures: measured with minimal concurrent connections.
Part 3: UTM gateways
SSL inspection
A UTM rated at 1 Gbps throughput may deliver 200–300 Mbps with SSL inspection enabled. Some vendors publish this. Many don't.
The compounding effect
Firewall only: ~1 Gbps (lab figure)
+ SSL inspection: ~300 Mbps
+ Antivirus: ~200 Mbps
+ URL filtering: ~180 Mbps
+ WAF: ~150 Mbps
These are illustrative, not measured figures — the point is the direction of travel.
Part 4: How CacheGuard handles this honestly
CacheGuard is a free, open-source UTM gateway OS that runs on commodity x86 hardware. It integrates NetFilter, Squid, ClamAV, ModSecurity, StrongSwan, and IPRoute2 into a single appliance with a web-based admin interface.
It doesn't publish a throughput figure. Performance depends on which features are active and the underlying hardware. At installation, the appliance is configured for the expected capacity of the network it will serve. If traffic increases abnormally beyond that configured capacity, the appliance starts blocking connections.
This is not a throughput problem. It's the appliance doing what it was configured to do: protect a network that was provisioned for a defined capacity.
📖 Original article: cacheguard.com/network-appliance-throughput
What to actually ask when evaluating a network appliance
Instead of "what is the throughput?", ask:
- What is the throughput with all intended features enabled?
- What is the throughput with SSL inspection active?
- How does performance scale with ruleset complexity?
- What is the maximum concurrent connection count before degradation?
Summary
| Device type | Key throughput variables |
|---|---|
| Router | Routing table size, dynamic protocol load |
| Firewall | Ruleset complexity, concurrent connections |
| UTM gateway | Active features, SSL inspection load, traffic profile, hardware |
The throughput number on a spec sheet answers the wrong question. Any vendor who tells you otherwise is selling you something.
👉 cacheguard.com — free, open-source UTM gateway
📖 Documentation
💬 Community forum
🔗 GitHub
Top comments (0)