Global protect split tunnel setup

[Alex_Samad]

Hi

I have 8.1.5 on the pa and 4.1.11-9 client

I have setup the gateway for video traffic exclusion, and selected 

youtube-streaming

netflix-streaming 

But a simple test shows utube still come over the tunnel address

I want to allow MS Teams to by pass the tunnel, so I goto agent / client setting select my config and split tunnel 

domain and application 

but the app runs from 

{userprofile}\AppData\Local\Microsoft\Teams\current\Teams.exe

how can i enter that into the config 

[wiresharky]

nice!

i have minemeld running and will use that as a source.

Do any of your users have issues with teams joining meetings or sharing their desktop?

I've got mixed results.

[Alex_Samad]

Seem like the nice people at PA have opened up trial license for 3-6 months for GP.  which will allow me to use all these nice features.

So instead of having to do it by ip address I should be able to do it by app / process ..

[Alex_Samad]

Moved to trying 

%userprofile%\AppData\Local\Microsoft\Teams\current\Teams.exe

turned it on and MS Teams stop working for some and still working for others 😞

[RLJFRY]

Hi all, 

Am I reading this right in that PanOS doesn't seem to support environment %Variables% in the path name of the executable you're trying to add to the "Include/Exclude Client Application Process Name" fields, be it with or without a GP license!? That's big oversight if that's the case. Has anyone got this confirmed by PA support?

If it makes a difference to the PanOS, we're at 8.1.x and have a GP license.

I'm basically also looking to add Teams and Zoom to the exclusion list by executable, but it's pretty pointless if neither will work? Or is Zoom working using the .exe path name in conjunction with the IP exclusions for it's IP blocks?

Also, are you guys seeing the new GP config changes apply after reconnecting / disconnecting and then reconnecting the GP client again? - I asked PA support when the GP configs get applied and they weren't sure, and advised me that's it's best to uninstall the GP client and clear a registry key and remove the GP services following a config change, and referred me to the following article: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJDCA0

This seems rather drastic!

Thanks,

John

[Alex_Samad]

 Wow support don't know !

I find it strange you have to remove the client. 

when i make changes to the split tunnel withe routes they seems to show up after a disconnect reconnect.

if they don't support %Variables%, then you can't really do teams can you ?  Wow 

[CoreyKinder]

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.

[Alex_Samad]

@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

[yannogrodowicz]

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: 13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/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.

Cheers.

Yann

[Alex_Samad]

@yannogrodowicz  thanks for the input.

We were using the trial license, but they way they charge, we will not being buying.

As for the 

%userprofile\AppData\Local\Microsoft\Teams\current\Teams.exe

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.

[RLJFRY]

Thanks @yannogrodowicz 

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 8.8.8.8 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!

Thanks!

John

[yannogrodowicz]

Thanks @RLJFRY and @Alex_Samad for your replies!

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 13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/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.

Yann

[RLJFRY]

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.

[bspilde]

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:

1. What I'd really like to see is that there is no path dependency such as done with PulseSecure, and even the option to require a specific MD5 hash of the file/version. 
2. Best scenario would also be that Split Tunneling be subjected to HIP requirements. Unpatched or disabled host firewall disables split-tunnel.

[bspilde]

@yannogrodowicz 

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.

[recross]

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...

13.107.3.0/24

13.107.64.0/18

52.112.0.0/14

52.120.0.0/14

*.lync.com 80,443

*.skype.com 80,443

*.skypeforbusiness.com 80,443

*.teams.cdn.office.net 80,443

*.teams.microsoft.com 80,443,3478,3479,3480,3481

teams.microsoft.com 80,443,3478,3479,3480,3481