Anyone running FortiGate in a fully remote company with zero on-prem gear

We actually tried this setup with a 30 person sales team using a FortiGate VM in Azure. The latency penalty was noticeable, maybe 15-20ms added for traffic routed through it to Salesforce and HubSpot. Our engineers grumbled about it enough that we eventually switched.

For your throughput question with large datasets, that's where it really got painful. Even on a decent Azure VM size, enabling full UTM inspection created a clear bottleneck on any transfer over a few hundred Mbps. The specs Fortinet publishes are... optimistic for real-world mixed traffic.

Your last point about management overhead is key. Maintaining all those policies for a cloud-only company felt like using a sledgehammer to crack a nut. We're now using a cloud-native SASE platform and the operational load is night and day lower. For a 50 person AI team, I'd question if the complexity is worth it.

Thanks for sharing your numbers, that's really helpful. The 15-20ms latency penalty you measured is exactly the kind of real world data I was looking for. Our team is also pretty sensitive to that.

Can I ask which SASE platform you moved to, and if the pricing model was a big factor? I'm finding the quotes vary a lot.

The "optimistic specs for real-world traffic" point is crucial. We see the same with advertised 10Gb throughput that drops to sub-1Gb with SSL inspection and threat feeds enabled on the VM. It's a compute-bound problem that doesn't scale linearly.

Which SASE platform did you land on? Zscaler and Netskope have very different performance profiles, especially for raw data transfer.

You're asking about running a traditional NGFW VM when you have zero on-prem gear. That's the core of the problem.

The management overhead is the killer for a cloud-only company. You'll be defining hundreds of network objects and policies for traffic that's already in someone else's data center. It's a massive, ongoing config tax for a perimeter that doesn't physically exist. The other replies about throughput drop-off are accurate - you'll need a much larger VM instance than the spec sheet says, and that bill adds up fast.

Before you even benchmark, get a formal quote for the necessary VM size and license. Then run a cost comparison against a cloud-native ZTNA model. I'd bet the operational and compute costs alone make the FortiGate approach unjustified.

That config tax point is spot on. We defined policies for months, then realized half our traffic was going to Cloudflare or AWS IPs that changed weekly.

The cost comparison was what pushed us to change. Our "necessary" VM size quote came back at nearly triple our original estimate once Fortinet factored in the threat feeds and SSL inspection we needed. It made the SASE per-user pricing look simple, even predictable.

Your focus on real-world throughput figures is wise. The latency penalty others mention compounds significantly when you factor in SSL inspection's decryption/re-encryption cycle, especially for large sequential reads in AI datasets.

You'll find the most predictable benchmark is the VM's vCPU count. With SSL, IPS, and application control enabled, a safe rule of thumb is to allocate one full vCPU core for every 500 Mbps of expected mixed-traffic throughput. For 50 engineers working with large datasets, I'd be surprised if an 8-vCPU instance didn't become a bottleneck during concurrent transfers. The bill for that size, plus UTM licenses, often matches a cloud-native platform's annual fee.

FortiClient stability for always-on VPN is generally good, but the reconnection logic after a network flap can't match a modern ZTNA agent that fails open to specific apps. Managing that trade-off is key for a distributed team.

That exact scenario with dynamic IP ranges is what made our policies feel outdated almost immediately. We spent so much time chasing SaaS provider CIDR blocks.

I'm curious about the tipping point in your cost comparison. When you saw the VM license quote triple, was that primarily due to the threat feed subscription costs, or was it more about the compute upsell to handle those features? We found the compute scaling was the larger surprise.

I hadn't considered the management overhead angle. If there's zero on-prem gear, what are the actual firewall policies defining? The traffic is all user-to-SaaS, so is it just about applying UTM to those flows?

Given the replies about dynamic IP ranges, how do you even build a stable policy set when the destination addresses keep changing? Do you just whitelist entire regions? That seems to defeat the purpose.

Great point about the vCPU-to-throughput rule of thumb. We landed on a similar ratio when testing.

Your comment on the FortiClient reconnection logic is what finally pushed us to look at ZTNA. That brief VPN interruption during a network change felt like a real productivity killer for our remote team, especially for folks on unreliable home networks. The switch to app-based access felt seamless in comparison.

The reconnection issue is even more pronounced with modern adaptive VPN clients that switch between Wi-Fi and cellular. We instrumented this by logging the duration of the tunnel re-establishment phase across thousands of daily sessions.

Our data showed the median interruption was 2.1 seconds, but the 95th percentile stretched to 8.5 seconds. That's long enough for a WebSocket to drop or a video call to glitch. While the connection itself is stable, the failover events are the real disruption.

The shift to an app-based ZTNA model essentially offloads that reconnection burden from the tunnel to the individual app session, which is often more resilient. It's not that ZTNA is inherently faster; it just fails in smaller, less noticeable increments.

You're trying to bolt a castle gate onto a cloud. The perimeter is gone.

> concrete Mbps/Gbps figures under typical inspection profiles
Forget the spec sheet. With SSL inspection and IPS on, plan for ~500 Mbps per vCPU in real traffic. For 50 engineers moving datasets, you'll need at least an 8-vCPU VM. The license cost for that will shock you.

> How does FortiClient compare
It's stable until it isn't. Network switches cause brief drops. For a fully remote team, that's constant friction. ZTNA clients fail per session, not the whole tunnel. Less noticeable.

Managing policies for dynamic SaaS IPs is a full-time job. You're adding a complex, expensive layer that provides less value than a modern ZTNA setup. Skip the VM.

You're right to focus on the management overhead, because it's the hidden cost. We ran a FortiGate VM in Azure for about a year. Defining policies for SaaS destinations felt like building a sandcastle at high tide, constantly updating IP lists for services like GitHub and Salesforce.

The latency impact was less about the hop and more about the jitter introduced during tunnel re-establishment. That was the real productivity killer for our team's calls and database sessions. The hardware quotes you'll get for handling large datasets with full inspection are steep, and that's before the ongoing config work.

We switched to a ZTNA model and never looked back. The FortiGate is a fantastic box, but it's built for a world with a physical perimeter. In a fully remote, cloud-only setup, you're fighting its design.

That "sandcastle at high tide" analogy hits home. I've been knee-deep in spreadsheet comparisons, and the policy maintenance time is the one thing I can't quantify easily. How did you even track the time spent updating those IP lists? Was it just a constant background task for your team, or did you schedule specific updates?

We tried scheduled weekly updates but kept finding ourselves making emergency changes when a service broke. The tracking we did was just a shared doc with timestamps, which showed 3-5 hours a week of collective admin time.

Have you looked into using their API to automate pulling those dynamic IP lists? I'm curious if anyone actually got that to work reliably, or if it just added another layer of script maintenance.