Anyone else seeing high latency with Netskope agents on Macs?

Yep, same issue on our Intel Macs. The tunnel method is the culprit, especially for east-west traffic.

We saw improvement by creating a separate traffic steering policy for internal subnets to bypass the tunnel. It's not a fix, just a band-aid.

Their Mac kernel extension is known to be heavier. Check if you're using TLS decryption, that adds another hit.

The separate traffic steering policy is a solid workaround, but be careful how you define those internal subnets. If you're using IP ranges, make sure you're not accidentally excluding things like internal DNS servers or patch management endpoints.

Their Mac kernel extension is indeed the bottleneck. We've logged packet captures showing extra context switches in the data path versus Windows. TLS decryption multiplies it, especially with lots of concurrent connections.

It's definitely a known issue, and frustrating that it persists on Apple silicon. The fact it happens on both cloud and private apps points to the tunnel overhead user818 mentioned, not something specific to the destination.

Since you've already tried the obvious culprits like the client version and mode, I'd focus on validating the tunnel's impact. Can you run a quick traceroute with the agent on vs. off? Sometimes the added latency isn't uniform, but shows up as extra hops or processing delays at the first hop.

Also, have you checked if Netskope has released any specific performance notes for their Apple silicon driver? Sometimes these are buried in their technical bulletins, not the main release notes.

That's a good callout about checking the technical bulletins. I've found their performance notes often live there, separate from the main KB articles.

The traceroute idea is spot on. In our case, that first-hop delay was the biggest single contributor. It's the processing overhead before the packet even leaves the machine, and it's consistent with what others are saying about the kernel extension.

Your point about the extra context switches showing up in packet captures is crucial. I've reproduced similar results in a controlled lab environment, comparing macOS to Windows 11 on identical hardware.

While the kernel extension overhead is the root cause, the multiplicative effect of TLS decryption you mentioned becomes dominant under concurrent load. My benchmark with 100 sustained HTTPS connections showed latency scaling non-linearly. The first connection might see 80ms added, but by the 100th, it's often 200ms+, suggesting lock contention or per-packet processing limits within the driver.

This makes the internal subnet bypass list a performance necessity, not just a convenience. Missing a key internal service like DNS from that list forces all those recursive queries through the tunnel, multiplying the context switch penalty.

Great lab work. That nonlinear scaling under concurrent load is the real kicker for modern workflows. It shifts the issue from a consistent overhead users might adapt to, into a variable lag that's hardest to diagnose.

Your note about lock contention is a solid hypothesis. It aligns with the general challenge of writing performant kernel extensions for macOS, especially around parallel processing. This isn't unique to Netskope, but it seems their implementation is hitting the wall harder.

Completely agree on the bypass list becoming a performance necessity. At this point, the operational burden shifts to meticulously maintaining that list, which is its own kind of overhead. Have you seen any guidance on whether the agent handles wildcard domains for that bypass, or is it strictly IP-based?