Exclude all Zoom traffic from GlobalProtect VPN

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Exclude all Zoom traffic from GlobalProtect VPN

L3 Networker

We have been trying to exclude all Zoom-related traffic from the GlobalProtect VPN tunnel.


So far we have tried with: "*.zoom.us" exclusion configured directly on the GP gateway as a domain in:

Network --> GlobalProtect --> Gateways --> GW NAME --> Agent --> CLient Settings --> Split tunnel --> Domain and Application


But this seems to not completely do the trick as Zoom use some AWS default domains, not under *.zoom.us.


What approaches will work that does not involve having to manually exclude all the IP ranges as defined here?



The Zoom binary path seems to be this one, but I'm not sure PA supports wildcards on the path like this:



1 accepted solution

Accepted Solutions

L3 Networker

I finally found the solution. On our case, having the Zoom binary in %AppData% was making the split tunnel not working correctly and Zoom UDP/8801 traffic was sent through the tunnel.


We end up deploying the Zoom package centrally with SCCM to al laptops. Now, with Zoom on C:\Prgoram Files x86 the Zoom exclusion by Process is doing the trick finally.

View solution in original post


L3 Networker

Hi Marchel,


Wildcards are not supported in the path, try one of the following variables %appdata%\Zoom\bin\Zoom.exe or c:\users\%USERNAME%\appdata\roaming\zoom\bin\Zoom.exe and let us know the outcome.

It's not working. After pushing changes & refreshing still can see some tcp/8801 Zoom connections going through the GP gateway.


I found the documentation not good enough on this specific feature.

Make sure your GP client fetches the new configuration from the portal.

The best way to make sure you fetch the latest config from your portal is by restarting the PanGPS service or rebooting the computer.

Performing a refresh connection action on the GP client options not always forces the client to request the lastest portal configuration as it may depend on how you configure the client connection.

We did that, the only difference is in our case the path is different:


"%AppData%\Zoom\bin\Zoom.exe" instead of: "%AppData%\Roaming\Zoom\bin\Zoom.exe".


But we keep facing the same issue: all traffic is correctly split tunneled except for the UDP traffic going throug port udp/8801 (which is the most bandwidth consumption).


And thanks for the tip, but yes we were doing the "Refresh connection" after each change.

In windows, run the command: "netstat -anob" to verify if traffic is generated by zoom's PID and executable [Zoom.exe].

Make sure you are using our latest GP client version 5.0.8 or 5.1.1.


Here the sessions I was talking about that still going through the GP VPN:

PA log.png


If I run your command I do not see anu udp/8801 connection for some reason I don't understand:




UDP *:* 26124
UDP *:* 26124
UDP *:* 5236
UDP *:* 26124


The netstat output shows that UDP traffic is going through the physical interface, hence, the heavy traffic is being split. Only the TCP traffic with Destination Port 443 is going through the tunnel.

Your traffic logs which illustrate the UDP traffic are from one hour and a half ago. 

Are you still seeing UDP traffic on the latest traffic logs?
If so, are they from a device that was recently connected or have verified it received the latest Prisma Access - GlobalProtect Portal configuration?



My last reply was not send somehow..


Here you can see the exceptions we have in place:

PA excpetions.png

Here you can see all the Zoom traffic from my user that is tunneled through the GP VPN instead of doing local breakout. The amount of bytes is huge. And this is only happening with the udp/8801 traffic for some reason.

It's still happening, after refreshing connection, restart,...:

PA logs 2.png

L0 Member

Same type of behavior on my end, so I went ahead an added the Zoom IP blocks listed for port 8801:



Which came out to be 57 entries. Doing this seems to have helped, somewhat, while doing 1-on-1 tests, I wouldn't see traffic show up in the firewall logs, even testing with other users, however we now have ~3,000+ employees working remotely, so I am starting to see these logs appear but it seems not as much as you would think. I have a case open with Palo Alto, they are able to replicate but unable to provide a solution.


On top of adding the IP blocks, we are excluding the domains,



and application processes for both PC and macOS


Macintosh HD/Applications/Zoom.app
C:\Program Files (x86)\Zoom\bin\Zoom.exe



This article gives great instructions but doesn't obviously seem to work.


I am also attempting the same with BOX and will see how things go in the coming days.



You might want to check your companies policy and regulations regarding split tunnels as most dont allow it. I'm sure there is a reason for the request, however why would you want to lose that viability?



Thanks for the feedback, seems you are facing the exact same scenario.


In our case, we want to avoid add the network ranges as it's something we would need to keep updated as they add/remove ranges, plus we would need to do manual configurations in multiple gateways. The API could be an option to automate this, but anyway we would need to keep an eye at Zoom article while their add/remove them.

There is not much added value on sending Zoom traffic through the VPN when Zoom is classified as a low-risk app by applipedia, it's an allowed application meaning no need to block/restrict, we want to give this application the best performance due to the current situation (and send it through the VPN is for sure not the way to achieve this). The only thing we might lose here is the ability to see&block files transfers as they flow through the Zoom sharing connection, but that's something we accept.

Can you start a zoom meeting with screen sharing and video ON. Add at least 2 people with video


While on meeting run - netstat -aenob




Also, for IPs in the traffic logs, enable host lookup, by checking the box at bottom. Resolve hostname. And share the screenshot again. Above link will help





~ Sai Srivastava Tumuluri ~
  • 1 accepted solution
  • 59 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!