Having recently completed a comprehensive POC of Netskope's ZTNA solution against a legacy per-app VPN, I find myself compelled to document a significant architectural divergence. The industry's wholesale shift to an always-on, user/device-tunnel model, while superior for continuous security posture validation, introduces non-trivial workflow and performance complexities that are often glossed over in vendor white papers.
My primary contention is that the elimination of a discrete, user-initiated 'per-app' connection mode creates friction in several specific scenarios:
* **Developer & Administrative Workflows:** Tasks requiring brief, high-privilege access to a single internal tool (e.g., a database admin console, a CI/CD server) now necessitate the entire device's traffic to be routed through the corporate tunnel for the duration. This forces all other personal/non-work traffic to suffer the latency of the corporate egress point, a clear inefficiency.
* **Bandwidth-Sensitive Applications:** In a per-app model, a user could route only SSH or RDP traffic for a server management session. With an always-on tunnel, a simultaneous personal video stream or large download is unnecessarily routed through the corporate infrastructure, consuming pooled bandwidth and potentially violating acceptable use policies.
* **Troubleshooting & Network Differentiation:** The binary state of the tunnel—either entirely on or off—complicates diagnosing whether a connectivity issue is with the user's local network, the ZTNA service, or the target application. A per-app mode provided an implicit segmentation for testing.
The Netskope Client, while highly configurable via its `settings.json`, appears philosophically opposed to this selective tunneling concept for ZTNA resources. Consider a simplified legacy VPN configuration for routing only specific subnets:
```json
// Hypothetical legacy per-app config (not Netskope's)
{
"ConnectionName": "Corp-App-Access",
"TunnelMode": "split",
"Routes": [
"10.10.1.0/24",
"192.168.100.0/24"
],
"DNS": "10.10.1.10"
}
```
In contrast, Netskope's model is predicated on a default route for all traffic (`0.0.0.0/0`) with exclusions, which inverts the logic. The administrative overhead then shifts to meticulously defining and maintaining **Exclude** lists for all non-corporate destinations, which is both fragile and infinite.
I understand the security rationale: the always-on tunnel enables real-time posture checks and prevents credential-based attacks on isolated apps. However, from a systems architecture perspective, this feels like a regression in granular control. The cost is paid in user experience, unnecessary network load, and increased support tickets for "slow internet" when the tunnel is active.
Has anyone else devised a pragmatic workaround within Netskope's policy framework to approximate a user-controlled, application-specific tunnel? Or are we to accept that this level of network-layer granularity is an intentional casualty in the evolution from VPNs to ZTNA? I am particularly interested in any quantifiable data on bandwidth overhead or latency impact from forcing all traffic through the service, as my initial benchmarks showed a 8-15% increase in latency for non-corporate traffic during tunnel sessions.
Oh, I feel this so much! You're spot on about the developer workflow friction. We had a similar griping session here when our analytics team rolled out a new always-on setup.
It completely borked their local development environments because every API call to test a microservice got routed through the corporate tunnel, adding crazy latency to their feedback loop. Suddenly, a quick build-and-test cycle took minutes, not seconds. They ended up creating isolated local network segments just to work around it, which felt like a total step backwards.
It's that lack of granular control that stings. There's a real difference between securing all traffic and letting someone quickly tunnel into one specific thing without dragging their whole internet connection with them.
Forcing all personal traffic through the corporate tunnel just for a quick console check is a design failure. It trades minor convenience for real user productivity.
You see the same lazy architecture in analytics. Vendors push always-on, full-stream tracking under the banner of "complete data," ignoring how it bogs down apps and floods you with useless noise. Granular event control isn't a legacy feature, it's a requirement.
The latency hit on non-work traffic isn't just an inefficiency, it's a measurable performance tax that will show up in your employee satisfaction surveys. Has anyone actually run the numbers on that productivity loss versus the supposed security gain?
If it's not a retention curve, I don't care.