Skip to content
Notifications
Clear all

Has anyone quantified the bandwidth overhead of the always-on client? My test shows 5-8%.

1 Posts
1 Users
0 Reactions
1 Views
(@derekf)
Trusted Member
Joined: 5 days ago
Posts: 38
Topic starter   [#16814]

I've been conducting a performance and cost analysis of Fortinet FortiSASE for a potential large-scale deployment (approx. 5000 remote users) and have hit a data point that requires broader community validation. A core component of my evaluation is quantifying the inherent bandwidth overhead introduced by the always-on FortiClient EMS ZTNA agent, as this has direct implications for user experience, bandwidth provisioning, and ultimately, WAN cost calculations in a FinOps model.

My controlled lab test methodology was as follows:
* **Test Traffic:** Generated sustained, reproducible traffic using `iperf3` for TCP and UDP streams, and simulated common web traffic with `wrk` against a test application.
* **Baseline:** Measured throughput and total bytes transferred directly over a clean broadband link.
* **FortiSASE Condition:** Repeated identical tests with the FortiClient (version 7.2.3) connected to FortiSASE, ZTNA rules configured for the test targets, and all security profiles (web filtering, DNS filtering, CASB) enabled as per our proposed production policy.
* **Measurement Point:** Captured packets at the client interface using `tcpdump` over 10-minute intervals, comparing total payload bytes delivered to the application layer vs. total bytes transmitted on the wire.

**Preliminary results indicate a consistent bandwidth overhead of 5-8%.** This is attributed to the encapsulation headers (IPsec or DTLS, depending on the tunnel establishment) and the necessary keep-alive/control messaging required to maintain the always-on ZTNA tunnel. The overhead was more pronounced (closer to the 7-8% range) on high-throughput, low-packet-rate streams (like large file transfers), and slightly lower (5-6%) on transactional web traffic.

**This finding has significant cost implications.** For an organization with a distributed workforce using, for example, a cumulative 10 Gbps of sustained internet egress, the effective "tax" for the SASE fabric could be 500-800 Mbps of additional bandwidth requirement. When translated to ISP circuit costs or cloud egress fees (for branches using cloud on-ramps), this becomes a non-trivial operational expense.

My questions to the community are:
* Has anyone else performed similar empirical measurements of FortiSASE or comparable always-on ZTNA client overhead?
* Do your observations align with this 5-8% range, or have you seen divergent results based on different traffic profiles or client versions?
* Are there documented best practices or configuration tunables (e.g., MTU adjustments, DTLS vs. IPsec preference) to minimize this overhead without compromising security posture?

I will be proceeding with a wider field trial and can share my detailed testing framework and raw data if there is interest. A collaborative effort to benchmark this overhead would benefit all platform engineering teams tasked with justifying SASE architecture from both a security and economic perspective.


No free lunch in cloud.


   
Quote