Just had to roll out FortiSASE to a subset of our fleet. The memory usage is… not great.
Ran a quick comparison against our existing Palo Alto GlobalProtect deployment on identical Ubuntu 22.04 VMs. Same workload, just idling after connection.
```
# GlobalProtect
$ ps aux | grep PanGPS | awk '{print $6/1024 " MB"}'
~85 MB
# FortiSASE
$ ps aux | grep forticlient | awk '{print $6/1024 " MB"}'
~220 MB
```
That's the main `forticlient` process. There's also a helper or two adding another 30-40MB. So we're looking at roughly triple the resident memory for the same basic function: a VPN tunnel.
I get that it's doing more "SASE" things, but when you're deploying this at scale, that delta adds up fast. More resource contention, bigger bill from your cloud provider. For what? A tunnel is a tunnel. GlobalProtect has been boringly reliable for years. This feels like bloat wrapped in a fancy acronym. Anyone else seeing this, or did I get a bad package?
If it ain't broke, don't 'upgrade' it.
I'm a platform engineer at a mid-sized SaaS company, we manage about 600 endpoints and use both Palo Alto firewalls and have done POCs with Fortinet's SASE. Our primary VPN for remote engineering staff is GlobalProtect.
1. **Memory footprint and performance:** You've measured the core difference. FortiSASE *does* bundle more into the client: DNS filtering, ZTNA connector, and a local web filter cache. That 220MB baseline is normal. GlobalProtect's lighter agent does just tunnel and HIP. If you enable the full SSL inspection or local logging on FortiClient, add another 50-70MB.
2. **Deployment and management overhead:** FortiSASE requires its cloud portal and ties into the Fortinet ecosystem. It's a full day to configure SAML, posture checks, and app policies vs. GlobalProtect's half-day setup connected to an on-prem Panorama. The big lift is migrating endpoints; you can't just swap clients, you need to rebuild the config profile from scratch.
3. **Cost model difference:** GlobalProtect typically comes with your Palo Alto firewall license (like $150-300/year per gateway). FortiSASE is a separate subscription, about $8-12/user/month for the full stack. The hidden cost is the compute overhead you found - those extra 150MB per endpoint add up in a VDI or cloud workload scenario.
4. **When FortiSASE actually wins:** It's for a zero-trust rollout where you need client-side inspection and don't have a full firewall stack at every branch. If your use case is "tunnel back to the data center for RDP," GlobalProtect is simpler and lighter. FortiSASE makes sense if you're actively blocking threats at the endpoint level via the tunnel and use CASB features.
I'd stick with GlobalProtect for straightforward secure access. The Fortinet stack only makes financial sense if you're replacing other endpoint security layers and need the integrated dashboard. To decide cleanly, tell us your primary use case and whether your security team is already bought into the Fortinet ecosystem.
Build once, deploy everywhere
Spot on about the management overhead. I just finished a similar POC and the SAML integration alone took us an afternoon because of some quirks with the attribute mapping in the FortiSASE portal.
The subscription cost is a huge point too. With GlobalProtect, you're basically right, the license is often just there. For us, the $10/user/month sticker shock meant we had to justify it against the extra features we'd actually use, like ZTNA for contractors. Most of our team just needs the tunnel, so it was a tough sell.
Have you seen any performance hit on lower-powered machines with that extra memory load, or does it mostly just idle?
The extra memory absolutely causes swap churn on low-spec developer laptops, especially when they're running Docker or a heavy IDE. We saw a noticeable increase in "sluggish VPN" tickets.
Your point about the license cost is the real killer. You're paying that $10/user/month whether you use the ZTNA features or not. If you just need the tunnel, you're burning budget for memory overhead and unused cloud portal features.
We justified it for a team that needed the app-level ZTNA rules. For everyone else? GlobalProtect stayed. The SAML quirks you hit are consistent too, their IDP handling is brittle compared to Palo Alto's.
shift left or go home
Yes, the performance impact on lower-spec machines is real. The issue isn't just idle resident memory, it's working set and page cache contention. When a developer's 16GB laptop is running Docker and an IDE, that extra ~150MB footprint pushes more of the active working set into swap, causing disk I/O churn.
You can see this indirectly with `vmstat` looking at `si`/`so` (swap in/out) during normal workflow with the tunnel active. The FortiClient process itself isn't CPU-heavy, but the memory pressure it creates triggers the OS to page out other application code. That's where the "sluggish" reports originate, especially during context switches when the system is reclaiming pages.
It forces a trade-off: you pay the subscription cost for ZTNA, then potentially pay again in hardware refreshes to mitigate the agent's resource tax. For a tunnel-only use case, the math rarely works.
brianh