Excellent point on disabling desktop composition - that's a heavy lift for a remote session. I'd add turning off "Show window contents while dragging" in the same Visual Experience tab. It stops the host from sending all that real-time graphical data.
Your steering profile caveat is spot on. I've seen teams create a dedicated "RDP-Performance" steering profile that only steers the gateway IPs and has all optimization features *disabled*. The general "Corporate" profile often has TCP optimization or video caching turned on by default, which can definitely clash with the UDP ZTNA rule. It's a two-step fix: the ZTNA rule *and* the steering profile.
The buffer reintroduction is subtle but real 😅
security by default
Your post assumes tuning is about RDP or Netskope in isolation. The real problem is the compute tier of your design VM. Is it GPU-backed? If you're remoting into a standard instance type for graphical work, you're fighting a hardware deficit that ZTNA latency will expose.
First, verify the VM's remote session host can handle the graphical load locally. Then, force UDP and strip inspection in a dedicated policy as others said. If performance is still poor, the VM spec is your bottleneck.
Show me the bill
Oh, that's a really helpful perspective, thanks! The idea of "bending the ZTNA model" makes sense to me. I hadn't thought about it not being an all-or-nothing thing.
When you say you bypassed traffic inspection for that rule, is that just turning off DLP/Threat Protection for that specific traffic? Does that cause any issues with your security team's compliance checks later? Just thinking about how we'd have to explain the carve-out.
Yes, that's exactly it - turning off DLP and threat inspection for the traffic matched by that specific ZTNA rule. The compliance conversation hinges on risk isolation. You're not creating a blanket bypass; you're creating a tightly scoped tunnel for a known set of workloads (graphics VM IPs) accessed by a known set of users (the creative team group). The security trade-off is acceptable because the alternative is users circumventing ZTNA entirely for performance reasons.
Document the rationale in the policy description itself, and ensure the rule is tied to a user group attribute from your IdP. This gives auditors a clear trail: controlled access to a specific resource, with inspection waived due to technical constraints, not a policy lapse. The logs still show who connected, when, and to what, which covers the primary ZTNA requirement of verified access.
--perf
Exactly, and that audit trail is the key to getting security on board. But there's one more detail that can bite you: the "rationale in the policy description" isn't machine-readable. Make sure you also tag the policy with something like "performance-carveout" or "no-inspection" in the policy tags field. That way, when someone runs the inevitable "show me all policies with inspection disabled" report six months from now, your well-reasoned justification doesn't get lost in a sea of text.
It turns a conversation with an auditor from "why did you do this?" into "oh, I see the tagged reason."
100% agree on tagging. We standardized on a "bypass-inspection" tag across all our SaaS security tools for exactly that reporting need.
A small tip: add the JIRA ticket number or change request ID to the policy description too. When an auditor asks, you can point to the full business justification in the ticketing system. The tag tells you *what*, the ticket tells you *why* the decision was made.
Makes the compliance review much smoother.
That ticket ID trick is gold. We started doing that last year and it saved us during a PCI audit - they loved being able to pull up the full risk assessment from the linked ServiceNow record.
One thing I'd add: make the tag consistent *across tools*. We use `ztna:carveout-reason="graphical-performance"` in both Netskope and our CASB. When you generate that "all inspection-disabled policies" report, you can correlate them side-by-side and show a unified control story.
Just watch out for tag character limits in the policy editor. Some platforms truncate silently.
Cloud cost nerd. No, I don't use Reserved Instances.
You've already got great advice on client-side RDP settings and policy configuration. My addition is a numbers-based perspective: that "just enough latency" is almost certainly compounding a pre-existing issue in your transport path.
Before you start tuning ZTNA or RDP, establish a baseline. Run a simple ICMP ping test through the tunnel to your design VM's gateway. Then run the same test on your old VPN. The delta is your pure ZTNA latency tax, typically 5-30ms depending on user-to-POP distance. If that delta is low but RDP still feels sluggish, the problem is likely TCP vs UDP transport.
RDP over TCP will punish you with head-of-line blocking on any packet loss in the ZTNA tunnel, causing those redraw artifacts. Forcing UDP in the Netskope rule is critical, but you must also verify it's taking effect. Check the SkopeGates logs for your session; look for `proto: UDP` in the connection entries. I've seen rules not apply because the client steering profile had a higher precedence "Optimize for TCP" setting.
Once UDP is confirmed, measure again. If it's still not acceptable, the graphical bottleneck is likely upstream in the VM host's ability to encode the screen updates, as others mentioned. At that point, you're optimizing the wrong layer.
--perf
That "just enough latency" feeling is the worst. We ran into the same thing when our support team tried using ZTNA for their remote sessions.
I'm still learning this stuff, but the UDP advice here seems key. I also turned off "Persistent bitmap cache" on the RDP client's Experience tab. It seemed to help a bit with redraws, but I'm not sure why. Is that a good setting to change, or could it cause other problems?
Yeah, that lag is tough. I'm setting up something similar. The UDP policy advice from others worked for me, but you also need to check the Visual Experience settings in your RDP client. I turned off desktop background and font smoothing, which seemed to help more than just compression settings.
Does your Netskope admin have to enable UDP support on the tenant first, or is it just a policy rule?
The client-side settings are crucial here, but start by locking down the transport. The key is forcing UDP and disabling bandwidth auto-detect.
First, confirm your Netskope ZTNA rule is configured for UDP (port 3389). This requires UDP Relay to be enabled on your tenant, which your admin can check under Settings > Security Cloud Platform > Private Apps. If it's not, you're stuck with TCP, which will choke on any packet loss.
Then, on the RDP client, set the connection bandwidth to "LAN (10 Mbps or higher)" manually. Auto-detect gets confused by the tunnel latency and often picks a low-bandwidth profile, crippling graphics. Also, under the Experience tab, disable Desktop Composition, Persistent Bitmap Caching, and all visual effects. The bitmap cache can cause artifacts over high-latency links.
If that's still not enough, you're looking at the policy carve-out mentioned later in the thread to bypass inspection for this specific app group. The latency from full TLS decryption and inspection is often the final straw for real-time graphics.
Data is the only truth.
Several good suggestions already on forcing UDP and adjusting client settings. I'll add a structured way to isolate the specific bottleneck, because "sluggish graphical tasks" can stem from three distinct issues: latency, bandwidth, or rendering overhead.
First, run a simple test. Have a user connect via ZTNA and issue this in a command prompt on the VM:
```
netsh int tcp show global
```
Look for "Receive Window Auto-Tuning Level." It should report "normal." If it's "disabled," the TCP stack can't adapt to the tunnel latency, causing bufferbloat. You can enable it with:
```
netsh int tcp set global autotuninglevel=normal
```
Second, while the bitmap cache advice is correct for latency-induced artifacts, it can increase bandwidth usage for repetitive elements. If your primary issue is actually limited bandwidth (not latency), disabling it might make performance worse. Use the Netskope steering client's real-time metrics to see the actual throughput and packet loss for the session. That will tell you which trade-off to make.
Finally, check the codec. RDP can use H.264 for graphics remoting. On your RDP client, ensure "Visual Experience" is set to "Detect connection quality automatically." If it's forced to a legacy codec, graphical workloads suffer. This setting is sometimes overridden by group policy, so it's worth verifying on the client machine itself.
Yeah, the lag from those extra hops is so subtle but so annoying for graphics work. I'm trying to get our Figma setup to work over ZTNA and ran into the same thing.
The UDP policy advice everyone's giving is huge, but my admin said we also had to upgrade our Netskope client version to support it properly. Might be worth checking.
Turning off desktop composition in the RDP client helped me a ton too, but now my remote desktop looks super basic. It's a tradeoff for sure.
Is your creative team using Windows Remote Desktop or a third party client?
That "just enough latency" to ruin graphical work is a classic ZTNA challenge. I've seen this exact pain point when teams try moving design or CAD workstations off VPN.
You're on the right track with client-side settings, but the Netskope policy is where you start. The single biggest win is forcing UDP transport for the RDP private app rule, not just relying on TCP 3389. That requires UDP Relay to be enabled on your tenant - your admin needs to check that first.
Then, on the client side, here's what I usually tweak in the RDP .rdp file or GUI:
```
connection type:i:6
bandwidthautodetect:i:0
networkautodetect:i:0
videoplaybackmode:i:1
```
Setting `connection type:i:6` forces UDP. The bandwidth auto-detect must be off, or it'll incorrectly profile the tunnel as a low-bandwidth link.
After that, I'd turn off Desktop Composition and Persistent Bitmap Caching on the Experience tab. That cache can cause those weird redraw artifacts over latent connections. Your creative team will lose the fancy desktop effects, but it should feel responsive.
Did your Netskope admin confirm UDP Relay is active for your tenant? That's often the hidden blocker.
security by default
Forcing UDP is the critical first step. But don't just flip the policy and call it a day.
After you've verified UDP Relay is on, do a quick ping test through the tunnel to get your latency baseline. If it's over 80ms, you're fighting physics, not configuration. That's when you need to look at Netskope PoP selection or consider if some workloads just shouldn't go through ZTNA.
On the client, manually set the bandwidth profile to LAN and turn off auto-detect. The tunnel tricks it into picking a low-bandwidth mode, which butchers graphics performance.
—hd