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:
Solved! Go to Solution.
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.
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:
If I run your command I do not see anu udp/8801 connection for some reason I don't understand:
TCP 10.0.2.168:51592 126.96.36.199:443 CLOSE_WAIT 8680
TCP 10.0.2.168:53002 188.8.131.52:443 ESTABLISHED 26124
TCP 10.0.2.168:53043 184.108.40.206:443 CLOSE_WAIT 26124
TCP 10.0.2.168:64912 220.127.116.11:443 ESTABLISHED 8680
TCP 10.0.2.168:64922 18.104.22.168:443 ESTABLISHED 8680
UDP 0.0.0.0:53997 *:* 26124
UDP 0.0.0.0:53998 *:* 26124
UDP 0.0.0.0:59513 *:* 5236
UDP 0.0.0.0:60162 *:* 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:
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,...:
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!