Thursday, May 21, 2020

By Charles Buege, Fuel User Group Member

Editor’s Note: This article has been updated with information on how to create a GlobalProtect Portal since its original publication in February 2020.

You’ve just entered the wonderful world of Palo Alto Networks and have found that your users need to be able to access work resources remotely. This means you’ll need to set up VPN access for them. In the parlance of Palo Alto Networks, this means you’ll also need to set up the GlobalProtect VPN client. This article will review how to set up the client for your usage.

Questions and Answers Suggestions

Setting up VPN access isn’t something you can simply jump into. There are a series of questions that you’ll need to consider when performing this action. Here are the questions I use when setting up VPN access:

1. What subnet will the users be using when they connect in with the GlobalProtect VPN client?
   

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

2. What zone will the users be connecting to?
   

   Again, using a dedicated zone for VPN users is best as well. While you could use an already existing zone and subnet, setting up VPN users on their own zone and subnet makes the security of the users much simpler to manage as well as allowing you to be more granular in your security.

3. What zone(s) will the VPN users need access to?
   

   You can never secure an environment unless you know where users will and will not need access to. I’m a fan of the concept of least authority, meaning I’ll only give access to what is absolutely necessary. If they don’t need it now and might need it later, grant it later. Granting more access than is strictly necessary will open you up to security risks that are better left secured.

4. What resources will the VPN users need access to beyond just the zones? Will they need access to the entire zone, a subset of the zone, etc.?
   

   While granting access to a zone is very simple and easy in most cases, sometimes you don’t need the users to have access to the ENTIRE zone. Look at the resources in the zone that you’re granting them access to. If you’re granting them access to the entire servers’ subnet, are there certain servers that you don’t want the users accessing remotely? Are there other resources that the users just don’t need access to from home — printers, etc.? If so, don’t allow access to those resources.

5. What certificate signing authority will the GlobalProtect client’s certificate be signed with? Will an external certificate signing request (CSR) be used, like GoDaddy or NameCheap, or will an internal certificate authority be used?
   

   If you are using your own internal certificate authority, then using that for your GlobalProtect client is an option to save some money instead of getting the certificate signed by an external certificate authority (CA). Of course, this means that any system connecting to the GlobalProtect will need to have that internal CA installed as a certificate authority on your client’s machine ahead of time. Is this the best course of action if the user’s personal system is the one that is going to be connecting in?

6. How many users do you expect to have VPNed in over a given time period? Associated with this question, you’ll want to consider how long they should remain connected (a couple hours or a couple days). Directly associated with that, what duration of DHCP lease do you want to assign to the IP address range as well? Will the users need to keep/be better off keeping the same IP address every time when coming in via VPN (due to internal security constraints on IP address-based internal-only secured systems) or do you WANT the user to get a new IP address every time?
   

   This series of questions ties right into how you should setup your GlobalProtect configuration for your users: number of available IP addresses in the subnet, lease time for the IP addresses, etc.

7. Do you intend to direct all user traffic through the GlobalProtect VPN?
   

   If you are wanting to redirect all of your users’ traffic through the GlobalProtect VPN connection, that’s fine but take these items into consideration. First, all data for the users will be flowing through your internet connection ─ Google searches, personal email, etc. Secondly, the users’ experiences may slow down significantly if all of their internet traffic needs to come back through your central office. Lastly, anything that a user has on their local network at home, like a networked printer, will not be accessible to them. You may have regulatory or business continuity needs to make this happen ─ just be sure to think this through ahead of time so you don’t kill your own connection.

Naming Conventions

In my experience, having some naming conventions identified makes for an easier system to administer.  Here is where I will go into detail of the list of naming conventions I’ve used in the past and the reasoning behind them.

First and foremost, I am a big proponent of self-documentation. I’m not one for naming a security zone “Z1Ex45Pro33.” No, I prefer much simpler zone names like “External,” “Internal,” “Visitors,” etc. If you have a need to go beyond this, feel free, but I’m of the opinion to not make this more difficult for yourself than you have to.

 Next comes the interface names. Two of the most common uses for any firewall are VPN access and IPSec tunnel access. Since VPN access is just a specific implementation of an IPSec tunnel, thinking of them along the same lines is fine, but since they are used for slightly different purposes (a one-to-many connection vs. a many-to-many connection), when naming tunnel interfaces, I tend to use the number of the tunnel as an immediately obvious differentiator of their purposes.

Utilizing a recommendation from the person who first introduced me to Palo Alto Networks technology, my VPN-based tunnels all start with a value of 10, while my non-VPN-based IPSec tunnels all start with a value of 100. This way, as soon as I look at my tunnel interfaces, I see what their different purposes are. Also, I don’t see many situations where a company will have more than 90 GlobalProtect instances (10 -> 99), so using 100 for the starting value of an IPSec tunnel seems fine to me. If you have a case where you might actually need more than 90 tunnel interfaces, then start your IPSec tunnels at 200 instead.

When it comes to assigning an IP address for the gateway on a given subnet, I prefer to use the last available IP address of a subnet. The reason for this is because over the years I’ve had to replace hardware and do some IP address swapping with regards to my hardware being moved around. Instead of trying to use IP addresses at the start of a subnet range and depending on my entire networking team to remember that we need to skip the first X addresses for some reason, I prefer to just use the IP addresses at the end. And since my DHCP range is set to not go to the very end of a subnet, I then have the flexibility to move IP addresses around near the end of that range with much greater ease.

Example

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 in. 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 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 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 10.146.146.0/24.

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, it 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”) we will enter the following subnets:

10.227.24.0/24

10.227.73.0/24

172.20.0.0/16

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 GlobalProtect 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 10.227.73.1 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 -> [Virtual Router 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 GlobalProtect Portal

The Portal is the endpoint that your VPN clients will be connecting to. It is also the point, if you choose to enable it, where you can allow your users to connect in and download the VPN client for themselves. If you are pushing out the VPN client via a Group Policy Object (GPO) or some other method, then you most likely won’t need this, but I’m going to show how to turn this on so you are aware. You can also use a portal to manage the connections for multiple GlobalProtect gateways and direct client communication, but we won’t be addressing this in this article.

Go to Network -> GlobalProtect -> Portals -> Add

In the “General” tab, enter a name for your portal in the “Name” section and specify the interface that you are using. In this example, it is ethernet1/2.

On the bottom half of the screen, this is where you can turn on (or off) the “Portal Login Page.” With this, a user can use their VPN credentials and log into the site to download the GlobalProtect VPN client themselves. Again, this is your choice. In this example, I’m leaving it turned on.

Next click the “Authentication” tab. From here, select the SSL/TLS Service profile you created earlier.  This is what the screen will look like.

Next, we need to setup the Client Authentication process for the portal. Click the “Add” button and then fill in the “Client Authentication” screen. You’ll need to enter a name and then choose the “Authentication Profile” created earlier. Here is what my screen looks like:

That’s all you need to do to get the Portal set up. Now we move onto creating the Security Policy for the VPN users.

Create a Security Policy

With everything else complete 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.

Commit and Connect

If everything went according to plan, you should be able to commit to the firewall and be able to connect with a client.