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:
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!?
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.
@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.
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...
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.
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
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.
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.
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.
220.127.116.11/17 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52/17 184.108.40.206/22 220.127.116.11/22 18.104.22.168 22.214.171.124/31 126.96.36.199/24 188.8.131.52/31 184.108.40.206/31 220.127.116.11 18.104.22.168/18 22.214.171.124/31 126.96.36.199/31 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168/16 22.214.171.124 126.96.36.199/22 188.8.131.52/22 184.108.40.206/25 220.127.116.11/25 18.104.22.168/26 22.214.171.124/22 126.96.36.199/18 188.8.131.52 184.108.40.206/20 220.127.116.11/15 18.104.22.168/16 22.214.171.124/17 126.96.36.199/18 188.8.131.52 184.108.40.206 220.127.116.11/15 18.104.22.168/13 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206/14 220.127.116.11/14 18.104.22.168/14 22.214.171.124/14 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11/14 18.104.22.168/14
@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.
@yannogrodowicz- Thank you very much for giving good material for research. Please see my results below:
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 22.214.171.124/18) or ( addr.dst in 126.96.36.199/14) or ( addr.dst in 188.8.131.52/14 )) and (bytes geq 100000000) on the gateway to see sessions still hammering the GP tunnel.
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: 184.108.40.206/18, 220.127.116.11/14, 18.104.22.168/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!
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.
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!