Hello to All,
I had to use several options in the split tunel options to solve VPN issues and I decided to share it.
1.The first issue we had is that some applications may not work when doing split tunnel for users with a particular operational system, so we used the options to do split tunnel configurtion based on operational system (for this you don't have to enable HIP data collection under the portal). Split tunnel is great if the CPU on the firewalls is jumping and as of the Covid many of us work from home the firewalls need this:
Also when doing a change on the globalprotect agent config on the portal you can enable the new config just for test AD users and groups just in case:
2. Another issue was with the zoom as it has too many ip addresses, so doing an optimized split tunnel based on domain and app is really nice feature that not many other vendors have and you may even split dns resolution for the excluded domains:
We used this to try solving the issue with the Invalid Address Errors as mentioned in https://live.paloaltonetworks.com/t5/general-topics/globalprotect-split-tunnel-some-clients-get-inva... . I think the issue is that for some split tunnel configurations only on address and domain some of the traffic for the excluded addresses is send over tunnel. Other vendors like F5 Big-IP suggest blocking the traffic on a firewall, so that any traffic that shouldn't be in the vpn tunnel does not pass the firewall and this sometimes solves the issue but I suggest first doing split tunnel from the article for zoom and split DNS and this is final option to also block the traffic from the VPN zone to the outside.
3. I also had issue Wi-Fi confirmation captive portals in the hotels with the free wi-fi but the community helped me with this with the options. Also "Enforce GlobalProtect for Network Access" was enabled and this causes the Palo Alto to work differently with the captive portals :
I suggest reading:
4. For Proxy issues with the VPN you can check:
5. Another issue was PanGPS error 'network type is unknown network' and we are still testing using fake FQDN that will fail and make the agent t realize that the network is external as we have only external gateways and this seems like a bug to me and we also upgraded to latest 9.1.x version and also the globalprotect agent itself, just in case.
For more about the palo alto logs (PanGPS and PanGPA are the most important but if you use HIP reports and OPSWAT checks there is also log for that):
6. In 9.1.x it is great that the Globalprotect log is in seperate tab in the GUI and you can also see latency reports from it, so this helps with investigating bad network connections and that the issue is not with the VPN, also if the hourly HIP reports failed for some reason, it will be in those logs. For HIP issues other than failed HIP reports like failed checks there is a log from a long time in GUI called "HIP Match Logs":
Also for HIP checks failing to be send every hour check:
7. Don't forget also for the great community article about Globalprotect MTU:
An issue that we had that is not related to globalprotect but I will menton it is when a client was using site to site GRE tunnel and the GRE tunnel does not automatically adjust the MTU size with MTU discovery as the IPSEC tunnel, so the traffic was getting dropped by the firewall as also the do not fragment bit was configured, so by checking global counters we saw the issue. I recommend for such issues checking:
8. Also if you need to test some Globalrotect changes and the option to have sepertate configs based on AD user/group or operational system then don't forget that you can add another public ip address on the same interface on the firewall where the portal or gateway is located and just make second test portal or gateway. For example testing something like different port for the portal/gatway communication https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClKPCA0 . Better first do such tests on a second test portal/gateway then on production.
9. A final thing is to always check that the traffic is that if ipsec is enabled and failovering to SSL as SSL has bad performance when compared to ipsec. On other vendors like F5 Big-IP the workaround is to use DTLS for VPN but I found out that it can't do automatic switchover between TLS and DTLS like palo alto does for SSL and IPsec:
10. As point 1 I mentioned CPU being high because of the too much VPN traffic and Palo Alto has some nice recomendations for this for extra optimizations:
11. Anothe note is if your windows admins want for example to run scripts at computer bootup even before the VPN is started and you have "Enforce GlobalProtect for Network Access" then you my try the ''pre-logon VPN'' or ''connect before logon'' options.
12. Always read the "Features Introduced" for the globalprotect app at helps very much and also the "Customize the GlobalProtect App" should be read by anyone working with Palo Alto VPN from time to time as for example the option "User Switch Tunnel Rename Timeout" can solve RDP issues with the VPN (there is an issue with the ip to user-id mapping even outside the Globalprotect VPN when using RDP and you can read about it here https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CleBCAS ). The option Windows SSO is also great even if you use RSA tolken MFA on the gateways as atleast the signing will be automatic after 24 hours when you again to sign the portal with your AD credentials as with 'pre-logon'' or "start before logon" or using different authentications on the portals and gateways the Cookie Authentication that allows when you log to the portal to not log to the gateway does not work.
13. Another usefull option is to "Install in Local Root Certificate Store" expecially if you replace globalprotect portal/gateway certficate with another SSL vendor provider certificate:
14. For Clienless VPN there are great Palo Alto articles hos to discover issues:
I also suggest checking the offcial palo alto article for "Troubleshooting GlobalProtect"
Just as a note I have issues with my old community account, to this is why I am using new one for now.
Palo Alto is great but they lack some available documentation for example for which log file should be checked for which issue etc. When you have some work with the palo alto TAC, you start to see somethings that are not officially documented. I also use my articles for something like One Note as I will be using them myself as things can be forgotten over time, but better share if I am going to write it anyway.
Also from what I see most people like to open a case and wait 2 or 3 weeks for the issue to be resolved than reading for 2 or 3 hours or checking if there is a solution in the community, because this way they don't take responsibility and can get by without reading too much and because of this just write an email or call each day with "....ASAP ......URGENT.....", so the TAC will still have more cases than they can handle but this article is for the small amount of people that want to solve their issues if possible themselves. Yes, some cases need TAC support but many don't and if you are not paying for premium support, you can't expect a solution from the TAC in 1 hour. This is at least how I see it.
Still the Palo Alto TAC needs some improvment as I have found more answers on my own in the community articles or even found out that some things are not like day say at all. The Example is:
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!