Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
Episode Transcript:
Hello PANCasters. GlobalProtect is the Palo Alto Networks remote access VPN solution and it covers both VPN to on-prem firewalls configured as gateways and also for mobile user connectivity with Prisma Access VPN. Today we are going to go through how GlobalProtect connectivity works and some tips for troubleshooting. Before we get into this, there is one caveat: The configuration for GlobalProtect has a lot — and I mean a lot — of different options for you to customize the user experience. We would not have time in a normal episode to cover all this, so just letting you know we will only cover some specifics today — specifically, the connections it uses and some troubleshooting tips on those connections. We have already covered Split Tunneling in episode two and I’m sure there will be more episodes on GlobalProtect to come in the future.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
Let’s start by looking at the connections. In the GlobalProtect world, we have two types of devices that the client will connect to: The portal and the gateway. The portal is a starting point for any connection. Once you login to the portal, it provides the client with all the required config. Most importantly are what gateways to connect to and what specific application settings to use. You can also have multiple configs so clients can receive different configs based on user, or group, or even device OS. So this portal connection is like the management for the VPN. You connect to get config but you don’t actually build a VPN tunnel to the portal. Once you have successfully connected to the portal and have the config, the client then connects to a gateway. A quick note on gateway selection: When you have multiple gateways, there is a gateway selection process that looks at priorities which are configurable, and response times from the client to the gateways in the list. This process results in the best available gateway being selected as the one the client will connect to.
I want to quickly touch on some key things about these connections to the portal and gateways. Firstly is the types of connections used. GlobalProtect allows you to configure either SSL as the connection protocol, or IPSec with fallback to SSL. This means it tries IPSec and if it fails to connect, it will use SSL. This is specifically for the tunnel to the gateway, meaning if you allow IPSec, it is only the actual gateway tunnel that uses IPSec, the other connections such as the portal connection and even logging into the gateway still uses SSL. Just some background on having the IPSec option. IPSec generally gives better throughput for VPN traffic so you can enable this if performance is key and SSL will generally be allowed in most environments which is why it is also the default option. As an example, maybe your ISP is blocking IPSec traffic but SSL should be allowed.
The second thing is actually to do with authentication and I know this episode is really about connections but I think this info is important in the context. As we now know, the client is going to connect, and therefore authenticate to the portal and then shortly after will also connect and authenticate to the gateway. Having double auth is not ideal for user experience. That is why we can configure cookies. The cookie configuration is available on both the portal and gateway with settings you can adjust on each to suit your requirements but the most common is that if you successfully authenticate to the portal, it can generate a cookie and the gateway can be configured to accept this cookie. This means the user just logs in once but can successfully authenticate to the portal and then the gateway uses the cookie to authenticate the user. Cookie lifetime can also be set and this can be important in how your cookies are configured.
OK, that covers the connections. Let’s have a look at what to do when it doesn’t work. If you listened to previous episodes you’ll know I am a firm believer in the top down approach to troubleshooting. This means if the client is not really telling you why it can’t connect, start with the high level logs. With GlobalProtect there are two places that logs are captured. On the actual client and then on the portal and gateways. Let’s start with the portal and gateway logs. For on-prem this means logging on to your Panorama, or the actual firewall and checking the GlobalProtect logs. For Prisma Access you can do the same but you may need to check the explore app for Cortex Data Lake. So what do you see? Any errors? Are you seeing the logs for that client username or IP? Remember you now know there should be a connection to the portal and then a connection to a gateway, including the steps in between like getting the config from the portal.
Now what if there is nothing obvious in the portal and gateway logs or worse still, no logs at all? Or you see an error but it really doesn’t help find the cause of the issue? Well, this is where we can look at the logs on the endpoint. But a warning first: This really is for the techies out there. The GlobalProtect client on the endpoint collects a lot of logs, and you can download these logs to review them.
There really is some detailed information in the logs, and as I said, a lot of logs so I would probably not recommend looking at these logs unless you have a very specific timestamp of when the issue happened. With the logs collected on the client there are multiple individual logs in the zip file. The main one to look at is the pan_gp_event log which is a high level events log and the best place to start. The two other common detailed ones then to review are the PanGPS.log and PanGPA.log. These relate to the GP Service which will have detailed logs on the GP service and then the GP agent which is the actual agent that a user would interact with. To be honest in most cases it would be best to just give them to TAC if required and they can then review them but if you are someone that likes to dig deep then you can have a look at these logs specifically.
Just a final comment on troubleshooting but this is for our SASE solutions Prisma Access and Prisma SD-WAN. We now have a feature called Autonomous Digital Experience Management, ADEM for short and I discussed this in the last episode in case you missed it. This can provide end to end visibility of the user experience, checking network paths and even specific application response times so it’s also really helpful in troubleshooting GlobalProtect.
One last thing before I go. Not specifically with connections and troubleshooting but I think it is an important takeaway for GlobalProtect and troubleshooting in general. And it sort of ties in with the discussion. So remember we connect to the portal to get the config and then to the gateway. What would be normal is that we connect to the portal at the start of the day and then to the gateway so we can work but potentially we don’t connect again to the portal for some time. So what happens if you make a change to the configuration on the portal? Well, it does not get pushed to all clients as soon as you make the change as it is reliant on clients connecting to the portal again and refreshing the config. Importantly, there is a setting for config refresh which by default is 24 hours. You can change this refresh timer and you can also manually refresh a connection on the client but the key thing here is that when you update config on the portal, it may not be instant on the client.
So there we have it, a brief discussion on GlobalProtect. I know I keep harping on about the fact this only really scratches the surface of GlobalProtect but I hope it has been useful anyway.
I’m just going to give you the key phrases as a reminder.
I want to end this by saying that I've been working with GlobalProtect a long time and troubleshooting can sometimes be really tricky. Hopefully having a bit more of an understanding of the connections and where to look if it doesn’t work may just mean if you do have issues in the future, you may be able to find the cause a bit quicker.
Remember to head to live.paloaltonetworks.com for the transcript and links to related articles and looking forward to getting the next episode out for you all to listen to.
Bye for now.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
