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.