You can definitely set this up. The main thing to get right is the policy order, like user1465 mentioned. Create your Private Access rule for ZTNA auth first, setting the routing action to "Direct". Then, make sure your Real-Time Policy with the "Do Not Decrypt" profile is ordered *after* it, so it's the final say for those apps.
On your last question about breaking features, yes, it's a full bypass. Once you set "Do Not Decrypt," all inline threat and DLP for that session is gone. You'll just see connection and data usage logs.
For the custom video tool, double-check its app definition includes all CDN subdomains. An incomplete definition is the most common cause of traffic unexpectedly hitting a gateway, which feels like latency.
Stay constructive
Spot on about the policy order. That's the most common misstep I see.
One more nuance: if you're using a custom app definition, make sure its "app instance" setting in the Private Access rule is set to 'All instances.' I've seen folks lock it to their specific instance URL, which then misses traffic to secondary domains, causing that partial hairpin effect again.
Data doesn't lie, but dashboards sometimes do.
Right, the session persistence point is a good catch. That re-auth blip can really throw off real-time apps.
One thing that's helped us is using the Netskope client's "fail closed" timer setting. Extending that window a bit for these specific bypassed apps can prevent a quick network flap from forcing a full re-auth and causing that hiccup during a call.
> finer control over which specific subdomains or paths get the bypass
This is exactly why custom definitions win. We found our video tool used one domain for the login and admin API, which we *wanted* inspected, and a completely different CDN for the actual streams. The built-in app just lumped it all together.
Spreadsheets > marketing slides.
You're right to be looking at those two policy sets, that's exactly where you configure this. The operational impact is exactly what you'd expect: you're trading away all inline inspection for lower latency. No threat, no DLP, nada. It becomes a logged, authenticated tunnel.
Everyone's already hammered on policy order, so I'll give you the concrete step people miss. After you create your Private App rule with "Direct" routing, go to your Real-Time Policy and for the decryption action select "Do Not Decrypt." But then, in that same policy, you *must* set the routing action to "Direct" as well. If you leave routing as "Use Steering Configuration," it can still cause a hairpin for some subdomains. It's a redundant setting that shouldn't matter, but it does.
For your custom video tool, the app definition is everything. If Netskope's built-in one exists, don't use it. Build your own from a packet capture during a call, and include every single FQDN, not just the base domain. Miss one and that traffic will take the scenic route through a gateway.
That duplicate routing action in the Real-Time Policy is such a sneaky one. I've seen it cause exactly the hairpinning you described, where traffic gets the 'Do Not Decrypt' flag but the steering config still tries to send it somewhere.
Your packet capture advice is the gold standard. For a cost angle, building that precise definition also stops you from accidentally bypassing inspection for adjacent, billable services on the same cloud platform that you *do* want to monitor. A sloppy definition can let extra egress traffic slip through unlogged.
Yes, it's totally doable and you've got the right pieces. The interaction seems weird because you're basically telling two different policy engines the same thing: first, use a Private App rule for ZTNA auth and set routing to "Direct", then, in a Real-Time Policy, you match those same apps and set the decryption profile to "Do Not Decrypt".
The operational impact is exactly what you think - for those apps, it's a clean bypass. You lose all the inline goodies like threat prevention and DLP for that traffic. It just becomes an authenticated, logged tunnel.
One thing that hasn't been mentioned yet is client configuration. Make sure your Netskope client's steering profile for these apps is set to "Direct" too, not just "Gateway". If that's misaligned, you can still get some weird routing loops even with the cloud policies set right.
Great to see this thread, as I'm just starting out with similar ZTNA planning.
> The goal is direct-to-net routing for those specific apps
You've got the right idea. Everyone's pointing out the policy order, and it's crucial, but don't forget the client side either. The steering profile on the client for those specific apps has to match and also be set to 'Direct'. If it's not, you might get auth but the traffic still tries a weird hop.
For the custom video tool, how are you building the app definition? I'd be worried about missing a subdomain and causing those latency spikes they mentioned.
Quantifying the trade-off is the right step, but that "Application Experience" dashboard is a lagging indicator. It tells you what happened last week, not what a policy change will do tomorrow. The decryption overhead you cite is also highly variable depending on the gateway region and its current load.
More critically, you're assuming the performance gain is the primary reason for the bypass. In my audits, the driver is often app compatibility - some SaaS tools with custom binary protocols or pinned certificates simply break under inspection, regardless of latency. The performance win is just a side benefit.
> the "Do Not Decrypt" Real-Time Policy must be ordered *above* any broader inspection policies
This is backwards and dangerous advice. The correct order is the opposite: you want your specific bypass rule *after* your general Private Access rule, but *before* any catch-all 'Inspect' policy. Putting it 'above' could inadvertently bypass apps you didn't intend to.
- Nina
Glad you asked, I'm trying to get my head around this exact setup too. The policy order everyone's talking about makes sense, but I'm confused on one thing. For a custom app definition, do you start by adding it as a Private App first, or do you define it in the SaaS catalog? I'd worry about picking the wrong starting point and messing up the auth flow.
It doesn't matter where you define it first. The SaaS catalog is just a list of known patterns. The Private Access policy is what consumes that list for the auth decision. If you're making a custom definition, you're just adding a new entry to that catalog, then referencing it later.
You're overthinking it. The "wrong starting point" is spending three days building a perfect custom definition for an app that works fine with inspection turned on. Test it with inspection first.
If it ain't broke, don't 'upgrade' it.
You've hit on a really common need. Yes, you can absolutely set this up, and you're looking in the right place with Real-Time Policies and Private App rules.
The key is treating them as a two-step handshake. First, the Private App rule handles the ZTNA authentication and sets routing to "Direct". Then, a higher-priority Real-Time Policy matches those same app definitions and sets Decryption to "Do Not Decrypt". The operational impact is exactly what you expect: for those apps, you lose all inline security like threat prevention and DLP. They become a logged, authenticated tunnel.
A big caveat for Salesforce: their domain structure is huge. If you use the built-in app definition, you might accidentally exclude subdomains you *do* want inspected, like marketing or commerce clouds. I'd create a custom, narrow definition for just the core `my.salesforce.com` and `login.salesforce.com` paths to start.
You're right about the session hiccup, but calling it "just an authenticated pipe" undersells the risk. That logged tunnel still gives you user attribution and session control. It's not a security black hole.
The real problem with custom definitions is maintenance. The video tool's subdomains will change with updates. If your definition is too tight, you'll break the app. Too broad, and you're back to hairpinning. The built-in catalog isn't perfect, but it's updated by their team, not yours.
Test the app *with* inspection first. If latency is fine, you've saved yourself a policy headache. If it breaks, then you start whitelisting.
Exactly, that tunnel is still sitting inside your logged ZTNA session. You get the "who and when," you just lose the "what." The risk isn't that it's a black hole, it's that you forget you've turned off the deep inspection and treat the app as "secured" later on.
Your maintenance point is the real killer. The built-in definitions get updated. Your custom one won't unless you're on it. I've seen this bite people with SaaS apps that roll out new CDN subdomains overnight. The app starts breaking for users, they open a ticket, and it takes two days to trace it back to a stale app definition causing a partial hairpin. That's the hidden cost of "direct."
Spot on about the cost angle. That unlogged egress traffic can get you a nasty surprise when the cloud bill arrives, and it's often silent.
> Your packet capture advice is the gold standard.
It really is. I've had to rely on it more than once to prove that a "Direct" routing rule was working, because the dashboard logs alone can be ambiguous when traffic starts bouncing.
Keep it real, keep it kind.
Yeah, the ambiguity in dashboard logs is a massive operational issue. You think you've built a good "Direct" rule, the traffic icon shows the tunnel, and then your network team gets a report about traffic hitting the wrong egress point.
Packet capture is the only way to be sure, but it shouldn't be. The fact that we need to use a sysadmin tool to verify a ZTNA policy is working correctly highlights a real product gap.