3 months in Palo Alto (Part 1)

I know that this site has been quiet for some time, so I really should put some effort into it. I am still trying to get the desire to study for my CCIE security back, which at the moment, is sorely lacking. I have also been doing the CCNA CyberOps, and have a little time left to complete that. Not sure that I will actually sit the exams or not, I don’t really feel the need to. I have not bee slacking though, I have just ben focussed elsewhere. Over the last few months, I have been playing around with Palo Alto devices. First, setting up a VM-300 in AWS, and now moving onto their GlobalProtect Cloud solution. This post is about my adventures with Palo Alto.

Why Palo Alto?

Traditionally, I have always been a Cisco guy. However the decision to go with one vendor or another is not always up to me, so evaluate other options we must. Hence testing Palo Alto’s options for a new VPN solution. The main driver is the Layer 7 abilities that it offers.

Test one: Palo Alto in AWS

AWS offers the Palo Alto VM-300 as either a BYOL (Bring Your Own License) or one where you use a license offered by AWS, and this comes in two bundles. Bundle 2 is the good one as it includes GlobalProtect (the VPN stuff). It will cost about $4500 a year (this is the licensing part) as well as the EC2 instance charges, which is per hour, and then there are the traffic costs on top of that.

To get any use out of the appliance, you will need two subnets, both with elastic IPs. Fire up an instance with two interfaces, connecting the subnets. The reason for the two interfaces is that one is for management, the other is for data (where your users will connect to the VPN and where your IPSec VPNs will connect).

Once you have this setup and the instance is running, you can access the management interface. It is a good idea to implement a security group to the management interface, limiting SSH and HTTPS access to the IP addresses you will be using to manage it.

A change of perspective

Going from Cisco ASAs to Palo Alto involves a bit of a change in how you view the whole idea of firewalls and ACLs. In a nutshell, they are very similar, both work on the premise of zones. With the ASA this is a bit more transparent – we have interfaces that are effectively the different zones (outside, inside, DMZ and so on). We assign ACLs based on these interfaces. With the ASDM GUI, we can see the ACLs applied to the different interfaces. The first interface will be the management interface, the second one will be the data interface.

With the Palo Alto, however, we have a more unified approach, and this is similar to CheckPoint firewalls if you have ever used those. All our ACLs (called Policies in the Palo Alto vernacular) are presented as one, with the source or destination zone being the decider.

Palo Alto to ASA IPSec VPN

OK, so let’s look at something a little more concrete. The first step I needed was to create an IPSec tunnel between the appliance and the HQ’s ASA.

Create Virtual Router (Network > Virtual Routers), this will handle our routing. You can probably just use the “Default” one that is created by default, but I prefer to create one (actually called “VR1”, not “VR” as the screenshot shows).

Go to the Zones menu, and create a zone called Internal-Zone. Assign the ethernet interface for the data traffic (ethernet1/1) to this zone and to VR1.

Next, create a loopback address (Network > Interfaces > Loopback), this can be on the same subnet as the internal management IP address (which by default is assigned via AWS DHCP. The reason for this will become apparent later on. Assign this to the Internal-Zone and VR1 created earlier. Now the zone should look like this:

The IPSec tunnel needs a few different components to work, and you can create these in a different order to how I am doing it here.

Create a new zone for your HQ. Leave it as a layer 3 interface and enable the user identification.

Create a new tunnel interface assigning to the virtual router and HQ zone:

Head back to the VR1 virtual router settings. We need to add some routes. Firstly a static route to 0.0.0.0/0 to go via the AWS gateway (by default this is a .1 address in the /245 DHCP range, so if your DHCP assigned address is 10.16.1.10, the next hop would be 10.16.1.1). Secondly, add a static route to go through the new tunnel to your HQ network:

So now that we have told the firewall how to get to our HQ (via the tunnel interface), let’s create the IPSec connection.

Go to Network > Network Profiles > IKE Gateways and click on Add. Fill in the details, selecting the data interface (and putting in the IP address of your HQ’s firewall):

Now go to Network > IPSec Tunnels and click on Add.

Name the new connection and select the tunnel interface created earlier, and the IKE Gateway created a moment ago:

Click on the Proxy IDs tab and enter the local and remote subnets that will form our interesting traffic.

That’s as far as this side goes. I am not going to include the ASA VPN set up (for the sake of brevity), but you should be able to ping the loopback interface created earlier from your HQ.

Palo Alto services and loopbacks

The reason we have a loopback interface is that by default, management traffic will be sourced from the management interface, this includes core services such as Syslog, SNMP, LDAP and so on. So if you want to run any form of LDAP authentication over your IPSec tunnel, you need to switch the interfaces.

Head to Device > Setup > Services > Service Route Configuration and switch the option from Use Management Interface for All, to Customize. Set the services you need over the IPSec tunnel to use the loopback interface:

Palo Alto policies

We need a policy to permit traffic between the HQ and Palo Alto.

Head to Policies > Security and click on Add. The fields we must complete are identified by a red squiggly line underneath the heading. Firstly, name the policy: