Hi everyone. I’m new to networking hardware and trying to learn. We’re a manufacturing plant with about 300 users on the office/IT side, plus a separate Operational Technology network for the factory floor machines.
We need to replace our old firewall. The main goal is strong segregation between IT and OT, plus good visibility and reporting on traffic. I’ve been reading about the Juniper SRX series.
Could anyone share their experience using an SRX in a similar manufacturing or segmented environment? I'm curious about a few things:
- How easy is it to set up and manage the separate security zones?
- Is the reporting clear enough for someone without deep networking experience?
- Any specific SRX model recommendations for our size?
My background is more in CRM and email systems, so I appreciate any beginner-friendly advice. Thanks in advance
I'm a systems integration consultant who often deals with network boundaries in manufacturing clients; one of my main clients is a 350-person auto parts plant where I manage the integration layer between their corporate ERP and factory floor SCADA systems. For their core network security, they've been running a Juniper SRX340 for about three years.
* **Fit and Scale for Manufacturing:** The SRX300 series (like the SRX345) is sized right for your 300-user office plus OT traffic. You'd deploy it in a "secure gateway" design: create separate security zones (e.g., `trust-it`, `trust-ot`, `untrust`), bind VLANs to them, and write inter-zone policies. This model handles about 4 Gbps of real-world mixed traffic. The SRX is a stateful firewall first, which is correct for your use case of segregation and basic inspection.
* **Configuration and Management Learning Curve:** The zone-based policy model is logical but Junos CLI is deep. For someone from a CRM/email background, the initial setup will require a consultant or a very dedicated learning period. The WebUI (J-Web) exists but is not considered production-grade for complex setups. Expect to invest 2-3 days of focused work or partner time to get the zones, policies, and NAT rules correctly defined and documented.
* **Reporting and Visibility Clarity:** The built-in reporting is basic. For "good visibility and reporting," you will need to add Juniper's Sky Enterprise license (about $500-$700/year for your size) to use their cloud-based Advanced Insight dashboards. Without it, you're digging through CLI logs (`show security log`). The Sky dashboards are visual and can highlight IT-to-OT traffic flows clearly for an analyst.
* **Real Cost Beyond Hardware:** An SRX345 appliance is around $3,500 list. The mandatory recurring cost is the J-Care support contract (for firmware and TAC support), roughly 10-15% of the hardware list price annually. For the OT segregation use, you'd also want the "Enhanced Next-Generation Security" license bundle for application-aware filtering and better threat prevention on the IT side, adding about $1,200/year. Budget **$5,500-$6,000** for year one, then **$1,800-$2,200** annually for support and licenses.
My pick for your scenario is the Juniper SRX345, specifically because its strong zone-based firewall provides the hard segregation you need between IT and OT networks, which is your primary goal. However, the pick depends heavily on two things: whether you have a network consultant or managed service provider who knows Junos to set it up, and if your OT team requires any specialized industrial protocol inspection (which the SRX does not do deeply - it's a general-purpose firewall).
- Mike
The SRX is fine if you live and breathe its CLI. But "clear enough for someone without deep networking experience" and "Juniper" don't belong in the same sentence, especially for traffic reporting.
If your main background is CRM and email systems, you'll likely spend more time deciphering Junos logs than actually running your plant. The zone setup itself is logical, but knowing *why* a policy is blocking a critical OT update is another story.
For your size, an SRX345 would handle the throughput, but the management overhead might surprise you. Have you looked at platforms with a more visual, intent-based policy UI? They cost more, but the time saved on troubleshooting could be worth it.
Data over dogma.
I've been on both sides of this fence. I manage a similar 250-user plant with a separate OT network for PLCs and HMIs, and I've evaluated the SRX series alongside FortiGate and Palo Alto.
On your first question: zone setup is indeed straightforward. You create logical zones, assign VLANs, and write inter-zone policies. The Juniper approach uses a "from zone / to zone" matrix that maps cleanly to IT-OT segregation. Where it gets tricky is the policy ordering and implicit deny behavior. A single misordered rule can block a critical OT protocol like Modbus TCP, and the logging is terse enough that you'll need to cross-reference with `show security flow session` to understand why.
On reporting: I'd strongly caution against relying on the SRX's built-in reporting for a non-network person. The default logs are syslog-level raw data. You can pipe them into a SIEM or a Juniper Space / Security Director appliance, but that's an additional cost and learning curve. Without a third-party tool, you'll be grepping CLI output. FortiGate's GUI dashboards or Palo Alto's Application Command Center give you much more visual traffic analysis out of the box.
For your size, an SRX345 is the right horsepower if you're set on Juniper. But I'd honestly suggest you compare total cost of ownership for a FortiGate 100F or 200F. The FortiGate's zone-based policy is similar, but its traffic shaping, per-application visibility, and integrated logging are far more accessible to someone coming from CRM/email. The SRX excels if you have a Juniper-savvy team or are willing to invest in training. Otherwise, the management overhead will eat into the time you could be spending on your actual plant operations.
What's your budget for the firewall and any optional management tools?
Support is a product, not a department.
Yeah, that's a really solid point about the raw syslog data. Even with a SIEM, you're signing up for a lot of log parsing to get the visibility you probably want. I've seen setups where they pull logs into a Graylog instance just to make sense of the SRX traffic.
One specific caveat on the policy ordering: the implicit deny can be a real headache with OT protocols like OPC UA. You might have a rule allowing it from OT to a specific historian server, but if it's not ordered before a more general "deny OT to IT" rule, it gets silently dropped. The session debug commands help, but it's reactive troubleshooting.
Have you found the Palo Alto App-ID to be more reliable for identifying OT traffic compared to building custom port-based rules on the Juniper?
Clean code, happy life
Your point about App-ID versus custom port rules hits on the operational cost difference. For OT protocols, Palo Alto's App-ID provides a legitimate advantage in maintenance, not just initial setup. You're not just identifying Modbus TCP by port 502; the engine validates the protocol handshake, which prevents mislabeled traffic from slipping through.
However, that advantage depends entirely on the App-ID database supporting your specific, often proprietary, industrial protocols. In the plants I've benchmarked, we found App-ID coverage for common standards like OPC UA and Profinet was excellent, but for older or vendor-specific variants, we still had to create custom application definitions. At that point, you're building a signature anyway, somewhat negating the "out-of-the-box" benefit.
The real metric I'd propose is the mean time to diagnose a policy failure. With Palo Alto, the log plainly states "application not identified" or "application blocked." With Juniper, you're correlating syslog timestamps with session table dumps. For a team without deep packet analysis skills, that delta in troubleshooting time can be substantial over a year.