In evaluating Zero Trust Network Access solutions for a high-throughput financial data pipeline, raw TCP throughput emerged as a critical, non-negotiable requirement. While security features and identity integration are paramount, the underlying data plane performance directly impacts the viability of replacing legacy, hardware-based VPN concentrators for data-intensive workloads.
We conducted a controlled lab test comparing three leading ZTNA vendors (referred to as Vendor A, B, and C) focusing on sustained TCP throughput over a simulated WAN link of 50ms RTT. All vendors were configured in their recommended "gateway" or "proxy" mode, enforcing identity-based policies before allowing the TCP connection. The test involved a simple `iperf3` stream from a client behind the ZTNA agent to a server in a private application segment.
**Test Configuration Summary**
- Tool: `iperf3 -t 300 -P 8`
- Network Path: Client -> Public Internet -> ZTNA Gateway -> Private App Server
- Latency Introduced: 50ms (simulated)
- ZTNA Agent: Latest version, installed on a standard 4-core, 8GB RAM cloud instance.
- Application Server: Equivalent specs in private segment.
**Observed Throughput Results (Averaged over 5 runs)**
| Vendor | Avg. Throughput (Mbps) | CPU Load (Client Agent) | Notes |
| :--- | :--- | :--- | :--- |
| Vendor A | 942 Mbps | High (~75%) | Kernel-level socket forwarding. |
| Vendor B | 487 Mbps | Moderate (~45%) | User-space proxy with TLS re-encryption. |
| Vendor C | 312 Mbps | Low (~30%) | Agentless; HTTP/S proxy for TCP tunneling. |
**Analysis of Architectural Trade-offs**
The results highlight a fundamental architectural divide impacting performance:
1. **Vendor A's** kernel-level implementation minimizes context switches and data copies, approaching near-native TCP performance. This aligns with architectures built for raw data transfer, but often requires a privileged agent.
```bash
# Example of the low-level socket handling that Vendor A likely employs
# This is conceptual, not their actual code.
kernel_module->intercept_connect(dest_port, &redirect_to_gateway);
```
2. **Vendor B's** user-space proxy provides strong isolation and easier updates, but the double TLS termination (client-agent and agent-gateway) and data copying create a measurable overhead. The security model is more contained.
3. **Vendor C's** agentless, proxy-based approach showed the highest overhead for raw TCP streams. Its strength lies in web and SaaS application access, not bulk data transfer. The throughput ceiling will be a significant constraint for database replication or large file transfers.
**Conclusion for Implementation**
The choice heavily depends on the application profile within the Zero Trust architecture. For user-to-web-app traffic, any vendor is sufficient. However, for modernizing data center-to-data center or user-to-high-performance server connections (e.g., data scientists accessing GPU clusters), the throughput penalty of the proxy-based models may be prohibitive. It forces a segmentation of the ZTNA strategy: high-throughput, trusted workloads may need a different architectural pattern (e.g., service mesh mTLS) alongside ZTNA for user access, rather than a one-size-fits-all ZTNA solution.