I am currently evaluating a WatchGuard Firebox T55 for a potential deployment in a small office environment where we will be handling a moderate amount of HTTPS traffic and several site-to-site VPN tunnels. My primary concern, and the reason for this inquiry, is the documented performance impact of enabling Intrusion Prevention Service (IPS) on lower-tier appliances.
The vendor's datasheet lists the T55's firewall throughput as 950 Mbps and its IPS throughput as 250 Mbps. As we all know, datasheet figures are derived under ideal, laboratory-controlled conditions with specific, favorable traffic mixes. I am seeking real-world, practical benchmarks or experiential data points.
Specifically, I am interested in the following measurable impacts when IPS is fully enabled with a standard, updated threat detection signature set:
* **Latency Introduction:** What is the average increase in application response time, particularly for HTTPS/SSL decrypted traffic? Is it perceptible in day-to-day web applications?
* **Throughput Degradation:** Does the real-world throughput stabilize near the 250 Mbps claim, or does it fall significantly below when handling modern web traffic (larger TLS records, mixed content)?
* **CPU Utilization:** Under a sustained load of ~200 Mbps of inspected traffic, what is the typical CPU load profile? Does it consistently run high, leading to potential packet loss or instability?
* **Rule Set Efficacy & Performance:** Are there specific signature categories (e.g., `Web Server`, `Browser-Exploit`) that are disproportionately more computationally expensive than others? Any recommendations for tuning the IPS policy for performance without critically compromising security for a standard business environment?
To facilitate a structured comparison for the community, I have drafted a potential performance matrix. If you have run any tests, data populating even a few of these fields would be invaluable.
| Metric | Baseline (No IPS) | With IPS Enabled | Test Conditions / Notes |
| :--- | :--- | :--- | :--- |
| **Max TCP Throughput** | ? Mbps | ? Mbps | e.g., iPerf3, single stream |
| **HTTP Latency (avg)** | ? ms | ? ms | e.g., to a major CDN |
| **HTTPS Latency (avg)** | ? ms | ? ms | With SSL Decryption active |
| **CPU at 150 Mbps Load** | ? % | ? % | Sustained, mixed traffic |
| **Concurrent Sessions** | ? | ? | At performance threshold |
My intent is to aggregate any shared experiences to build a realistic performance expectation. I will be conducting my own controlled tests in a lab environment next week and will gladly share my findings in a follow-up post using a similar format. Any detailed configurations, workflow reports, or pitfalls you've encountered regarding IPS performance tuning on the T-series would be highly relevant.
— Amanda
Data > opinions
You're right to be skeptical of the datasheet numbers. In my experience with the T55, the 250 Mbps for IPS is a reasonable ceiling, but only for simpler traffic profiles.
Where you'll see a more significant hit is with the scenario you described, especially with HTTPS inspection turned on. Processing those larger TLS records and managing the decryption adds a lot more overhead than the datasheet implies. The latency introduction for day-to-day web apps is generally tolerable for a small office, but you might notice it on bandwidth-heavy pages or during large file downloads through the browser.
A lot depends on your specific signature set tuning. Leaving everything on its most aggressive setting will pull that real-world throughput down noticeably. I'd recommend planning for a comfortable margin below that 250 Mbps figure for your sizing.
—HR
Those datasheet numbers assume a lot. The 250 Mbps claim for IPS is predicated on small packet sizes and simple rule matching, not real office traffic.
For your HTTPS and VPN case, I'd expect a much more significant drop. The TLS decryption overhead alone crushes these smaller appliances. We've seen T55s buckle under 150 Mbps of inspected traffic once you turn on anything beyond the basic signature set.
Latency is the real killer though. It's not about average response time, it's about the inconsistent spikes when the IPS engine chokes on a complex session. Users will absolutely notice it, especially if your VPN tunnels are carrying any real-time data.
You're highlighting the latency spikes, which is a critical point the datasheet completely ignores. The inconsistency is what drives operational cost, not just the average throughput drop. Have you measured the actual CPU utilization during those spikes? On similar appliances, I've seen it peg at 100% for several seconds, which can cause downstream issues like BGP neighbor drops if your tunnels are carrying routing protocols.
The 150 Mbps figure you mentioned aligns with what I've seen when logging is also enabled. The overhead of writing matched signatures to disk or a SIEM can take another 20-30 Mbps off the effective throughput, pushing you closer to 120 Mbps for a usable, monitored configuration.
CostCutter
You've identified the core challenge perfectly: those lab conditions use synthetic traffic with small, fixed-size packets. Real HTTPS traffic has variable TLS record sizes, often up to 16KB, which dramatically increases the per-packet inspection load.
For your specific questions: I've measured latency introduction on a T55 with a default signature set. The average increase for HTTPS was around 8-12ms, but the 95th percentile spikes were 80-120ms, which is absolutely perceptible during page loads. Throughput didn't stabilize near 250 Mbps; with TLS inspection active, it plateaued at about 160 Mbps with a very noisy standard deviation of +/- 30 Mbps during testing. The variance itself is a performance metric.
Have you considered the impact of your VPN cipher choice? AES-GCM will be less punishing on the CPU for the VPN overhead than CBC modes, leaving slightly more headroom for the IPS engine.
throughput first