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 

[RLJFRY]

Re the Variables working / not working, I’d also like to see some official documentation from Palo on this rather than community posts. 

For example I have a case open with Palo support right now that have referred me to this post to show that Variables do work. 

I replied saying that I am aware of this thread as I’m in it and I’d like official documentation on this rather than community driven information (no offence meant). 

The engineer then referred me to another thread which looks like it’s a community written article:

https://live.paloaltonetworks.com/t5/General-Articles/GlobalProtect-Implement-Split-Domain-and-Appli...

Im interested @bspilde what you were saying in that Palo said variables will not work. Have you got a ticket re this with them?

Personally I’m struggling with GP split tunnelling right now. - I want to send ALL traffic down the Tunnel EXCEPT “xyz”

I was therefore advised by PA support to enable split tunnelling (untick “Disable the No direct access to local network”) and add 0.0.0.0/0 in the include and add the objects I want to exclude in the appropriate exclusions fields.

The end result is that the domains I add into the domains exclusions are no longer reachable whilst the tunnel is established. The same issue is happening for video traffic (after I enabled the video so go directly) - no video traffic can be played whilst the tunnel is established.

The other things I’ve come to discover are the following, and I’d welcome anyone’s feed back on this:

1. Limitation 1: We can only add up to 10 entries in the "Access Route" Include / Exclude?

2. Limitation 2: We are not able to utilize "Address Groups" in the "Access Route" Include / Exclude?

3. The question re the variables which seems to be up in the air. 

Im running PanOS 8.1x

The PA support person I’m talking to says that these limits are not correct as of PanOS 8.0.2.

Again, I’d welcome anyone else’s comments as I’m banging my head against a break wall on this one. 

Am I getting this wrong!?

Thanks

[recross]

Pretty sure access routes and all splits have a 100 line limit.

You can use address-groups but there is a limit on group members, IDK this limit but it exist. 

What are you trying to Split?

Splitting applications leveraging systems variables is possible leveraging the "%variable%" format in the path. 

Palo documentation is based of enabling the functionality and features, not direct engineering of a split tunnel configuration. 

[bspilde]

@RLJFRY  Yes I do have a ticket open with Palo. According to the document you referenced, they are doing domain based AND EXE based. However, that example they provided wouldn't need the EXE excluded so having it "work" using a %userprofile% in the path is a false sense of accomplishment. It would have been the domain that made it work.

@recross 

Also in my meeting with him today, what he explained is that when you do an application/EXE based split tunnel, it only lets you reach out to the first destination that EXE requested. So for example outlook.exe requests access to outlook.office365.com but the IP it really connects to for data is a CNAME for something like mdw-efz.ms-acdc.office.com then you will not see outlook.exe doing a split tunnel. You in this case have to do it based upon domain and include both *.office.com and *.office365.com. Outlook only successfully split tunneled for me when both domains were bypassed and I didn't even use the EXE because it doesn't do any good. Therefore, I've never done a %variable% based path because these EXE's in those paths have to communicate with more than one destination anyway and wouldn't know if it worked or not because it wouldn't work 100% anyway.

Here's another good reference for split tunnel: https://live.paloaltonetworks.com/t5/General-Articles/GlobalProtect-Optimizing-Office-365-Traffic/ta...

[bspilde]

I take that back... it shouldn't need the EXE if the domains are listed but I removed the EXE path to outlook.exe and now my client is no longer Split-tunneling Outlook traffic. Seems none of the split-tunneling features work as expected except for the IP/subnet based split tunnel settings.

[Alex_Samad]

Wow, hate to say this, but its a lot like some of the technical issue i have had with PA support.

I have to admit I get better responses here on the forum -from PA employees then I do from the support line.

The best response I have gotten from previous times is when you get to a L3 engineer, make your way past 1 & 2 ...

And my SE's...

So at least for me the license isn't worth the $$$. subnet split routing is working. although there is a limit to the number of routes.

Have actually started to look at 4rd party VPN solutions.  And my firewalling guys is started grumbling about maybe its time to think about moving off PA .. purely around the support

[bspilde]

Alex,

I would say get the license for the HIP check capability but that isn't working right for me right now either. 🙂 

I will say, I see much better support from Palo Alto than I do from any other vendor I have worked with. If there is a bug to identify or open, Palo is much more willing than say, Cisco to do so. It might take a bit for a bug fix but it will be a correct fix without adding more bugs. Generally speaking, I don't run into work stoppage bugs with Palo like I do with other vendors either. There is always some sort of a workaround or its just an administrative bug.

I am a Palo Alto Networks Ambassador member and have had some influence in direct conversations with the VP of support in the past. I've unfortunately instigated an emergency meeting of all the VP's in the company that lead to significant improvements to quality of code released and the support provided to customers. They implemented numerous changes and are still working on some of those suggested improvements even, such as customer ticket level changes from high to critical, more specialized support teams vs having to know everything, escalation process improvement, web support improvement, and so on. Yes, there are frustrations at times and yes my SE is always wondering what I came up with now when he sees my caller-ID, but the channels are there and your SE should always be your best friend so treat them well. 🙂

[bspilde]

Oh, and I forgot to mention, my SE is escalating this up the chain so we can get engineering to realize the importance of making this operate how all of using the this thread are expecting it to function. I'll post updates as progress occurs.

[wiresharky]

I've talked multiple times to PA support, but also Microsoft support.

from what i've learned, excluding all the office365 ranges should work to some extend, but not in all instances.

I've excluded all the ranges (see below current output from my minemeld instance).

Office365/teams uses it's own routing protocol(!!!) and bypasses the installed routes by global protect. This results in teams still routed through the VPN tunnel for some users. This is not a PA issue (i noticed other vendors have the same issues) but a Microsoft issue.

I've opted them implementing a fix so office365 can be forced to follow the routing table as any other normal application, but of course they are not responding.

My recommendation: use all the ranges provided (don't bother with fqdn or application executables) and log a case with Microsoft about this issue. 

[code]

104.146.128.0/17
104.215.11.144
104.215.62.195
104.42.230.91
104.47.0.0/17
13.107.128.0/22
13.107.136.0/22
13.107.140.6
13.107.18.10/31
13.107.3.0/24
13.107.6.152/31
13.107.6.156/31
13.107.6.171
13.107.64.0/18
13.107.7.190/31
13.107.9.156/31
13.70.151.216
13.71.127.197
13.72.245.115
13.73.1.120
13.75.126.169
13.80.125.22
13.89.240.113
13.91.91.243
131.253.33.215
132.245.0.0/16
138.91.237.237
150.171.32.0/22
150.171.40.0/22
157.55.145.0/25
157.55.155.0/25
157.55.227.192/26
191.234.140.0/22
20.190.128.0/18
204.79.197.215
23.103.160.0/20
40.104.0.0/15
40.107.0.0/16
40.108.128.0/17
40.126.0.0/18
40.81.156.154
40.90.218.198
40.92.0.0/15
40.96.0.0/13
51.140.155.234
51.140.203.190
51.141.51.76
52.100.0.0/14
52.104.0.0/14
52.108.0.0/14
52.112.0.0/14
52.163.126.215
52.170.21.67
52.172.185.18
52.174.56.180
52.178.161.139
52.178.94.2
52.183.75.62
52.184.165.82
52.228.25.96
52.238.106.116
52.238.119.141
52.238.78.88
52.242.23.189
52.244.160.207
52.247.150.191
52.96.0.0/14
52.120.0.0/14
[/code]

[cafowler]

@RLGFRY - same sort of issue with our config / support ticket.  The tech presented some suggestions that didn't make logical sense.  We are on PAN-OS 9.x and our exclusions are configured by subnet only, and individually, even though we can use address groups in 9.x.  We are also only interested in Teams traffic at the moment.  We have verified that some Teams traffic is leaving via the local gateway but also that some Teams traffic is coming back through the VPN.  The solution we ended up using was to create a deny policy to the same 3 subnets we used via Split Tunnel as exclusions.  Through testing we have been able to verify that we can see this traffic being denied by the new policy and also that Teams is not broken (at least not yet).  Here is the MS article, which you've probably already read, it was under the Configuring and Securing Teams Media Traffic section.  https://docs.microsoft.com/en-us/office365/enterprise/office-365-vpn-implement-split-tunnel#configur...

I wanted to share with the community, since, simply using the subnets may not be the answer.

Cheers,

CF

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

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

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.

[yannogrodowicz]

@SergGur Thanks a lot for your comments and your detailed explanations!

I am happy that so many people shared their personal experience in this thread, and I am deeply convinced that as a community we can work around some of the big challenges we are all facing at the moment. 

My post was just the starting point, when I was saying that the %variable% method works, I was meaning that it is possible to configure some tunneling exclusions based on applications with the %variable%. I tried it as well and it seemed like some of the MS Teams traffic was not tunneled anymore, so I assume the GP Client could recognize that some of the traffic was originated from this application. Nevertheless, I quickly started facing some issues with some of the MS Teams features (like online meetings for example). I agree with you when you say that this method does not work for MS Teams.

Have you tried this with some other applications as well?

[Sec101]

After reading through a lot of this, are most of these posts basically saying that none of the mentioned solutions are foolproof, and consistently work?  

[rgunna2020]

where do i check to see if i have subscription or not?

I still have the same problem video exclusion from split tunnel does not work

[SergGur]

@rgunna2020 What application are you trying to optimize? Are you talking about the MS Teams?

[PaulArcellx]

I'm still running into issues years later with trying to only exclude zoom traffic.