Just made the switch for a small side project. The Meraki subscription was bleeding the budget dry. Got a FortiGate 60F for a fraction of the price, which felt amazing.
But man, the interface is a different world. Things that were one click in Meraki take a lot more digging. Had a rough time just setting up a simple site-to-site VPN and getting the policies right for internal services. The CLI seems powerful, but I'm not there yet.
Anyone else come from a similar "cloud-managed" background? Any key concepts or sections in the GUI I should focus on learning first? I'm determined to make this work, but it's humbling.
I manage infra for a 50-person SaaS shop. We run our core firewall stack on FortiGate 100F's, with a mix of AWS and on-prem workloads.
**Target audience**: Meraki is SMB/small branch office where you rent expertise. Fortinet is for when you have a networking person, even part-time, and want control.
**Real pricing**: The 60F is ~$500-700 hardware. The catch is you still need FortiCare for updates (~$100/yr) and likely FortiGuard for web filtering (~$150/yr). Merano's $2k-3k up-front for an MX, then $700-1k/year in licensing forever.
**Deployment effort**: Meraki: 20 minutes. FortiGate: A solid day for the first one. You're not configuring a device, you're learning an OS. The CLI is faster, but start with the GUI's "Policy & Objects" section. All your firewall rules live there.
**Where it wins**: Raw throughput for the money. A 60F will do 1-2 Gbps of real UTM-inspected traffic. A similarly-priced Meraki won't. You also get actual logs you can query, not just a pretty dashboard.
If you're solo and networking isn't your main job, stick with Meraki. If you have the time to learn one system that can grow with you, the FortiGate pays off. Tell us your team size and if you need to replicate this config to other sites.
Keep it simple
Your point about the logs is critical. Meraki's dashboard abstracts away too much for troubleshooting. With FortiOS, you can drill into the raw event log, filter on source/destination IPs, and actually diagnose why a policy isn't matching. It's the difference between seeing "there's a problem" and understanding the exact sequence of the connection attempt.
The CLI's `diagnose debug` commands are a natural progression from there. When a complex VPN tunnel won't come up, you can watch the IKE phases in real time. That level of visibility is what you're buying control for, but it does require you to build a mental model of the system's internals.
For the original poster, I'd suggest living in the GUI's **Policy & Objects** and **Log & Report** sections exclusively at first. Don't even touch the CLI until you hit a wall. The GUI will show you the structure, and the logs will teach you the flow. Once you see a "Deny" log entry with a "Policy ID: 0," you'll understand why implicit denial is a thing and that's your cue to start building rules.
null