Anyone else using Netskope ZTNA with a remote developer team? We’ve been hitting a consistent issue where Netskope seems to interfere with our engineers' VPN connections (OpenVPN & WireGuard). The connection will just drop, or become unusably slow, right when they need to access staging environments.
What we’ve tried/noticed:
* Issue is isolated to machines with the Netskope client.
* Seems tied to specific ZTNA rules for accessing our internal app subnets.
* Temporary workaround is to pause Netskope, which isn't a secure or scalable solution.
Looking for any insight on:
* Known config pitfalls with VPN passthrough?
* Specific steering or routing rules that might cause this?
* Are we better off excluding the VPN client process from ZTNA inspection?
Need to keep the security posture but can't have devs blocked. Appreciate any shared experiences or dashboards on this. 🙏
--ash
data over opinions
We're looking at Netskope too, and this exact VPN issue is my main worry. Have you checked the MTU settings on the client side? I've seen posts where adjusting the tunnel MTU lower, like to 1300, can stop the drops when a ZTNA client is also steering traffic.
Also, excluding the VPN client process from inspection sounds risky. Doesn't that basically create a tunnel around your ZTNA rules for everything inside that VPN?
Excluding the VPN client process is generally a bad idea. It bypasses your ZTNA for all traffic inside that tunnel, which defeats the purpose.
Your description points to a routing conflict. Netskope's client creates a split tunnel by default for ZTNA-steered traffic. If your VPN is also trying to route the same internal subnets, you get packet duplication or blackholing.
Check two things:
* The Netskope client's routing table (`route print` or `ip route`) when connected and attempting VPN.
* The ZTNA rule's destination definitions. Overlap with your VPN's advertised subnets causes this.
Adjusting the VPN's pushed routes to be more specific, or configuring Netskope to exclude the VPN's gateway IP from steering, usually works without sacrificing security. MTU tweaks are just masking the symptom.
Your fancy demo doesn't scale.
Good point on the MTU, user455. I've seen that work as a band-aid, but it's really just treating a symptom of a routing conflict. The underlying issue is usually the ZTNA client and VPN client fighting over control of the same traffic.
You're also spot on about process exclusion. It's a major security hole, essentially creating an unmonitored tunnel for any data the VPN carries. That's not a fix, it's just giving up.
Connecting the dots.
Exactly. This is why I don't trust client-side ZTNA for anything but the simplest web traffic. You're layering two network control systems that both think they're in charge.
Process exclusion is a joke. I've seen teams try it, and then the VPN client becomes the favorite vector for everything the security team is supposed to block.
The real fix is picking one tunnel. Either route your internal subnets over the corporate VPN and accept the performance hit, or commit fully to ZTNA and kill the traditional VPN for those resources. This hybrid mush just creates fragile, impossible-to-debug nonsense.
If it ain't broke, don't 'upgrade' it.