About OwenFuller

I have never configured IP addresses on my GlobalProtect tunnel interfaces.  When you specify routes in the Split Tunnel Include section, these will get installed in your computer's route table as "on-link" routes pointing to the IP that your GP interface gets from the pool.  It looks something like this: In this case, I'm tunneling everything (0.0.0.0/0), and my GP interface IP address is 172.X.X.X ... View more

I saw this occasionally on version 5.1.0-75 of the GP agent after we did an upgrade from 5.0.x via SCCM without doing a clean uninstall of the old client.  Generally we were able to fix this by simply going to Settings > Sign Out and then reconnecting. ... View more

Looks like the official advisory is out, and the suggestions are to do the exemptions like most of us have been talking about already:  https://live.paloaltonetworks.com/t5/customer-advisories/decryption-errors-created-by-the-expired-addtrust-external-root/ta-p/330976  What a mess.  Good luck w/ your exemptions everyone! ... View more

We only saw about ~50 destinations w/ decrypt-cert-validation as the session-end-reason in our logs, and several seem to be junk we don't really care about.  We're opting to leave expiration on for most user traffic.  We've created a custom URL category for affected sites which are business-related, and are using it in a separate SSL decryption policy that doesn't block the expired cert.  Seems to be the best option to avoid completely disabling cert expiration checking for our purposes. ... View more

According to the KB article TAC referenced (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UFBCA2), the new CA certs are already in the CA store on the firewalls.  It's saying that the problem is due to "Some servers that are using certificates signed by these CAs are still including the expired CAs as part of certification chain supplied to the client." It also mentions that "Our NGFW Trusted CA store is already updated with the self-signed certs, and no change is needed to Trusted CA store on PA."  However, given that the chains build properly on other systems, and there are know issues with certain clients (see my previous comment), this still seems to be a problem with PANOS (a la OpenSSL) in my opinion.  We're going to continue working w/ TAC for answers. ... View more

As @kalakai said, this problem appears to be related to OpenSSL incorrectly building the trust chain for certificates which used to chain up to the now expired Sectigo CA cert.  This article (which we're also providing to TAC on our own case) provides a very detailed explanation for those who are interested:  https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020   ... View more

One additional caveat I found while talking w/ my coworker was that we traced the issue to a combination of GP version 5.0.4 and our Wireshark installations, which included npcap version 0.9x with legacy loopback support enabled.  If you cannot upgrade GP to a newer version, you might see if the Wireshark/npcap issue applies.  You can uninstall npcap, and re-install Wireshark without selecting the legacy loopback support. ... View more

Is updating allowed in your user agent config?  Go to your portal > Agent > your agent config > App and make sure that the Allow User to Upgrade GlobalProtect App setting is configured to an Allow option.  Also, I can't find any documentation to support this, but I'm wondering if the jump from version 4.1 to version 5.1 isn't supported through automatic updates. ... View more

We had problems with 5.1.1 that seemed to be tied to doing an update from 5.0.x.  When we fully uninstalled the old client, and then installed the 5.1 client, it seemed to work better.  There are also a few bugs related to connections in 5.1.1 which were addressed in 5.1.3.  (see https://docs.paloaltonetworks.com/globalprotect/5-1/globalprotect-app-release-notes/gp-app-release-information/globalprotect-addressed-issues.html).  I'd try uninstalling 5.1.1 and doing a fresh install of 5.1.3. ... View more

Would it be possible to try a more recent version of the 5.0 client?  5.0.2 is over a year old now, and the preferred release at the moment is 5.0.9 (see https://live.paloaltonetworks.com/t5/customer-resources/support-pan-os-software-release-guidance/ta-p/258304#).  We previously had problems with users not being able to connect on versions earlier than 5.0.5. ... View more

Do you have a separate agent configs for your portal and gateway for each OS, or are you doing one with "any" OS? If separate, does your portal agent config for Windows OS point include include the correct gateway(s) in the External tab? ... View more

Is 192.168.1.20-192.168.1.50 your client pool for GP?  I don't know your topology.  What devices is 192.168.1.1?  The GP interface doesn't have a gateway because of how it works as a tunnel interface.  When you put routes in the split tunnel include section of the gateway config (Network > GlobalProtect > Gateways > Your Gateway > Client Settings > Your Client Config > Split Tunnel), these routes get installed in the Windows route table by GP with the GP adapter as the on-link interface.  Anything in the Exclude section does not get tunneled.  You should be able to verify the routes on a Windows machine by running this command in the command prompt: route print   ... View more

The KB you referenced is over two years old.  I do not see that stipulation about not working w/ the on-demand connection method in the actual documentation for 9.0 nor 8.1, so I can't say for sure.  It's been a couple of years since I worked with on-demand mode, but I was thinking the internal host detection still worked.  I could be wrong though.  I would still suggest opening up the access from your inside zone to your portal as I explained in my first reply, and testing out the internal host detection for yourself that way.   If you simply drop panos-global-protect to the portal, I think you'll still be stuck with the the "portal not found" error, because I don't think the client will be unable to reach it at all.  Since this is an on-demand connection, maybe that's acceptable, since users shouldn't see it unless they try to connect internally. ... View more