Tue. Oct 4th, 2022

How do I set up GlobalProtect VPN Client

You are just starting to use Palo Alto Networks technology and discover that your users need remote access to work resources. This means that you will need VPN access and, in Palo Alto Networks parlance, you will also need to set up the GlobalProtect VPN client. This article reviews how to set up the client for your use.

Q&a advice

Setting up VPN access is not something you can simply jump into. When you do this, you need to consider a number of issues. Here are the questions I use when setting up VPN access:

  1. Which subnet does the user use to connect to the VPN client?

In my experience, I’ve found it easiest to use a dedicated subnet for your users when setting up VPN access. Trying to use a subnet configured in an existing zone is problematic at best.

  1. Which area is the user connected to?

Also, it is best to use dedicated areas for VPN users as well. While you can use existing zones and subnets, setting up VPN users in their own zones and subnets makes users’ security more manageable and allows you to fine-tune your security.

  1. What areas do VPN users need to access?

You can never secure your environment unless you know where users need to access and where they don’t. I’m a big fan of the concept of minimum permissions, which means I only provide access that is absolutely necessary. If they don’t need it now and may need it later, grant it later. Granting more access than is strictly necessary exposes you to better security risks.

  1. What resources outside the VPN area do VPN users need to access? Do they need to access the entire region, subsets of the region, and so on?

While granting access to a zone is simple and easy in most cases, sometimes you don’t need users to have access to the entire zone. Look at the resources in the area that you granted them access to. If you grant them access to an entire subnet of servers, are there some servers that don’t want users to access remotely? Are there other resources that users don’t need to access at home — printers, etc.? If so, access to these resources is not allowed.

  1. With which certificate signing authority will the GlobalProtect client’s certificate be signed? Will you use an external CSR, such as GoDaddy or NameCheap, or an internal certificate authority?

If you use your own internal certificate authority, using it for your GlobalProtect client is an option to save some money instead of having certificates signed by an external CA. Of course, this means that any system connected to GlobalProtect will need to install the internal CA as a certificate authority on your client computer in advance. Is this the best course of action if the user’s personal system is the system to connect to?

  1. How many users do you expect to use VPN in a given period of time? Related to this issue, you need to consider how long they should remain connected (a few hours or a few days). Directly related to this, how long do you still want to assign DHCP leases for IP address ranges? Does the user need to keep/preferably keep the same IP address each time they enter through the VPN (due to internal security limitations of IP address-based internal security systems only) or do you want the user to get a new IP address each time?

This series of questions relates to how you should set up the GlobalProtect configuration for your users: the number of IP addresses available in the subnet, the rental time of IP addresses, and so on.

Naming conventions

In my experience, identifying some naming conventions makes the system more manageable. Here, I’ll detail a list of naming conventions I’ve used in the past and the reasons behind them.

First of all, I’m a big supporter of self-recording. I don’t like to name the security zone “Z1Ex45Pro33”. No, I prefer simpler zone names such as “external”, “Internal”, “visitor”, etc. If you need to go beyond these, feel free to do so, but I don’t think you should make this more difficult for yourself than you have to.

Next comes the interface name. The two most common uses of any firewall are VPN access and IPSec tunnel access. Since VPN access is just a specific implementation of IPSec tunnels, it is ok to think of them in the same vein, but since they are used for slightly different purposes (one-to-many versus many-to-many connections), I prefer to use the tunnel number as a clear distinction between their uses when naming tunnel interfaces.

Using tWorks technology recommended by the person who first introduced me to Palo Alto, my VPN-based tunnels all start with 10, and my non-VPN-based IPSec tunnels all start with 100. That way, as soon as I look at my tunnel interface, I see that their purpose is different. In addition, I don’t see many situations where companies will have more than 90 instances of GlobalProtect (10 – >; 99), so using 100 as the starting value for IPSec tunnels seems fine to me. If you might actually need more than 90 tunnel interfaces, start your IPSec tunnel at 200 instead.

When assigning IP addresses to gateways on the stator network, I prefer to use the last available IP address of the subnet. The reason for this is because over the years I have had to replace hardware and do some IP address swapping when my hardware is moved. Instead of trying to use IP addresses at the beginning of the subnet range and relying on my entire network team to remember that we need to skip the first X addresses, FOR some reason I prefer to just use the last IP address. And because my DHCP range is set not to reach the very end of the subnet, I can more easily and flexibly move IP addresses near the end of that range.


For this document, the following system configuration/lab environment will be used:

Here’s a little more detail on what I am referring to on each of these zones:

  • Internal: This is where our normal users will live — internal to the network, day-to-day, in-the-office workers.
  • External: This is the external interface for outgoing traffic. This isn’t the real IP address I used — this is just for the purpose of documentation.
  • Servers: The servers on the user’s network. They are in their own zone for the added protection that a segregated zone will allow them.
  • DMZ: This is the portion of the network where there will be servers that are immediately available to the outside world. Again, by giving them their own zone, it’s easier for us to be more granular in the assignment of access at the security zone level.
  • Visitors: This is the segment of the network where anyone can connect. This includes a user’s personal devices, any actual visitors to the company, etc. This connection will just get them an IP address and internet access but no actual access to the internal network resources.
  • Hardware Management: This is the zone where the actual management interface for the Palo Alto Networks appliance resides. This allows me the ability to grant remote access to the management interface, if I so desire, allowing for remote work on the device.
  • VPN-Users1: This is the zone where the actual VPN users will connect in. Due to how I am setting up the GlobalProtect client, there is no gateway IP address necessary, meaning I can keep that blank.

Now it’s time to start setting up GlobalProtect.

Create the zone

To create the tunnel zone, click on Network -> Zones -> Add.

Enter the Name of the zone.  I’m using “VPN-Users1” for my name.

Set the ”Type” to ”Layer 3.”

Click “OK” when complete.

Create the interface

To create the tunnel interface, click on Network -> Interfaces -> Tunnel -> Add.

For your “Interface Name,” enter a value of “10.”

Set your virtual router to the one you will be using.

Set the security zone to the one you created in the previous step. For this article, it is “VPN-Users1.”

Click “Ok” when complete.

Create the certificate entries

If you are using an internal certificate authority, you’ll need to follow one of these two paths:

  1. Set up the internal certificate authority that is going to be used. Import the key along with the certificate if it is available.
  2. Set up the certificate that the GlobalProtect client will use when connected to the server. If the key was imported with the internal CA, then the fully generated certificate will be immediately available. Otherwise, you’ll need to export the CSR, take it to the CA to sign it and then import it back in with the EXACT same name so the CSR and the certificate are paired correctly.

Here are the steps for setting up the certificate to use in conjunction with GlobalProtect:

To set up the certificate, go to Devices -> Certificate Management -> Certificates.

Select the certificate authority you are going to use.

Click “Generate” and fill out the form. Be sure to select your own CA in the “Signed By” option.

If you are using an external certificate authority (GoDaddy, NameCheap, etc.):

  1. Generate the CSR of the certificate.
  2. Import the intermediate certificate into the device.
  3. Import the certificate from the certificate authority.

Create SSL/TLS Service Profile

To create the profile, go to Device -> Certificate Management -> SSL/TLS Service Profile -> Add.

Enter a valid, easy-to-remember name and then choose the certificate you created a few moments ago.  Click “OK.”

Create Authentication Profile

This is what you will be using to verify the user connecting in is authorized to connect. I will be using a local user on the PA-220, but Active Directory/LDAP is an option and a more involved demo. This can be done another time.

Device -> Authentication Profile -> Click “Add.”

Enter a name and then I choose a “Type” of “Local Database.”

Under the “Advanced” tab, choose the users you want to allow. Alternatively, you can choose “All” from the list as well, to allow all users from the local database to be granted VPN access.

Create GlobalProtect gateway

Network -> GlobalProtect -> Gateways -> Click “Add.”

Now we will create the GlobalProtect gateway. On the initial page, enter a name for the gateway and then choose the interface that you’re working with.

Click on the “Authentication” tab.

Choose the SSL/TLS service profile you created earlier.

After that, click “Add” under “Client Authentication.”

Enter a name for the client authentication profile you are creating for the gateway and choose the authentication profile that you will be using.

Once you finish filling out the client authentication information, your “Authentication” tab should look like this:

Set up the firewall for the GlobalProtect

Now it’s time to set the firewall up for the GlobalProtect to use the correct interface that we created earlier.

Click on the “Agent” tab.

Under the “Tunnel Settings” tab, enable “Tunnel Mode” by checking the box, then select “tunnel.10” from the “Tunnel Interface” dropdown list.

Next click on the “Client Settings” tab and click “Add.”

On the “Config Selection Criteria” tab, enter a name for the criteria you are creating.

After that, by the “Source User” box, choose “Select” above it. Inside of it, click “Add” and add all of the users who are going to be applied to this criteria.

Next click on the “IP Pools” tab. Here is where you specify what IP address range will be assigned to the VPN users that connect. Be sure to choose a subnet that isn’t in use on your network or you could become VERY confused. In our example, we are going to use

Next click on the “Split Tunnel” option. I don’t want to prevent my users from being able to access resources on their local network. From a security perspective, you may want to NOT allow this and that’s why you’d check the “No direct access to local network” option. The only thing to keep in mind is if you DO check this box, and these are the two things I’ve come across the most that make it difficult for my remote users, this means all internet traffic for the user will be traversing the tunnel and the user won’t have access to anything on their local network — like a wireless printer. I just mention those so you are aware of them.

In my case, I don’t want my VPN users to access anything other than the subnets in the zones internal servers and DMZ. To this end, in the “Include” section (where it says, “Enter subnets that clients need to access” — VERY easy to understand!), we will enter the following subnets:

Be sure that your security policies reflect these subnets or else you won’t be able to access these resources.

When you’re done, click “OK” to go back to the “Client Settings” tab. Here is the completed client settings tab.

Back on the gateway configuration screen, click on “Network Services.” Here is where you specify any internal DNS servers or other resources you’d like the user to use while they are connected with the VPN. I’ve got a DNS server setup, but only one, so I’ll set the primary DNS to and I’ll also set the DNS suffix to my domain name to match the domain that they’re connecting to.

At this point, the gateway configuration is complete. Click “OK” now.

Add a Static Route for VPN Subnet

Lastly, we need to set a static route for the VPN subnet. Otherwise, traffic trying to return to VPN users won’t know where to go, since the VPN zone doesn’t have an endpoint to route traffic like the other zones do. Follow these steps:

Network -> Virtual Routers -> [Router selected for your tunnel] -> Static Routes -> Click “Add.”

Assign a name and then set the destination for the subnet for your VPN clients. Set the tunnel interface to the VPN zone’s interface, “tunnel.10,” and set the “Next Hop” to “None.”

Here is the static route screen filtered for the VPN line we just added.

Create a Security Policy

With everything else completed to this point, you’ll then need to create a Security Policy to then allow the Zones to speak to each other. With this, you can get as complex or as simple as you want.  You can set each individual non-VPN Zone to each other zone on a one-to-one basis even separating them from incoming and outgoing traffic or you can make it so that all zones you want to interconnect with each other are in a single rule. I prefer the first option and go as granular in the security as possible.

Go to Policies -> Security -> Add

In the “General” tab, enter the information as follows:

Click on the “Source” tab. Enter the information as follows:

Click on the “Destination” tab. Enter the information as follows:

Don’t forget to look at the “Service/URL Category” tab. By default, the “Service” section is set to “application-default”. This means that in the event that you have an internal web server running on a non-standard port like 12345, you would be unable to connect to it. Change this as necessary.

Also, be sure to look at the “Actions” tab as well to decide if you want to/need to apply any profiles to the rule that you’ve just created.

Lastly, in my example here, I’ll then need to go ahead and define a second rule, Internal to VPN – Outgoing, that will allow the return traffic to the VPN users. Without this, the remote users won’t be able to do anything.

By admin

Leave a Reply

Your email address will not be published.