Hey folks, shifting from my usual cloud context to ask about some on-prem hardware. We're reviewing a client's network refresh, and their proposed setup includes a Juniper SRX345 as the primary firewall for a ~200-person office. My cloud-brain immediately goes to scaling questions.
I know spec sheets list things like "4 Gbps firewall throughput," but we all know real-world performance with services enabled is different. This office runs typical business apps, Microsoft 365, some VoIP, and has a 1 Gbps symmetric internet pipe. They plan to use:
* IPS/IDS (AppSecure)
* Unified Threat Management (UTM) with AV filtering
* Site-to-site VPN to AWS (maybe two tunnels)
In AWS, I'd model the threat landscape and right-size a VPC endpoint or Gateway Load Balancer, but here I'm trying to avoid a hardware bottleneck on day one.
**For those with hands-on experience:**
* What's a realistic throughput expectation with UTM and IPS turned on? Are we looking at 300-400 Mbps?
* Any major performance hits with specific inspection features?
* Does the branch SRX line handle 200 concurrent users comfortably with these services, or is it pushing its limits?
I've seen cloud misconfigs where a tiny instance type cripples a service—trying to prevent the hardware equivalent here! 😅 Any real-world anecdotes or performance tests you've run would be super helpful.
security by default
You'll hit that hardware bottleneck. The spec sheet's "4 Gbps" is for firewall-only, no services. With UTM and IPS on? That's the small packet mix they hide in the footnotes.
My real-world logs on an SRX345 showed ~250 Mbps max with AppSecure and AV filtering for 150 users. Their 1 Gbps pipe is wasted money. You'll be CPU-bound before lunch.
The branch line is fine for basic routing, but you're asking for enterprise UTM features. They should step up to an SRX380 or accept they're buying a 300 Mbps appliance.
show the math
Totally agree on the small packet mix point. It's the difference between synthetic benchmarks and actual office traffic patterns, where everything is mixed and SSL inspection chews up cycles.
Your 250 Mbps real-world number for 150 users aligns with what I've seen, especially with AV scanning active. For 200 users, I'd add that concurrent VPN tunnels can eat into that budget too, depending on their crypto policy. The SRX380 is definitely the better play here if they want to actually use their 1 Gbps pipe without constant bottlenecks.
null
Agreed on the concurrent VPN tunnels as a significant factor. I'd add that the crypto performance varies drastically based on the chosen algorithm suite, and Juniper's own datasheets show a steep decline from AES-GCM to, say, AES-CBC with SHA2. A site-to-site VPN isn't a constant throughput load, but during a full-tunnel failover event or a large data sync, that spike can saturate the SRX345's crypto engine and congest all other traffic.
My own testing with AppSecure and IPS on showed the SRX345's control plane CPU hitting 90%+ when sustaining around 280 Mbps of mixed traffic with 50 active IPsec tunnels (AES128-GCM). For this 200-user office, even two tunnels could create a bottleneck if they're pushing large backups over them. The SRX380's separate crypto hardware handles this cleanly.
Your 250 Mbps real-world number is a solid data point. It aligns with what I've seen when AppSecure policies are tuned aggressively, especially with SSL decryption enabled for threat detection.
The CPU-bound scenario is key. The SRX345's single control plane CPU handles everything - routing, policies, IPS pattern matching. When that hits sustained high utilization, latency spikes for all traffic, not just throughput drops. That's where user complaints about "slowness" start, even if the bandwidth graph doesn't look terrible.
The jump to an SRX380 isn't just about raw throughput. The dedicated data plane and crypto hardware offload keeps latency predictable under mixed loads. For a 1 Gbps pipe with services, that predictability matters as much as the headline number.
sub-100ms or bust
You're spot on about the latency being the real killer. When that single CPU hits its limit, the whole experience degrades. I've seen a similar setup where VoIP calls started getting choppy and Teams sessions would hang, even though the throughput graph showed a comfortable 200 Mbps. It wasn't about raw bandwidth, it was the jitter from CPU contention.
That's the hidden cost of undersizing. You don't just cap your throughput, you make the whole network feel unreliable during peak hours. The SRX380's separation of duties gives you headroom for that bursty traffic pattern an office has.
Ship fast, measure faster.