I've been conducting a performance analysis of our WatchGuard Firebox M570 cluster over the past quarter, and I've isolated a significant latency regression that correlates directly with the APT Blocker (Advanced Persistent Threat) feature when applied to HTTPS traffic. Our environment handles a substantial volume of encrypted egress traffic to various SaaS platforms, and the introduction of full HTTPS inspection with APT Blocker has introduced a measurable and, in some cases, operationally impactful delay.
The setup is standard for deep inspection: we have a valid CA certificate deployed to all endpoints, and APT Blocker is configured with what I consider conservative settings—primarily targeting executable downloads and document-based threats over common ports. The policy is applied to specific subnet groups. However, when benchmarking with `curl` from internal hosts to external HTTPS resources and comparing a policy with APT Blocker enabled versus basic HTTPS inspection only, the TLS handshake and time-to-first-byte metrics show a consistent degradation.
Key metrics observed (averaged over 1000 requests):
* **Basic HTTPS Inspection Only:** TLS handshake completion: ~120ms. Time to first byte: ~350ms.
* **With APT Blocker Enabled:** TLS handshake completion: ~190ms. Time to first byte: ~650ms.
* **Increase:** Handshake +58%, TTFB +86%.
The configuration snippet for the relevant policy action is straightforward, but the performance hit is not:
```xml
HTTPS-Outbound-With-APT
HTTPS
enable
enable
enable
enable
```
The system resources (CPU, memory) on the M570 are well within nominal ranges during these tests, peaking at around 65% utilization on the proxy workers. This suggests the latency is not due to resource saturation but rather the intrinsic processing overhead of the APT analysis engine, which likely involves signature matching, heuristic analysis, and possibly cloud lookup integration for each inspected stream.
My primary questions for the community are:
* Has anyone performed similar quantitative benchmarking and observed comparable results?
* Are there specific tuning parameters within APT Blocker (e.g., file type exclusions, cloud-assisted vs. local analysis balance) that have proven effective in mitigating this latency without completely compromising the security posture?
* Is this overhead documented by WatchGuard in any performance sizing guides? Our calculations during procurement were based on raw throughput and connection counts, not this specific feature's impact.
I intend to present these findings to our security team, but I'm seeking corroborating evidence or alternative configurations before recommending a policy change. The security-value-to-performance-cost ratio here needs careful evaluation.
Yeah, welcome to the inspection tax. It's not just the handshake. The real fun starts when APT Blocker decides to buffer and scan that 2GB encrypted backup stream to Backblaze, thinking it *might* be a document. All that data has to be proxied, decrypted, scanned, re-encrypted. Your latency is just the visible symptom.
Also, "conservative settings" on these boxes is often a fantasy. The overhead is in the decryption/re-encryption chain itself, not just the final file scan. You pay for the full ride even if it just waves the traffic through.
Seen teams ditch this layer entirely for specific high-volume SaaS targets after similar benchmarks. Sometimes the "advanced" threat isn't the malware, it's the performance hit.
Your stack is too complicated.