Skip to content

Palo Alto Netoworks GlobalProtect capabilities

Generally, Palo Alto Networks’ next-generation firewalls are quite flexible and granular devices. You can do a lot in terms of security to reduce the attack surface, and more. They lack some advanced networking features, but in my opinion, this is understandable since they were designed as security devices, not networking devices.

GlobalProtect is a remote access solution provided by Palo Alto Networks’ firewalls. I don’t want to elaborate on how to configure it; the configuration can be really simple but also much more advanced. I just want to show how flexible and granular this solution is based on my experience from deployments and customer support.

Pre-logon

I elaborated on Pre-logon a little bit here: https://letsnet.eu/globalprotect-pre-logon/. Basically, for Pre-logon purposes, we need a machine certificate to authenticate to the portal/gateway before login. If the certificate is not present in the client’s certificate store for some reason, it won’t be able to authenticate and connect to GlobalProtect at all. A machine certificate signed by CA PreLogon_CA must be present.

Recently, I faced some challenges. During a Pre-logon deployment, I found out that certificate distribution was not working correctly. Some devices missed machine certificates and, as a result, were unable to connect to GlobalProtect after the Pre-logon deployment. Again, Palo Alto Networks’ devices are really granular. You can configure different endpoint settings based on selection criteria such as user/user group, client OS, certificate checks, and custom checks—you can even check for some registry keys and, based on that, deliver different configurations. I solved my problem quite easily using Device Checks. If a machine certificate signed by PreLogon_CA is present, deliver the endpoint configuration to connect to the gateway with Pre-logon enabled. If not, connect to the gateway without Pre-logon and certificate authentication.

To identify if a certificate is present, the configuration step below is mandatory (unfortunately not well-documented).

MTU issue

The second issue I faced recently was about connectivity. I help maintain a GlobalProtect distributed infrastructure for a couple of thousand users. A Customer reported that some users sometimes have connectivity issues. Sometimes they cannot connect to internal resources, sometimes to the internet, and sometimes connectivity is working but really slow. Everything happened randomly — “the simplest” kind of issue to resolve. I had to wait until I could check the problem in live. Unfortunately, it took about three months because of the randomness and my availability. When I had the opportunity to check it in live, the issue was really simple — an MTU mismatch. In a couple of places across Europe, smaller ISPs had smaller MTUs than the default one, so the solution was just to lower the MTU to the desired value. With GlobalProtect, it is just a simple click.

As you can see above, there are a lot of GlobalProtect client settings. You can configure how the app will behave, what the user will see, and much more, there are a lot of options.

Generally, I like solutions that are flexible and granular. At first glance, they usually look complicated and maybe even overwhelming with so many options, but when you face some issues or have specific needs, flexibility and granularity matter.

Join the conversation

Your email address will not be published. Required fields are marked *