Palo Alto VPN (GlobalProtect)
Part 4 – Gateways

Intro

The Gateway is pretty much exactly as it is named, the gateway where you get a virtual connection to tunnel into the network.

Requirements:

1)  And Interface with a Public IP address.
2) Certificates (Covered in Part 2)
3) Authentication Profile (Covered in Part 1)

Configuration

On the Palo Alto Firewall go to Network -> GlobalProtect -> Gateway

Under General give it a Name and define the interface in which has your Public IP address. *Note* The IP address can be left as none, this will work fine if your interface gets its IP address via DHCP, if you have static the static IP address should be populated from the drop down and can be selected. The Appearance section allows you to alter the web login portal that can be used to download the GlobalProtect client software.

Under Authentication Select a SSL/TLS Profile which contains the certificate which will secure this portal)

Then click add under Client Authentication and add the Auth Profile which states which users are going to be allowed to authenticate through this portal. Then select a Certificate Profile. (Covered in Part 2)

This is the first section that actually looks different than the portal configurations, under the Agent section the first area is the tunnel settings. This is where you define which tunnel interface (i picked the default, you may need to create additional tunnel interfaces if doing multiple portal/gateway configurations). In my case I was setting up tunnel based IPsec type VPN.

I left all the Timeout Settings as default, then moved onto client settings. Here we define any particular users, what OS they are allowed, and what IP addresses they are to be assigned (basically acts as a dedicated DHCP for the virtual tunnel interface when the VPN is established).

 

Next, under Network Services define the internal DNS server and WINS servers, as well as the DNS suffix users who connect will use, this will allow them to work as if they were locally at work.

In my case I didn’t have to deal with HIP Notifications or the Satellites section. 😀

That’s it for the Gateway, this unfortunately is not enough and we still need to define our Security Rules. Luckily since the Portal utilizes a public facing interfaces, we don’t have to deal with any NAT rules as connections are routed through the virtual tunnels that get created pretty much through the settings we defined in this part. 😀

As you can tell these post are a lot shorter as the hardest parts is building the pre-requisites.

Till Part 5, Cheers!

Leave a Reply

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