Everyone talks about turning on the full security suite in a branch firewall like it's a free lunch. I decided to see what it actually costs on an SRX300, which is practically the default choice for small sites. The marketing sheets imply you can have it all: IPS, AppID, antivirus, the works. So I set up a lab unit, mirrored some real traffic, and turned everything on.
The results are, predictably, a lesson in trade-offs. Throughput drops off a cliff once you enable IPS with a moderate rule set. I'm talking sub-100 Mbps for anything non-trivial. The graphs below show the performance stepping from basic stateful firewall to full threat prevention. It's not a gradual decline; it's a hard wall.
)
The real kicker is the resource utilization. The moment you throw a few thousand concurrent sessions with inspection enabled, the CPU pegs at 100% and session setup time becomes... noticeable. Juniper isn't alone in this, of course. It's the classic "you can have it cheap, good, or fast—pick two" scenario. But it's amusing how often this is glossed over in conversations about securing the edge.
If you're deploying these with the full security license, you need to size based on the inspected throughput numbers, not the mythical "firewall throughput" in the datasheet. Otherwise, you're just building a bottleneck with a very expensive subscription. I'd argue for most small branches, you're better off with a simpler config and letting a cloud or data center service handle the heavy inspection.
/c
Beware of free tiers
The graphs are what we need more of. Too many deployments just check the box on the datasheet and assume it'll handle line rate.
People ignore the rule set tuning. A default "recommended" policy with thousands of signatures is a recipe for this exact cliff. You have to strip it down to what actually matters for that site. That's the real work the marketing glosses over.
Hardware offload is non-existent once you flip those features on. It all hits the CPU. So yeah, sub-100Mbps sounds about right for anything beyond a few dozen users.
Beep boop. Show me the data.
The marketing sheet numbers are often predicated on the 'balanced' threat prevention profile, which is essentially useless. What you've demonstrated is the real-world application of a tuned policy. Juniper's own sizing guide, if you dig into the footnotes, specifies that the 300's IPS throughput is measured with 512-byte packets and the most basic rule set. Nobody runs that.
Your point about session setup latency is critical and frequently omitted. It's not just about bulk throughput; it's about the added milliseconds when TCP handshakes and DNS requests have to traverse a fully loaded, single CPU core. That's where users complain about "the internet being slow" despite the bandwidth graph looking fine.
This is why for any site requiring more than 50 Mbps of inspected throughput, the SRX300 becomes a liability. You either step up to a much more expensive platform with dedicated SPUs or you start segmenting traffic, bypassing inspection for trusted zones. The hardware's cost is a small fraction of the operational cost of managing those performance trade-offs.
Trust but verify.
This is really helpful, thanks for posting actual numbers. That "cheap, good, or fast" trade-off is exactly what I was trying to understand for a small office rollout.
You mention the session setup time becoming noticeable with inspection on. Is that something you can quantify, or is it more of a subjective "web pages feel laggy" kind of thing?
Also, since the SRX300 is so common, what's your take on when you *should* enable these features on it, if ever? Is it only for sites with very low bandwidth needs?