This is the method I used. It has worked flawlessly ever since, no issues.
I did notice some traffic escapes to the tunnel for teams, however it seems to be talking to subnets outside of the scope supplied by microsoft. This has not caused any issues, and since making changes everything has improved.
@CoreyKinder which method the one with variables ?
I tried it and ran into similiar problems earlier people had. some staff would work and some wouldn't
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...)
Just wanted to quickly share about my experience on this, as some of you may have been or will be in a similar situation:
- Configuring split tunneling for the Teams.exe process located under %userprofile\AppData\Local\Microsoft\Teams\current\Teams.exe does work but we had a lot of issues with users that could not join MS Teams Meetings. Video calls and audio calls worked fine, but the main issue was with online meetings. It could be that Teams creates sub-processes or uses some system resources in the background, I have not dug deeper into this.
The reason why we considered to configure split tunneling was to reduce the load and bandwidth consumption on our VPN Gateways (Netflow is a good indicator to see that MS Teams video/voice traffic on ports UDP/3478, UDP/3479, UDP/3480, UDP/3481 is far from being negligible) and to provide our users with the best possible audio/video experience (back homing the traffic over a long distance may be sub-optimal, and Microsoft designed their solution in a way that the client will always connect to the best possible Microsoft PoP and all the traffic will then run on Microsoft's backbone).
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-...
I excluded the routes to the following subnets: 18.104.22.168/18, 22.214.171.124/14, 126.96.36.199/14, and this was working great!
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
Microsoft definitely do not make our life easy since they leverage CDNs for this.
I have not tested it very thoroughly but found it fun to see how these services work, so please make sure to test it thoroughly and from different regions if you need to go down the split-tunneling route for these services
Please note that you'll probably need a GlobalProtect license for this, and the scope here is large, therefore you should definitely clarify whether this is acceptable or not with your IT Security Officer. This configuration is done on the GlobalProtect gateway directly!
Regarding Webex, a full list of subnets to exclude can be found here: https://help.webex.com/en-us/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network
I did not test the split-tunneling for Zoom meetings, but found the following article on Zoom's KB: https://support.zoom.us/hc/en-us/articles/201362683-Network-Firewall-or-Proxy-Server-Settings-for-Zo...
All the information shared here are coming from my personal analysis and you should be careful before implementing it as security is a critical aspect in the RA VPN infrastructure and you should make sure that the split tunneling configuration you make complies with your corporate policies/requirements.
I hope this helps.
@yannogrodowicz thanks for the input.
We were using the trial license, but they way they charge, we will not being buying.
As for the
our issue was some users could connect and some couldn't always the same when i remove that it works as expect.
So I have gone back to downloading the ip's and creating rules for GP.
That's some helpful insight there, and much appreciated.
I'd already read the article re the split tunnel features (https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-new-features/globalprotect-features/split-tunne... but I couldn't find any mention of variable support. I'll take your word for it.
It's good news that you managed to bypass the MS Teams traffic using a mixture of the variables and subnets, I'll look to do the same. It's a shame that the Split Tunnel doesn't support EDL's as I could have utilised Minemeld for this without doubling up my work. Anyhoo, this is good news you got it to work!
Could you advise as to when you experienced the changes take effect on the VPN clients? From the general consensus it seems to be once a VPN client has made connection, disconnects and reconnects. This would make sense as if gives the client the chance to pull the policy update and apply it on next connection.
Finally, and I ask this question because I couldn't seem to get it to work... It would be good to see if an excluded Client Application Process Name (not IP or domain) is bypassing the tunnel and going direct, or at least some of it's traffic.
I know I could look at the FW logs, but that would obviously only show me traffic that the firewall is seeing and therefore routing over the GP VPN, not what traffic is going direct. I know I could run a netstat on the clients and get the apps process ID and see what connections it's making, but that wouldn't show the route the process is taking.
Using tracert/traceroute isn't going to work either as that's not the App Process we're whitelisting. - It's Team.exe or Zoom.exe for example that the GP VPN client is looking out for to bypass and not tracert.exe
I tried adding the paths to tracert.exe to the Client Application Process Name but this didn't seem to work, yet adding IP exclusions such as 188.8.131.52 happen pretty much straight away. So it made me wonder if the Client App bypass was working at all?
Does anyone know of a way of proving the Client App Process is bypassing some traffic at least? I think I'm overlooking something quite simple? It's been a tough couple of weeks on the brain haha!
Just wanted to clarify that in the end I removed all the split-tunneling config based on process name, and then tested with subnet exclusion for the 3 subnets 184.108.40.206/18, 220.127.116.11/14, 18.104.22.168/14. The latter worked in all situations.
I agree with you that EDL integration would be nice, but can imagine it's not that easy, hope Palo Alto Networks will find a way to make this happen.
Regarding the test of split tunneling config based on Process Name, the following steps are required for the config to become effective:
- Close the application (Process Teams.exe for example)
- Refresh connection in GlobalProtect client
- Start the applicatoin (Teams.exe)
To see which path the traffic is taking, I use wireshark on my Tunnel adapter interface and ethernet/wifi adapter interface, and filter traffic to the GlobalProtect gateway IP (to avoid all the SSL or IPSec traffic to get captured).
If you have split tunneling configured, you can see the traffic going out on the ethernet/wifi adapter, otherwise it'll go out on the tunnel adapter interface.
Otherwise you can use "netstat -anbo" in a cmd Window that you run as administrator. You'll see if the originating IP address belongs to your tunnel network adapter or your physical network interface
I hope this helps.
Thanks @yannogrodowicz for confirming.
Yes, of course re the "netstat -anob". I'm so used to looking at the Foreign Address in the results, I didn't stop to look at the Local Address.
Another limitation I've found, at least on our PanOS revision, is that there are a limitation of 10 IP entries that can be entered into the INclude / EXclude fields for the GP Split tunnel "Access Route". Adding more entries just overwrites the existing ones!
Unfortunately it doesn't support Address Groups either, so you're forced to enter address entries or point to existing entries in the Address objects table.
I've reached out to PA support on my existing case to see if this still exists on all the PanOS versions.
Otherwise some may be forced to widen the subnet range in the entries, which would obviously be quite risky.
Thanks again for your help and confirmation.
BTW: I'll post the info I get back from PA support here.
I checked on 9.2 beta and I didn't see that anything has changed for address support.
Also, I am being told engineering is working on a solution to the MSTeams.exe path being different.
Couple thoughts to throw out for some feedback on feature enhancements:
You said "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...)".
However, I don't see anywhere in the document that %variable% is supported. In addition to that, I have tested it and it doesn't work. Palo Support also says that will not work.
As mentioned in another reply to this, Palo Support has stated engineering is working on a solution to MSTeams.exe. I have been given no idea when this might be implemented but it is allegedly on the roadmap.
You should try to implement a domain and IP based split. The traffic you do see coming back will be UDP and destin for *:*. You will see this traffic on both your home and VPN interfaces. You should not see any TCP traffic for the subnets below on your home interface.
All subnets and domains are sources here - https://endpoints.office.com/endpoints/Worldwide?ClientRequestId=b10c5ed1-bad1-445f-b386-b919946339a...
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 Live Community as a whole!
The Live Community thanks you for your participation!