I have been conducting a detailed performance evaluation of Banyan Security's Zero Trust Network Access platform across our distributed organization, and I have identified a significant and consistent bottleneck: file transfer performance to and from remote offices is markedly slower than expected. This analysis is based on a comparative benchmark against our previous site-to-site VPN and other ZTNA vendors we have tested in a proof-of-concept capacity.
The core workflow in question involves branch office users accessing large files (engineering assets, multimedia, dataset archives) from on-premises SMB shares and NAS appliances, routed through the Banyan Access Tiers. We observe a 60-75% reduction in throughput compared to a direct IPSec tunnel, with latency-sensitive protocols like SMB/CIFS becoming particularly cumbersome. This degradation manifests not just in raw transfer times, but in user experience—directory listings are sluggish and file locks are slow to propagate.
My initial hypothesis centered on the architectural overhead. To isolate variables, I performed a series of controlled `iperf3` and `scp` tests between identical endpoints, with the only variable being the data path.
**Test Configuration:**
* Source: Remote Office (Linux client, 1 Gbps symmetric enterprise broadband).
* Destination: Corporate Data Center (Linux server, 10 Gbps).
* Path A: Direct via Banyan Access Tier (nearest region).
* Path B: Direct via legacy IPSec VPN concentrator.
* Tool: `iperf3 -c -t 30 -P 4`
**Benchmark Results Summary (Average of 10 runs):**
| Metric | Banyan Path (A) | IPSec VPN Path (B) | Degradation |
| :--- | :---: | :---: | :---: |
| TCP Throughput | 312 Mbps | 887 Mbps | ~65% |
| Avg. RTT | 42 ms | 19 ms | ~121% |
| TCP Retransmits | 1.2% | 0.1% | 1100% |
The increased latency and packet retransmissions point to TCP inefficiencies introduced by the proxy/gateway architecture. The Access Tier appears to be terminating and re-initiating TCP connections, which breaks the end-to-end principle and can severely hamper protocols that rely on tuning their congestion windows to the underlying network characteristics. While this is a common trade-off in ZTNA for security inspection, the performance penalty here seems excessive.
I am seeking insights from other enterprises with similar deployment patterns. Specifically:
* Has anyone performed granular tuning of Banyan's TCP stack or Access Tier configuration to improve bulk data transfer?
* Are there recommended practices for placing Access Tiers to minimize latency between offices and key data repositories?
* Has Banyan's engineering team provided guidance on optimizing for high-throughput, low-latency use cases beyond standard web applications?
My next step is to instrument the data path with an APM tool to gather deeper TCP flow analysis, but community feedback on practical configurations would be invaluable.
— Isabella G.
Measure everything, trust only data
Surprised? You traded a fat VPN pipe for a dozen micro-tunnels and policy checks. Of course it's slower. The benchmarks just confirm the overhead.
> latency-sensitive protocols like SMB/CIFS becoming particularly cumbersome
That's the architectural tax. Your old VPN was a dumb bridge. ZTNA is a smart filter. Every packet gets inspected, re-encrypted, and bounced. Try running a packet capture through the Access Tier, you'll see the extra hops.
What did you expect? They sold you "secure" not "fast."
If it ain't broke, don't 'upgrade' it.
The architectural tax you mention is a real factor, but attributing the entire 60-75% throughput drop to ZTNA's inherent "smart filtering" oversimplifies the diagnostic process. Packet inspection and encryption overhead are constants, but the magnitude of impact you're seeing suggests potential misconfiguration or a suboptimal traffic path.
I'd focus the packet capture analysis not just on hop count, but on the specific TLS ciphers being negotiated between the client and the Access Tier, and between the Access Tier and your backend. An inappropriate cipher suite for your hardware can cripple throughput. Also, verify the TCP window scaling behavior through the tunnel; ZTNA gateways can sometimes reset this, forcing poor performance for high-latency links.
Your point about SMB/CIFS being cumbersome is key - it's a chatty protocol. The performance hit isn't just per-packet overhead, it's the multiplicative effect of round-trip latency on each SMB command. Have you compared the performance using a different protocol like SFTP to the same data? That can isolate whether the issue is broadly file transfer or specifically SMB over the new tunnel.
—at