We are currently in the planning stages for a full IPv6 dual-stack deployment across our primary corporate network and several satellite offices. As part of our standard security posture, we utilize Netskope's Secure Web Gateway and Cloud Access Security Broker capabilities for all outbound traffic, with clients configured via the Netskope client.
Our initial limited pilot for IPv6 has revealed significant and consistent connectivity issues that do not manifest in an IPv4-only environment. The problems are severe enough that our network engineering team has formally paused the broader rollout pending a resolution. The core symptom is that client machines with IPv6 enabled experience intermittent but profound failures in establishing a connection to the Netskope cloud, resulting in either a complete block of internet traffic (when the client is set to block mode) or a leak into direct, unsecured connections (in monitor mode).
From a technical perspective, we have observed the following specific failure modes:
* **Initial Handshake Timeouts:** The Netskope client frequently fails to complete its initial authentication and tunnel establishment handshake when the underlying OS network stack prefers an IPv6 route. Packet captures show repeated TCP SYN attempts to Netskope POPs over IPv6 that either go unanswered or result in RST packets.
* **Inconsistent POP Reachability:** Using diagnostic tools, we find that IPv6 connectivity to certain Netskope datacenter IPs is unstable, with ping and traceroute tests showing high packet loss (30-50%) or excessive latency spikes beyond 500ms, whereas IPv4 paths to the same geographic regions are stable under 50ms.
* **SSL/TLS Negotiation Failures:** On occasions where a TCP connection is established over IPv6, we encounter a higher-than-expected rate of TLS handshake failures. This suggests potential issues with certificate validation or intermediary devices when the traffic is routed via IPv6.
Our current environment and testing methodology:
* Netskope Client Version: `v95` (also regressed to `v91` with identical results)
* Client Deployment Mode: Steered via PAC file for explicit proxy discovery.
* Underlying OS: Windows 11 23H2 and macOS Sonoma 14.4.
* Test Control: Verified by toggling IPv6 on the client NIC, which reliably triggers or resolves the issue.
I am seeking to determine if this is a localized infrastructure problem or a more widespread compatibility issue. Specifically, I would like to gather data on:
* Whether other enterprises with dual-stack deployments have successfully implemented Netskope without modifying client IPv6 settings.
* Any required configuration adjustments on the Netskope tenant (SKEN/STE) or client policy side to robustly support IPv6.
* Official statements or known limitations from Netskope regarding IPv6 readiness for the SWG tunnel.
* Benchmark comparisons of latency and throughput for IPv4 vs. IPv6 tunnels within Netskope for those who have it operational.
Our next step is to engage Netskope support with this collected data, but community validation on the current state of IPv6 would be invaluable for prioritizing this as a critical path item.
This mirrors our experience almost exactly, particularly with the initial handshake phase. We documented the same pattern of timeout events during tunnel negotiation that would clear immediately when forcing the client to IPv4-only via local policy.
Did your team also notice if the failures correlate with specific DNS resolver behavior? In our case, we found the Netskope client's internal logic for selecting its egress path seemed to falter when AAAA records were present, even if the eventual connection attempt was meant to be over IPv4. It pointed to a problem with the client's own network detection stack, not the underlying network's IPv6 connectivity.
We opened a support case and were eventually directed to a specific client version and a registry tweak to disable its IPv6 probing entirely. I can dig up the exact version string if you think it would help, but the permanent fix only landed in their stable track a few months ago.
Support is a product, not a department.
That handshake timeout symptom is a classic one. We saw something similar during our last dual-stack push, though for us it wasn't just Netskope. The common thread was applications that tried to race IPv4 and IPv6 connections on startup.
A key question for your team: are you using a split-DNS setup where internal domains only resolve to private IPv4, while the Netskope endpoints get both A and AAAA records? That mismatch can really confuse a client's connection logic, making it wait for a v6 attempt to timeout before falling back, which blows past the app's own timeout threshold.
Have you tried running a packet capture during a failure to see if the SYN is actually going out on IPv6, or if it's stuck in the resolver phase? That usually tells you if it's a true network path issue or an app-layer selection problem.
You've hit the nail on the head with split-DNS. It's almost always the culprit in these half-baked rollouts. Your packet capture suggestion is correct, but I'd skip straight to the source and just run `netsh interface ipv6 show neighbors` on a problematic Windows client during a failure.
Nine times out of ten, you'll find it's not the SYN packet. The client has an IPv6 default route and a valid address, so it dutifully tries to resolve the FQDN. It gets both records, but the local firewall or the host's own stack is blocking the outbound IPv6 probe to the Netskope endpoint. The client's connection logic then sits there, stuck in a loop, waiting for a timeout that takes far longer than the application expects.
This is why I push for disabling IPv6 on the client NIC as the first step in any SWG rollout. You're not deploying IPv6 for your users, you're deploying it for your network. The extra complexity it introduces at the endpoint, especially with security software that hijacks the stack, is rarely worth the trouble until everything else is flawless.
keep it simple
That's a solid diagnostic path, and I've seen that exact neighbor cache issue before. It often points back to the client's own IPv6 default gateway not being fully functional, even if an address is assigned.
I do have to push back gently on the blanket recommendation to disable IPv6 on the client NIC, though. While it's a proven workaround, it can become a crutch that lets underlying network problems persist indefinitely. For a true dual-stack rollout, the goal should be to make the stack work correctly, not to disable it. Sometimes the fix needs to come from the Netskope side, as their client's interaction with Windows' IPv6 stack isn't always optimal.
Have you found that the registry tweaks to adjust connection timeouts, or prioritizing IPv4 over IPv6 in the prefix policy, provide a more sustainable fix than just turning the protocol off?
Keep it constructive.
Oh, that's a really good point about disabling IPv6 just hiding the problem. I'm new to a lot of this network stuff, so thanks for explaining.
I was wondering, when you talk about the client's IPv6 default gateway not being fully functional, could that also include things like RA flags from the router? Sorry if that's a basic question.
For the registry tweaks, did adjusting the prefix policy actually help without breaking other apps that might need v6?