About SergGur

@yannogrodowicz- Thank you very much for giving good material for research. Please see my results below:   @yannogrodowicz wrote: The %variable% method definitely works if you have a GlobalProtect license, but you need to make sure your GP client version and your PAN OS version support it. (https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-new-features/globalprotect-features/split-tunnel-for-public-applications) I did multiple tests and it does NOT work. I also confirmed it with support and they acknowledged what was repeated many times of forums here - GP is running under SYSTEM space and unable to resolve variables from the USER space. Use curports tool on the endpoint or (( addr.dst in 13.107.64.0/18) or ( addr.dst in 52.112.0.0/14) or ( addr.dst in 52.120.0.0/14 )) and (bytes geq 100000000) on the gateway to see sessions still hammering the GP tunnel.   @yannogrodowicz wrote: I finally tested the split-tunneling based on Microsoft subnet list published here https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges#skype-for-business-online-and-microsoft-teams I excluded the routes to the following subnets: 13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14, and this was working great!   This dives some better result comparing with excluding app by name but very temperamental. On most of the cases, Teams.exe ignores local routes and goes to tunnel! But there is remedy!   Add this on the gateway: Source_zore: GP_RAS Source_IP:ANY Dest_zore:ANY Destination_IP: 13.107.64.0/18 52.112.0.0/14 52.120.0.0/14 Protocol and App: Not configured (e.g. any) Action:Deny Once added, I can see 4-5 UDP sessions blocked in rapid succession on the PAN every time Team call user starts the Voice or Video call but then user has great experience (local split tunnel exclude) and curports report UDP sessions using real machine IP   @yannogrodowicz wrote: Another interesting topic is Microsoft Stream and Microsoft Teams Live events, which are often used for virtual townhall meetings. Here my tests and wireshark captures showed the following: For MS Stream Live events: you'll need to exclude traffic to the following domain: *.azureedge.net port tcp/443 For MS Teams Live events: you'll need to exclude traffic to the following domain:  *.streaming.mediaservices.windows.net port tcp/443   I did research on MS documentation and came to similar conclusions, the number of IP subnets for underlying CDNs is too big to exclude, and DNS exclusion is the way forward. added domains to exclusion and this killed video links on https://stream.microsoft.com used for distance learning. As a result I to roll-back the change. The error is "stream%Region%%Number%.azureedge.net can not be reached" (where %Region% and %Number% is some stuff) I did not yet understand if this is an issue with Conditional Access because customer setup limiting o365 access from trusted locations only. ... View more