We've been running Palo Alto Prisma Access for about 18 months. Overall, the security posture is excellent, but we've hit a persistent performance issue with real-time media apps, specifically Zoom and Microsoft Teams. The mandated full tunnel for all traffic creates latency and jitter that directly impacts call quality, especially for our remote users on varying home ISPs.
Our current policy pushes all user traffic, including Zoom/Teams media, through the nearest Prisma Access pop. While this gives us full inspection, the added hops degrade the UDP streams. I've quantified this with some basic benchmarks from a standard developer laptop (M1 MacBook Pro, 100Mbps home fiber):
* **Full Tunnel via Prisma Access (us-east1):**
* Ping to Zoom edge server: 42ms
* Jitter (via `ping -c 100`): 4-22ms
* Observed video resolution during test call: 720p with occasional drops
* **Direct Internet (split tunnel disabled for test):**
* Ping to same Zoom edge server: 18ms
* Jitter: 1-3ms
* Observed video resolution: 1080p stable
The trade-off between security and user experience is clear. I'm looking for concrete implementation strategies that balance both.
Has anyone successfully configured Prisma Access split tunneling *only* for these specific SaaS applications, while maintaining traffic inspection for everything else? I'm particularly interested in:
* The exact **SaaS Security** configuration or **Tenant Settings** you used.
* How you handle the security gap for the split-tunneled traffic. Are you relying solely on the app's own encryption, or layering in something else?
* Any measurable performance impact (good or bad) post-implementation.
* Gotchas with the Prisma Access client (GlobalProtect) and these exceptions.
Our ideal end-state: Zoom/Teams media UDP traffic egresses locally, while signaling, authentication, and all other web traffic still routes through Prisma for CASB and threat inspection. Is this a realistic configuration, or are we forced to accept the performance hit for full security?
Numbers don't lie
Your benchmarks really show the core problem. That jump from 18ms to 42ms is the difference between a seamless call and a frustrating one.
You can achieve a decent balance with a vendor-neutral approach: tunnel your non-media traffic and let the optimized media paths flow direct. The key is defining those paths precisely, not by app alone, but by the specific FQDNs and IP subnets Zoom and Teams use for their real-time media. Both vendors publish these lists. You build your split tunnel policy around them, which keeps the management and security traffic protected.
This does introduce a visibility gap, but it's a calculated and accepted one. You're trading full inspection of the media streams for a functional user experience, while still protecting the sensitive corporate data in the tunnel. The real work is in maintaining those endpoint lists as the services update.
Stay curious, stay critical.
Those latency numbers hit home. We went through a similar headache last year after moving to Google Workspace and adopting Zoom. Our security team was adamant about a full tunnel, but the user complaints were constant.
We ended up with a strategy similar to what user793 hinted at. We defined a policy to only tunnel the traffic needed for security (like our core SaaS apps and file servers), while letting Zoom's media IPs go direct. It wasn't perfect, but it reduced our help desk tickets for call quality by about 70%.
The tricky part for us was keeping the tunnel rules up to date as Zoom changed their infrastructure. How often does your team review the published FQDNs for these apps?
Migration is never smooth.