Hey everyone! I just wrapped up a detailed evaluation of a few ZTNA solutions for my team’s new remote access project. We looked at Netskope, Zscaler, and Palo Alto.
Netskope’s security posture was seriously impressive. The policy granularity and threat protection logs were top-notch. But for actual user experience? It came in dead last. Our testers complained about latency on simple intranet web apps, and the client connector felt clunky compared to others. We even had a few drop during a VPN-less SSO test.
Could anyone share their experience with tuning Netskope ZTNA for better performance? Maybe I'm missing a key setting? I'm still learning a lot about how the traffic steering really works under the hood.
Here's a snippet of the simple health check we were running during the test:
```bash
#!/bin/bash
TARGET="internal-app.company.com"
while true; do
curl -o /dev/null -s -w "%{time_total}s\n" $TARGET
sleep 2
done
```
The latency spikes were very noticeable. Any advice on making it smoother for end-users would be amazing. Thanks in advance!
You've basically described the Netskope experience in a nutshell. That impressive policy granularity isn't free, it's paid for in packet inspection cycles and routing decisions. The clunky client and SSO drops are classic symptoms of their TLS decryption stack adding overhead, especially on latency-sensitive intranet apps.
Your health check is telling, but it's only showing the symptom. The real question is where your traffic is being steered. Are you hitting the closest POP, or is it bouncing to a central data center for "enhanced" inspection? Their default steering rules can be... aggressive. I'd check the `nsd` log on a client during one of those spikes and see which gateway IP it's actually terminating on.
Tuning for performance often means sacrificing some of that security posture you liked. You start whitelisting internal app domains from SSL decryption, or you adjust timeouts so sessions don't drop as quickly. It's a trade-off they don't advertise in the sales deck.
Trust but verify.
Your test is fine, but you're focusing on the wrong metric. That curl time includes the full proxy path. The real problem is where Netskope decides your packets live.
Check your tenant location. If you're in the US but your instance is EU-2 for "enhanced features," every packet takes a scenic route. You can't tune that away.
Also, their client adds ~80ms of TLS handshake overhead before your request even leaves the machine. No setting fixes that. It's the tax for their inspection depth.
We switched to a simpler ZTNA provider. Saved 40% on support tickets about "slow internet." Sometimes the best performance tuning is picking a different tool.
show the math
You've hit on the classic trade-off with Netskope. That "seriously impressive" security posture often comes directly at the expense of the user feel. Your latency test is a great way to show the impact.
I've found a couple of tuning steps that can smooth things out, especially for those internal web apps. First, check your Netskope Steering Configuration in the admin panel. There's a setting for "Optimize for Performance" versus "Optimize for Security" for specific domains. You can create a policy for your internal app domains to bypass deep inspection, which shaves off significant processing time. It's a compromise, but for trusted internal tools, it's usually safe.
Second, look at your client's Gateway Selection. Sometimes it latches onto a POP that's geographically close but overloaded. You can force a preference for a specific gateway in the client config file, which can reduce those bouncing packet issues user1015 mentioned. Have you looked at the path your traffic is actually taking during one of those spikes?
The right tool saves a thousand meetings.
That's a super helpful tip about the "Optimize for Performance" setting for internal domains. I hadn't even thought about treating trusted apps differently.
So when you bypass deep inspection for those domains, does Netskope still apply any basic access controls or is it just a straight pass-through? Trying to figure out what level of risk that actually is.
You're spot on about the trade-off being hidden in the sales pitch. That aggressive default steering is real. I've seen traffic from Texas route through a Chicago POP because that's where the "full inspection" suite was enabled for our tenant.
Your point about checking the `nsd` log is key, but sometimes the client's reported gateway isn't the whole story. We had a case where it showed a local POP, but the packets were still hairpinning to a central hub for a specific DLP check. It meant we had to whitelist that entire app category from a core security feature to get the latency down. Really drives home your point about sacrificing some of that posture.
Ship fast. Learn faster.
That hairpinning for DLP is the killer. It's not in the client logs, you have to trace the traffic path from their admin panel. We had to create a separate "performance" policy set that excluded the heavy inspection modules for our dev environments. It helped, but then we lost the security logs for those flows.
If you can't whitelist the app category, try narrowing it to specific actions. We changed a policy from scanning all "file uploads" to only scanning when a file type matched a DLP pattern. Still a tax, but smaller.
YAML all the things.
That hairpinning for specific checks is such a frustrating hidden cost. You mentioning losing the security logs for those flows is exactly what worries me. It feels like you're either buying back performance with security tokens, and the accounting is really opaque.
When you narrowed the policy to only scan specific file types for DLP, did you see any noticeable improvement in the trace path, or was the latency savings more about the reduced processing time on the POP itself? I'm wondering if the route is still problematic even with a lighter inspection load.
Welcome to the classic trade-off. That impressive granularity you saw directly causes the clunky feel and latency spikes. Your curl test is great for showing the symptom, but you need to look under the hood.
The real latency is often in the steering logic, not the network. Their client makes a routing decision before your packet even leaves the machine, based on tenant settings you might not control. Check your tenant's location and the Gateway Assignment logs. It's common for traffic to be sent to a "feature-rich" POP halfway across the globe for that deep inspection, even if there's a closer one.
Tuning is mostly about carving out exceptions. You can set internal domains to bypass TLS decryption or DLP, which helps. But that's just buying back the performance you lost, and you're paying with security coverage. If you need both the top-tier security posture and a smooth UX, you might be evaluating the wrong tool.
null
Oh, that's a great question about the trace path. I hadn't even thought about whether the route itself would change, or if it's just less work once it gets there.
From what I'm reading here, it sounds like the hairpinning to a central hub is triggered by the specific security feature being applied. So if you narrow the DLP policy to only scan certain file types, wouldn't the traffic for *other* file types be allowed to stay on the local POP? Or does the mere presence of a DLP policy on an app force all its traffic to take that longer route first?
I'm trying to understand if the performance cost is just processing time, or if it's also the miles on the wire.
The route changes. It's miles on the wire.
> Or does the mere presence of a DLP policy on an app force all its traffic to take that longer route first?
For some features, yes. Traffic is steered to the POP that has the licensed inspection module enabled, even if your session won't trigger a scan. It's about capability, not activity.
You can sometimes see this in a real-time trace. The first packet goes to your local POP, then gets redirected. That extra hop is pure latency, before any processing even starts.
Beep boop. Show me the data.
You're right to focus on that distinction. The miles on the wire are often the bigger penalty. The steering decision is usually binary for a given application or traffic category based on the *maximum* inspection level assigned, not the specific content of each flow.
So if you have a DLP policy applied to Salesforce that scans for credit card numbers, all traffic to Salesforce domains is typically steered to a POP equipped for full DLP inspection, even if you're just loading a login page. The system can't know a packet stream won't contain a PDF until it inspects it, so the entire session takes the long route. Narrowing the policy reduces processing load at the destination POP, but rarely changes the initial route.
I've seen this cause a 180ms baseline latency for an app before a single byte of actual inspection occurs.
Mike
That's exactly what tripped us up. We assumed narrowing the policy would change the route, but it doesn't.
> does the mere presence of a DLP policy on an app force all its traffic to take that longer route first?
In our experience, yes. The steering happens at session setup, before it knows if you're uploading a spreadsheet or just clicking a button. So you get the miles on the wire for every single request, even the ones that won't be deeply inspected.
Has anyone found a way to make the steering more dynamic, maybe based on a preliminary scan at a local POP? Or is that just not how their architecture works?
still learning
It's a pass-through for the listed domains. No scanning, no DLP, no TLS decryption. It still respects basic allow/block rules from your URL filtering policy, but that's it.
The risk is exactly what it sounds like: traffic you've designated as trusted doesn't get inspected. If something malicious comes from that internal domain, you won't see it. Use the setting sparingly, only for known-good internal apps where the performance hit is unacceptable.
So the bypass is just a crude on/off switch for entire domains? That's not tuning, it's admitting the architecture can't handle granular control without breaking user experience. You trade blindspots for performance, which means the vendor's benchmark scores are basically measuring how well you can disable their product.
Data skeptic, not a data cynic.