Migrated from Sophos UTM to Juniper SRX for a 100-user shop - what broke

I'm Alex Garcia, managing infrastructure for a 250-person B2B SaaS company. We ran Sophos UTM for about five years before switching to Palo Alto firewalls, so I've lived through a similar vendor migration.

My take on a Sophos UTM to SRX move for a shop your size:

**Fit and philosophy:** Sophos UTM was built as an all-in-one SMB/Mid-market appliance. Juniper SRX is a modular enterprise NGFW. You're feeling the difference in unified features versus best-of-breed components.
**Real licensing cost:** The SRX hardware is competitive, but the operational cost hits. At my last shop, building the missing web filtering, caching, and central logging visibility added about $5-7 per user annually in extra licenses and management overhead.
**Configuration mindset:** Sophos uses a "policy decides everything" model, handling NAT implicitly. Juniper uses a "services model" where NAT, security policies, and application objects are explicitly defined and linked. That's why your source NAT needed a matching security policy.
**Where SRX clearly wins:** The CLI and commit model is far superior for predictable, version-controlled changes. HA failover is smoother and faster. Raw throughput for encrypted tunnels (like IPsec) is usually higher on equivalent hardware.

Given you're a 100-user shop, I'd recommend the SRX only if you have a dedicated network engineer who values CLI granularity and plans to build a security fabric with separate best-in-class tools. If you need a single-pane-of-glass for a lean team, stick with an all-in-one like Sophos or FortiGate.

To make a cleaner call, tell us: 1) Is there a dedicated network person on your team? 2) Is web filtering/security logging a compliance checkbox, or is it actively investigated daily?

Your mention of NAT is the hidden cost of moving from an SMB-centric to an enterprise-centric platform. The SRX's explicit security policy requirement for NATed traffic is a classic source of misconfiguration that passes basic connectivity tests but fails under actual load.

We ran into a related performance issue with source NAT pools on SRX340s under moderate load, roughly 150 users. The default `persistent-nat` configuration, while beneficial for some protocols, introduced unexpected session table exhaustion during peak hours. The symptom wasn't a hard outage, but erratic connection timeouts for specific applications. I had to adjust the `address-persistence` timer and implement `port-no-translation` for certain internal subnets to maintain stability. It's worth monitoring your session count per pool.

You might also find that your `unknown-tcp` internal applications are triggering the default `default-logical-system-appfw-rule`, which typically drops that traffic unless you've built an explicit permit rule for it. That one can manifest as sporadic application failures rather than a clean block.

Oh wow, the point about the NAT configuration is super helpful. I'm only just learning about firewall policies in my role, and that "automatic" versus "explicit" difference sounds like a huge trap. When you say you had to define security policies *for* the NATed traffic, does that mean you effectively wrote the rule twice? Once for the NAT translation itself and then another rule to actually permit the traffic after the address change?

Yes, you've hit on a critical architectural difference. Sophos UTM's 'Automatic NAT' embeds the translation logic within the policy rule, making it a single-step configuration. On the SRX, security policy and NAT are discrete processing layers.

You don't write the rule twice, but you must consider the traffic's state at each layer. A source NAT rule translates the packet's source IP, but the firewall session is still evaluated against the `from-zone` and `to-zone` of the *original* source address. The security policy must permit the traffic from the pre-NAT source zone to the destination zone. This separation is powerful for complex scenarios but introduces a point of failure.

For your outbound rule, a common oversight is mismatching the source address object in the security policy. If your NAT pool uses `interface` translation but your policy specifies the internal subnet, it will fail. They must align conceptually on the source identity.

Your code block appears truncated. A complete source NAT for basic outbound traffic often looks like this:
```
source {
pool office-outbound {
address {
203.0.113.1/32 to 203.0.113.2/32;
}
}
rule-set rs1 {
from zone trust;
to zone untrust;
rule r1 {
match {
source-address 192.168.1.0/24;
}
then {
source-nat {
pool {
office-outbound;
}
}
}
}
}
}
```
The corresponding security policy must allow `from-zone trust` `to-zone untrust` with a source address matching `192.168.1.0/24`. Did your initial policies perhaps reference the public NAT pool address instead of the internal subnet?

Exactly, that default `persistent-nat` behavior was a gotcha for us too on our SRX340s. It's fantastic for user experience with things like HTTPS, but it holds those sessions open way too long for internal apps that make thousands of short-lived connections.

I ended up creating a separate source NAT pool without address persistence for our server subnets, targeting just the high-volume, internal application traffic. The trick was using a source-address filter in the NAT rule that matched our server VLANs. That stopped the session table from ballooning during batch jobs.

And you're spot on about the `unknown-tcp` and the default app rule. It's easy to forget because the rule is in the logical system context, not your main security policy. I built a simple permit rule for that traffic and logged it, which showed me exactly which internal ports were being flagged. Turned out to be an old monitoring agent using a non-standard port.

Oh, thanks for sharing that tip about the separate source NAT pool for servers. I hadn't considered splitting the config like that.

>logged it, which showed me exactly which internal ports were being flagged.

That's a smart move. Did you just set up a single 'permit and log' rule for all unknown-tcp traffic? I'm worried about the log volume, but it seems like the best way to discover what's actually happening.

Oh, that point about the "real licensing cost" is so true, and it's often the hidden budget killer in these migrations. While the SRX hardware price looks great on paper, you're absolutely right that the operational overhead of reassembling those integrated features adds up fast.

We saw something similar when we moved a client from an older UTM to a more modular setup. The $5-7 per user annual extra you mentioned lined up almost exactly with what they ended up spending on a dedicated DNS filtering service and a beefier SIEM license to correlate the now-separate log streams. It's the total cost of a *security system*, not just the box.

That said, I think the CLI and commit model you mentioned is the SRX's saving grace for manageability long-term. Once you've built those explicit components, having that version-controlled, predictable change process makes complex tuning, like the NAT adjustments others mentioned, so much less stressful. It's just that initial build-out that's a bear!

You've nailed the hidden project cost that rarely makes it into the initial TCO spreadsheet. It's never just the hardware swap.

Your point about the CLI and commit model being a long-term win is absolutely key. That structured, repeatable process is a lifesaver when you're knee-deep in the kind of fine-tuning this thread is discussing, like those NAT pools and app overrides. The initial pain of building those explicit components from scratch gives you a clean, documented foundation.

My caveat would be that the value of that model depends entirely on who's managing it. For a team that lives in the CLI, it's a superpower. But for an SMB shop where the firewall is managed by a generalist, that initial complexity can become a permanent operational burden. I've seen clients pay that "hidden tax" not just in extra licenses, but in expensive consultant hours every time they need a simple policy tweak.