- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-17-2020 03:24 AM
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:
C:\Users\*\AppData\Roaming\Zoom\bin\Zoom.exe
04-07-2020 01:43 AM
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.
03-17-2020 09:12 AM - edited 03-17-2020 09:20 AM
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.
03-18-2020 01:04 AM
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.
03-18-2020 03:47 AM
03-18-2020 09:24 AM
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.
03-18-2020 09:36 AM - edited 03-18-2020 09:40 AM
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.
03-18-2020 10:07 AM
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.
03-18-2020 10:23 AM
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 52.202.62.202:443 CLOSE_WAIT 8680
[Zoom.exe]
TCP 10.0.2.168:53002 213.244.140.46:443 ESTABLISHED 26124
[Zoom.exe]
TCP 10.0.2.168:53043 52.202.62.243:443 CLOSE_WAIT 26124
[Zoom.exe]
TCP 10.0.2.168:64912 52.202.62.248:443 ESTABLISHED 8680
[Zoom.exe]
TCP 10.0.2.168:64922 3.208.72.69:443 ESTABLISHED 8680
[Zoom.exe]
UDP 0.0.0.0:53997 *:* 26124
[Zoom.exe]
UDP 0.0.0.0:53998 *:* 26124
[Zoom.exe]
UDP 0.0.0.0:59513 *:* 5236
[PanGPS.exe]
UDP 0.0.0.0:60162 *:* 26124
[Zoom.exe]
03-18-2020 10:52 AM
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?
03-18-2020 11:18 AM
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,...:
03-18-2020 01:43 PM
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,
*.zoom.us
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.
03-18-2020 02:42 PM
Hello,
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?
Regards,
03-19-2020 12:55 AM
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.
03-19-2020 12:58 AM
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.
03-19-2020 03:39 AM - edited 03-19-2020 03:46 AM
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
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClQjCAK
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
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!