Having just finished a 14-month migration project off a pair of SRX340s that were serving as the hub for three public clouds and two major colos, I feel compelled to weigh in. We replaced them with FortiGate 600Es. The core of the agony was the SD-WAN logic. I see a lot of architects comparing datasheet features, but the devil is in how you operationalize it day-to-day.
Junos is powerful, but its SD-WAN implementation feels like a collection of separate features bolted together, not a unified system. You're manually stitching together service-based forwarding, next-hop groups, static routes with qualified-next-hop, and IPSec tunnels. The logic for path selection and failover is distributed across these config stanzas, making it a nightmare to trace why a particular flow took a bad path. FortiGate's SD-WAN is a dedicated construct from the ground up. You define members, create rules based on performance SLAs or simple priorities, and the intent is centralized.
Consider a simple requirement: "Send all VoIP traffic over the primary MPLS, but if latency exceeds 50ms, fail over to a broadband IPSec tunnel."
* In SRX land, you're looking at configuring a `service-set` for VoIP, defining an `app-track` profile for latency, building forwarding policies, and ensuring your next-hop groups are ordered correctly. The configuration is fragmented.
* In FortiGate, you create a Performance SLA for latency to the target, build an SD-WAN rule matching VoIP traffic, and set the strategy as "Lowest Cost (SLA)". The rule and its conditions live in one logical place.
Here's a sanitized snippet of the complexity from our old SRX config. Just to set up basic path monitoring and a failover route:
```
services {
service-set VoIP-SET {
ipsec-vpn-rules VPN-POLICY;
next-hop-service {
inside-service-interface ;
outside-service-interface ;
}
}
}
routing-options {
static {
route 10.10.0.0/16 next-hop ;
route 10.10.0.0/16 qualified-next-hop {
preference 200;
}
}
forwarding-table {
export NH-SELECT-POLICY;
}
}
```
You then need additional policies for `app-track` and firewall filters to tie it all together. One change could require edits in four different configuration hierarchies.
The FortiGate equivalent is a single SD-WAN rule in the GUI (or a few centralized CLI blocks). The operational clarity is not even close. For a multi-cloud hub where paths and performance are dynamic, this simplicity reduces mean time to repair (MTTR) dramatically. However, be warned: FortiGate's strength here is also a weakness if you need deep, granular control that Junos provides. You trade flexibility for operational simplicity.
My hard-won lesson: If your team is steeped in Junos and you have the cycles to build, document, and maintain a complex, custom SD-WAN fabric, SRX can be molded to fit. If you need the SD-WAN abstraction to be the product's primary function, making daily operations and troubleshooting straightforward for a broader team, FortiGate's model is objectively cleaner. We chose cleaner logic over ultimate flexibility and haven't looked back.
—BW
Migrate once, test twice.