git clone https://github.com/jeremypageitcompany/Azure_PA_HA.git

1. What is it Link to heading

  • Using Azure components to do high availability with more than one standalone Palo Alto in Azure.
  • Deployment of the infrastructure with Terraform.
  • Testing Inbound traffic with a public load balancer.
  • Testing Outbound traffic with a internal load balancer.
  • Splitting inbound and outbound on different firewalls

2. Why do this Link to heading

The Good

  • Can scale easily by adding more firewall, can have more than 2.
  • Support Inbound traffic with public LB (ex: exposing a web server)
  • Support Oubound traffic with internal LB
  • Using native Azure components to do HA
  • Fast Failover done by the LB health probe
  • Segmentation of inbound/outbound traffic on different set of firewalls
  • Dont need multiple VR

The Bad

  • Need standalone licence for each firewall
  • Need panorama to keep firewall in sync
  • IPsec and GlobalProtect traffic will not work through LB
  • Need to source Nat Inbound traffic
  • require double the number of VM and licence

3. Diagram Link to heading

diagram

  • 4 Palo Alto VM
  • 3 nics per VM (mgmt, untrust, trust)
  • Public Ips for each mgmt interfaces and also for the public LB
  • Public Ips for the untrust NIC of the Palo handling Outbound traffic
  • internal LB in the trust subnet
  • Subnet for Servers, with a UDR pointing to the frontend IP of the internal LB

4. Lab Link to heading

4.1 Terraform Code Link to heading

git clone the project, go into folder PA_Active-Passive

git clone https://github.com/jeremypageitcompany/Azure_PA_HA.git
cd PA_Dedicated_Inbound

some of the variable values you might want to change are in the terraform.tfvars file
terraform_1

  • Project and Env are use in every resource name.
  • Location to deploy the resources and its resource group.
  • SKU for public IP
  • Palo Alto VM size
  • Palo Alto SKU, could be byol or licensed (bundle1, bundle2)
  • Palo Alto version
Note
By default, TF will take the public IP of the deploying machine and input it into a NSG on the management and untrust interfaces.
Warning
variable vm_password and vm_username are used for the palo altos and the linux VM. They are configured as sensitive variable that will not show in the PLAN but they will show in the state in cleartext.

4.2 Terraform deployment Link to heading

  • Now do a terraform init to download plugin and init directory
  • Then, do a terraform plan to see what will be deploy in Azure
  • terraform apply to push configuration to Azure. TF will ask to enter your username and password that will be set for the PAs and Linux server.

terraform_2

After 5-10 minutes, deployment will be completed.
TF will output the public ips associated with your management interfaces

In you Azure portal, you should now see a new resource group with all associated resources for this project.
terraform_3

4.3 Palo L3 Link to heading

Note
This scenario works best with a Panorama managing the firewall. If you dont have one and still want to test this, you will have to replicate configuration on each firewall.

Interface Mgmt
The interface mgmt is important in this scenario. This will allow health probe on both load balancer to check if the firewall is alive. The protocol use here need to match your load balancer rule. In this example, SSH (TCP22) was used.

You can also restrict it further by enabling only the IP of the load balancer.

palo_l3_1

Interfaces

  • ethernet1/1: is going to be used for Untrust

    • Mgmt profile: Health Probe(Only on PA 1-2)
    • Zone: UNTRUST
    • IP: Dynamic, uncheck: Automatically create default route

  • ethernet 1/2: is going to be used for Trust

    • Mgmt profile: Health Probe(Only on PA 3-4)
    • Zone: TRUST
    • IP: Dynamic, uncheck: Automatically create default route

Palo1-2
palo_l3_2

Palo3-4
palo_l3_3

Note
Uncheck Automatically create default route pointing to default gateway provided by server. We will configure static route manually.

Routes

All 4 palos will have these 2 routes.

  • Name: default
  • Dest: 0.0.0.0/0
  • Int: e1/1
  • Next Hop: IP - 10.0.1.1

palo_l3_4

  • Name: inside
  • dest: 10.0.0.0/8
  • Int: e1/2
  • Next Hop: IP - 10.0.2.1

palo_l3_5

Only PA 3-4 will have this additional route for the health probe.

  • name: healthprobe
  • dest: 168.63.129.16/32
  • Int: e1/2
  • Next Hop: IP - 10.0.2.1

palo_l3_6

4.4 Inbound Link to heading

In this section, we will make the necessary configuration to allow a resource on the internet to reach an internal resource in Azure that is protected by the firewall.
Inbound traffic is being processed by PA 1 and 2.

4.4.1 Public LB Link to heading

Inbound traffic will be control by a public load balancer that is configured in Azure.

The Frontend ip will be a public IP. This is the public IP that resources on the internet will reach to access internal resources in Azure.
public_lb_1

The backend pool will be composed of the 2 Untrust NIC of each of the Palo Altos.
Once a request reach the frontend ip, the load balancer will send it to one of the member of the backend pool.

Note
By default, it will use a five-tuple algorithm https://learn.microsoft.com/en-us/azure/load-balancer/concepts

public_lb_2

A healh probe will be configure to check if member in the backendpool are alive and responding.

public_lb_3

Load balancing rule will define how the traffic is going to behave when hitting the load balancer.

  • Frontend IP to use
  • Backend pool to use
  • Protocol and port to match
  • Health probe to use
  • Floating IP
  • Source NAT
Warning
Floating IP: if enable, the traffic will not be DNAT to the IP of the instance in the backend pool. Generally recommended to be enable for a public LB. This will have an impact on how NAT/Security policy will be configure. It will also impact the destination of the logs that will be shown in the Palo Alto for Inbound traffic.
Warning
Source NAT. This define how to source NAT outbound traffic originating from the backend instances (untrust NIC of the Palo). By using the default option, it will source NAT on the frontend Public IP. You could also use Outbound rules to define how to source NAT the traffic.

public_lb_4

4.4.2 Palo Config Link to heading

NAT Policies

  • Name: dnat
  • Src/Dst zone: UNTRUST
  • Dest Addr: the ip address of your pip on your public lb frontend
  • Service: TCP8000
  • Source Translation: Dynamic ip and port - ethernet1/2
  • Destination Translation: 10.0.100.4:8000

Note
Since we configured a floating IP on the public LB. Azure will not dnat the traffic before it reach the palo. This means that the destination will be the public IP.
Note
We also need to source NAT traffic so that return traffic exiting the server will go back to the same Palo Alto that allow the request.

public_lb_5

Security Policies

  • Name: inbound
  • Src Zone: UNTRUST
  • Dst Zone: TRUST
  • Dst addr: the ip address of your pip on your public lb frontend
  • Service: TCP443

public_lb_6

4.4.3 Test inbound Link to heading

To test inbound:

  • Connect SSH to palo mgmt
  • jump to linux device in SSH
  • start a python web server on port TCP8000
  • Test the website

Connect in SSH to Palo mgmt and do the following ssh host 10.0.100.4 now you should be on the linux VM.

Start the webserver: sudo python3 -m http.server

public_lb_7

Access the public ip of frontend public lb from your browser on port 8000.

public_lb_8

Validate the Palo Alto log.

  • Destination IP is the public IP
  • DNAT is working
  • SNAT is working

public_lb_9

4.4.4 Test inbound failover Link to heading

First, identify which firewall is passing the traffic right now.
Then we will modify the mgmt profile on this firewall to block the health probe and force the load balancer to only send it to the other firewall.

modify the IP to something different.

public_lb_10

To check, go into the public lb resource - Monitoring-Insight-AdvancedMetrics

public_lb_11

As you can see, health probe failed for one firewall and the lb is forcing traffic on the other one. Retest your website and you will see that its working.

4.5 Outbound Link to heading

In this section, we will make the necessary configuration to allow a resource in the server subnet to reach the Internet.

Outbound traffic is controlled by PA 3-4

4.5.1 Internal LB Link to heading

Outbound traffic will be control by an internal load balancer that is configured in Azure.

The Frontend ip will be a private IP in the Trust subnet. This is the IP that resources in the server server will point to to get to Internet or for lateral traffic.
internal_lb_1

The backend pool will be composed of the 2 Trust NIC of each of the Palo Altos.
Once a request reach the frontend ip, the load balancer will send it to one of the member of the backend pool.

Note
By default, it will use a five-tuple algorithm https://learn.microsoft.com/en-us/azure/load-balancer/concepts
internal_lb_2

A healh probe will be configure to check if member in the backendpool are alive and responding.
internal_lb_3

Load balancing rule will define how the traffic is going to behave when hitting the load balancer.

  • Frontend IP to use
  • Backend pool to use
  • Protocol and port to match. HA ports = all Protocol
  • Health probe to use
  • Floating IP: Disabled

internal_lb_4

4.5.2 Palo config Link to heading

NAT Policies

  • Name: snat
  • Src zone: TRUST
  • Dst zone: UNTRUST
  • Dest Addr: any
  • Service: any
  • Source Translation: Dynamic ip and port - ethernet1/1

internal_lb_5

Security Policies

  • Name: Outbound
  • Src zone: TRUST
  • Dst zone: UNTRUST
  • Dest Addr: any
  • Service: any

internal_lb_6

4.5.3 Test Outbound Link to heading

To test outbound:

  • Connect SSH to palo mgmt
  • jump to linux device in SSH
  • validate public ip used for internet services

Connect in SSH to Palo mgmt and do the following ssh host 10.0.100.4 now you should be on the linux VM.

Do the following command curl icanhazip.com

internal_lb_7

Validate the Palo Alto traffic logs.

internal_lb_8

We can see its using the frontend public IP of the public LB because this is using the default behavior when outbound LB rules are not configured.