Deploying Palo Alto VM-Series on Azure

60 Replies

Here is a recap of some of the reflections I have with deploying Palo Alto's VM-Series Virtual Appliance on Azure. This is more of a reflection of the steps I took rather than a guide, but you can use the information below as you see fit.  At a high level, you will need to deploy the device on Azure and then configure the internal "guts" of the Palo Alto to allow it to route traffic properly on your Virtual Network (VNet) in Azure.  The steps outlined should work for both the 8.0 and 8.1 versions of the Palo Alto VM-Series appliance.

Please note, this tutorial also assumes you are looking to deploy a scale-out architecture.  This can help ensure a single instance doesn't get overwhelmed with the amount of bandwidth you are trying to push through it.  If you are looking for a single instance, you can still follow along.

Deploy the Appliance in Azure

In deploying the Virtual Palo Altos, the documentation recommends to create them via the Azure Marketplace (which can be found here: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=Overview).  Personally, I'm not a big fan of deploying the appliance this way as I don't have as much control over naming conventions, don't have the ability to deploy more than one appliance for scale, cannot specify my availability set, cannot leverage managed disks, etc.  In addition, I noticed a really strange error that if you specify a password greater than 31 characters, the Palo Alto devices flat out won't deploy on Azure.  In this case, I've written a custom ARM template that leverages managed disks, availability sets, consistent naming nomenclature, proper VM sizing, and most importantly, let you define how many virtual instances you'd like to deploy for scaling.

Note: this article doesn't cover the concept of using Panorama, but that would centrally manage each of the scale-out instances in a "single pane of glass".  Below, we will cover setting up a node manually to get it working.  It is possible to create a base-line configuration file that joins Panorama post-deployment to bootstrap the nodes upon deployment of the ARM template.  The bootstrap file is not something I've incorporated into this template, but the template could easily be modified to do so.

With the above said, this article will cover what Palo Alto considers their Shared design model. Here is an example of what this visually looks like (taken from Palo Alto's Reference Architecture document listed in the notes section at the bottom of this article):

Shared design model as per Palo Alto's Reference Architecture

Microsoft also has a reference architecture document that talks through the deployment of virtual appliances, which can be found here: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha

Below is a link to the ARM template I use.

PaloAlto-HA.json

Deployment of this template can be done by navigating to the Azure Portal (portal.azure.com), select Create a resource, type Template Deployment in the Azure Marketplace, click Create,  select Build your own template in the editor, and paste the code into the editor.

Alternatively, you can click this button here:

Here are some notes on what the parameters mean in the template:

VMsize: Per Palo Alto, the recommend VM sizes should be DS3, DS4, or DS5.  Documentation on this can be found here.

PASku: Here is where you can select to use bring-your-own-license or pay-as-you-go.  Plans are outlined here: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/paloaltonetworks.vmseries-ngfw?tab=PlansAndPrice

PAVersion: The version of PanOS to deploy.

PACount: This defines how many virtual instances you want deployed and placed behind load balancers.

VNetName: The name of your virtual network you have created.

VNetRG: The name of the resource group your virtual network is in.  This may be the same as the Resource Group you are placing the Palos in, but this is a needed configurable option to prevent errors referencing a VNet in a different resource group.

envPrefix: All of the resources that get created (load balancer, virtual machines, public IPs, NICs, etc.) will use this naming nomenclature.

manPrivateIPPrefix, trustPrivateIPPrefix, untrustPrivateIPPrefix: Corresponding subnet address range.  These should be the first 3 octets of the range followed by a period.  For example, 10.5.6. would be a valid value.

manPrivateIPFirst, trustPrivateIPFirst, untrustPrivateIPFirst: The first usable IP address on the subnet specified.  For example, if my subnet is 10.4.255.0/24, I would need to specify 4 as my first usable address.

Username: this is the name of the privileged account that should be used to ssh and login to the PanOS web portal.

Password: Password to the privileged account used to ssh and login to the PanOS web portal.  Must be 31 characters or less due to Pan OS limitation.


Configure the Appliance

Once the virtual appliance has been deployed, we need to configure the Palo Alto device itself to enable connectivity on our Trust/Untrust interfaces.

Activate the licenses on the VM-Series firewall.

Follow these steps if using the BYOL version

  1. Create a Support Account.
  2. Register the VM-Series Firewall
    (with auth code)    .
  3. On the firewall web interface, select Device tab -> Licenses
    and select Activate feature using authentication code.
  4. Enter the capacity auth-code that you registered on the support
    portal. The firewall will connect to the update server (updates.paloaltonetworks.com), and download
    the license and reboot automatically.  If this doesn't work, please continue below to configuring the interfaces of the device.
  5. Log back in to the web interface after reboot and confirm the following on the Dashboard:
    1. A valid serial number displays in Serial#.
      If the term Unknown displays, it means the device is not licensed. To view
      traffic logs on the firewall, you must install a valid capacity license.
    2. The VM Mode displays as Microsoft Azure.

Follow these steps if using the PAYG (Pay as you go) version

  1. Create a Support Account.
  2. Register the Usage-Based Model of
    the VM-Series Firewall in AWS and Azure (no auth code)    .

Configure the Untrust/Trust interfaces

Configure the Untrust interface

  1. Select Network-> Interfaces ->Ethernet-> select the link for ethernet1/1 and configure as follows:
    1. Interface Type: Layer3 (default).
    2. On the Config tab, assign the interface to the Untrust-VR router.
    3. On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new zone called Untrust, and then click OK.
  2. On the IPv4 tab, select DHCP Client if you plan to assign only one IP address on the interface. If you plan to assign more than one IP address select Static and manually enter the primary and secondary IP addresses assigned to the interface on the Azure portal.  The private IP address of the interface can be found by navigating to Virtual Machines -> YOURPALOMACHINE -> Networking and using the Private IP address specified on each tab.
    1. Note: Do not use the Public IP address to the Virtual Machine.  Azure automatically DNATs traffic to your private address so you will need to use the Private IP Address for your UnTrust interface.
  3. Clear the Automatically create default route to default gateway provided by server check box.
    1. Note: Disabling this option ensures that traffic handled by this interface does not flow directly to the default gateway in the VNet.
  4. Click OK

Note: For the untrust interface, within your Azure environment ensure you have a NSG associated to the untrust subnet or individual firewall interfaces as the template doesn't deploy this for you (I could add this in, but if you already had an NSG I don't want to overwrite it). As per Azure Load Balancer's documentation, you will need an NSG associated to the NICs or subnet to allow traffic in from the internet.

Configure the Trust Interface

  1. Select Network-> Interfaces ->Ethernet-> select the link for ethernet1/2 and configure as follows:
    1. Interface Type: Layer3 (default).
    2. On the Config tab, assign the interface to the Trust-VR router.
    3. On the Config tab, expand the Security Zone drop-down and select New Zone. Define a new zone called Trust, and then click OK.
  2. On the IPv4 tab, select DHCP Client if you plan to assign only one IP address on the interface. If you plan to assign more than one IP address select Static and manually enter the primary and secondary IP addresses assigned to the interface on the Azure portal. The private IP address of the interface can be found by navigating to Virtual Machines -> YOURPALOMACHINE -> Networking and using the Private IP address specified on each tab.
    1. Clear the Automatically create default route to default gateway provided by server check box.
      1. Note: Disabling this option ensures that traffic handled by this interface does not flow directly to the default gateway in the VNet.
  3. Click OK

Click Commit in the top right.  Verify that the link state for the interfaces is up (the interfaces should turn green in the Palo Alto user interface).

Define Static Routes

The Palo Alto will need to understand how to route traffic to the internet and how to route traffic to your subnets.  As you will see in this section, we will need two separate virtual routers to help handle the processing of health probes submitted from each of the Azure Load Balancers.

Create a new Virtual Router and  Static Route to the internet

  1. Select Network -> Virtual Router
  2. Click Add at the bottom
  3. Set the Name to Untrust-VR
  4. Select Static Routes -> IPv4 -> Add
  5. Create a Static Route to egress internet traffic
    1. Name: Internet
    2. Destination: 0.0.0.0/0
    3. Interface: ethernet 1/1
    4. Next Hop: IP Address
    5. IP Address: Use the IP address of the default gateway of your subnet the Untrust interface is deployed on
      1. Note: To find this, navigate to the Azure Portal (portal.azure.com) and select All Services -> Virtual Networks -> Your Virtual Network -> Subnets and use the first IP address of your subnet the untrust interface is on.  For example, is the address range of my subnet is 10.5.15.0/24, I would use 10.5.15.1 as my IP address.  If my subnet was 10.5.15.128/25, I would use 129 10.5.15.129 as my IP address
  6. Create a Static Route to move traffic from the internet to your trusted VR
    1. Name: Internal Routes
    2. Destination: your vnet address space
    3. Interface: None
    4. Next Hop: Next VR
      1. Trust-VR
  7. Click OK

Create a new Virtual Router and Static Route to your Azure Subnets

  1. Select Network -> Virtual Router
  2. Click Add at the bottom
  3. Set the Name to Trust-VR
  4. Select Static Routes -> IPv4 -> Add
  5. Create a Static Route to send traffic to Azure from your Trusted interface
    1. Name: AzureVNet
    2. Destination: your vnet address space
    3. Interface: ethernet 1/2
    4. Next Hop: IP Address
    5. IP Address: Use the IP address of the default gateway of your subnet the Trust interface is deployed on
      1. Note: To find this, navigate to the Azure Portal (portal.azure.com) and select All Services -> Virtual Networks -> Your Virtual Network -> Subnets and use the first IP address of your subnet the trust interface is on.  For example, if the address range of my subnet is 10.5.15.0/24, I would use 10.5.15.1 as my IP address.  If my subnet was 10.5.15.128/25, I would use 129 10.5.15.129 as my IP address
  6. Create a Static Route to move internet traffic received on Trust to your Untrust Virtual Router
    1. Name: Internet
    2. Destination: 0.0.0.0/0
    3. Interface: None
    4. Next Hop: Next VR
      1. Untrust-VR
  7. Click OK

Click Commit in the top right.

Configure Health Probes for Azure Load Balancers

If deploying the Scale-Out scenario, you will need to approve TCP probes from 168.63.129.16, which is the IP address of the Azure Load Balancer.  Azure health probes come from a specific IP address (168.63.129.16).  In this case, we need a static route to allow the response back to the load balancer.   For the purpose of this article, we will configure SSH on the Trust interface strictly for the Azure Load Balancer to contact to validate the Palo Alto instances are healthy.

Configure Palo Alto SSH Service for the interfaces

First we need to create an Interface Management Profile

  1. Select Network -> Network Profiles -> Interface Mgmt
  2. Click Add in the button left
  3. Use the following configuration
    1. Name: SSH-MP
    2. Administrative Management Services: SSH
    3. Permitted IP Addresses: 168.63.129.16/32
  4. Click OK

Next, we need to assign the profile to the Trust interface

  1. Select Network -> Interfaces ->select the link for ethernet1/2
  2. Select the Advanced tab
  3. Set the Management Profile to SSH-MP
  4. Click OK

Next, we need to assign the profile to the Untrust interface

  1. Select Network -> Interfaces ->select the link for ethernet1/1
  2. Select the Advanced tab
  3. Set the Management Profile to SSH-MP
  4. Click OK

Create a Static Route for the Azure Load Balancer Health Probes on the Untrust Interface

Next we need to tell the health probes to flow out of the Untrust interface due to our 0.0.0.0/0 rule.

  1. Select Network -> Virtual Router -> Untrust-VR
  2. Select Static Routes -> IPv4 -> Add
  3. Use the following configuration
    1. Name: AzureLBHealthProbe
    2. Destination: 168.63.129.16/32
    3. Interface: ethernet 1/1
    4. Next Hop: IP Address
    5. IP Address: Use the IP address of the default gateway of your subnet the Trust interface is deployed on
      1. Note: To find this, navigate to the Azure Portal (portal.azure.com) and select All Services -> Virtual Networks -> Your Virtual Network -> Subnets and use the first IP address of your subnet the trust interface is on.  For example, if the address range of my subnet is 10.5.15.0/24, I would use 10.5.15.1 as my IP address.  If my subnet was 10.5.15.128/25, I would use 129 10.5.15.129 as my IP address
  4. Click OK

Create a Static Route for the Azure Load Balancer Health Probes on the Trust Interface

Next we need to tell the health probes to flow out of the Trust interface due to our 0.0.0.0/0 rule.

  1. Select Network -> Virtual Router -> Trust-VR
  2. Select Static Routes -> IPv4 -> Add
  3. Use the following configuration
    1. Name: AzureLBHealthProbe
    2. Destination: 168.63.129.16/32
    3. Interface: ethernet 1/2
    4. Next Hop: IP Address
    5. IP Address: Use the IP address of the default gateway of your subnet the Trust interface is deployed on
      1. Note: To find this, navigate to the Azure Portal (portal.azure.com) and select All Services -> Virtual Networks -> Your Virtual Network -> Subnets and use the first IP address of your subnet the trust interface is on.  For example, if the address range of my subnet is 10.5.15.0/24, I would use 10.5.15.1 as my IP address.  If my subnet was 10.5.15.128/25, I would use 129 10.5.15.129 as my IP address
  4. Click OK

Click Commit in the top right.

Create a NAT rule for internal traffic destined to the internet

You will need to NAT all egress traffic destined to the internet via the address of the Untrust interface, so return traffic from the Internet comes back through the Untrust interface of the device.

  1. Navigate to Policies -> NAT
  2. Click Add
  3. On the General tab use the following configuration
    1. Name: UntrustToInternet
    2. Description: Rule to NAT all trusted traffic destined to the Internet to the Untrust interface
  4. On the Original Packet tab use the following configuration
    1. Source Zone: Click Add and select Trust
    2. Destination Zone: Untrust
    3. Destination Interface: ethernet 1/1
    4. Service: Check Any
    5. Source Address: Click Add, use the Internal Address space of your Trust zones
    6. Destination address: Check Any
  5. On the Translated Packet tab use the following configuration
    1. Translation Type: Dynamic IP and Port
    2. Address Type: Interface Address
    3. Interface: ethernet 1/1
    4.  IP Address: None
    5. Destination Address Translation Translation Type: None
  6. Click OK

Click Commit in the top right.

Update your Palo Alto appliance

By default, Palo Alto deploys 8.0.0 for the 8.0.X series and 8.1.0 for the 8.1.X series.  In this case, Palo Alto will strongly recommend you upgrade the appliance to the latest version of that series before helping you with support cases.

To do this, go to Device -> Dynamic Updates -> click Check Now in the bottom left and download the latest build from the list of available updates.

Please note: the update process will require a reboot of the device and can take 20 minutes or so.

Summary

At this point you should have a working scaled out Palo Alto deployment.  If all went well, I would recommend removing the public IP to the management interface or at least scoping it down to the single public IP address you are coming from.  You can find your public IP address by navigating here: https://jackstromberg.com/whats-my-ip-address/

References

Official documentation from Palo Alto on deploying the VM-Series on Azure (took me forever to find this and doesn't cover setting up the static routes or updating the appliance): https://docs.paloaltonetworks.com/vm-series/8-1/vm-series-deployment/set-up-the-vm-series-firewall-on-azure/deploy-the-vm-series-firewall-on-azure-solution-template.html

Official documentation from Palo Alto on Azure VM Sizing: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClD7CAK

Documentation on architecture for the VM-Series on Azure (click the little download button towards the top of the page to grab a copy of the PDF):  https://www.paloaltonetworks.com/resources/guides/azure-architecture-guide

Palo Alto Networks Visio & OmniGraffle Stencils: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmAJCA0

Neat video created by Palo Alto outlining the architecture of a scale-out VM-Series deployment: https://www.paloaltonetworks.com/resources/videos/vm-series-in-azure

Upcoming VMSS version of Palo Alto deployment: PaloAltoNetworks/azure-autoscaling: Azure autoscaling solution using VMSS (github.com)

60 thoughts on “Deploying Palo Alto VM-Series on Azure”

  1. WeilandYutani

    How do you have the user defined routes configured in Azure for the other (spoke) vNets? I've tried pointing at the Trust-LB frontend IP but the traffic doesn't seem to reach the firewall. If I point at one of firewalls directly instead of the Trust-LB routing works.

    Reply ↓
    2. Josh

      Did you ever get this working? I am having the same problem.. individual FW is fine. UDR to Azure LB is not. All resources exist within the same region.

      Reply ↓
      1. Jack Post author

        Do you see the health probes hit the Palos? Typically, non-forwarded traffic to the Palo means the load balancer health probes are failing.

        Reply ↓
  2. Ravi

    Jack, for the external lb, are you able to use the standard lb, or do you need to deploy an application gateway?

    Reply ↓
    1. Jack Post author

      You can front the Palos with either Application Gateway or Azure Load Balancer Standard for the external interface. Just note that Application Gateway only supports HTTP/HTTPS traffic, so all other traffic would need to flow through the Azure Load Balancer.

      Reply ↓
  3. Manuel Araica

    Hi Jack,

    Did you create the firewall in its own dedicated "Network Vnet" if so, is that best practice?

    thanks

    Reply ↓
    1. Jack Post author

      Sorry for slow reply. It is not required for the appliance to be in its own VNet. You can either leverage one big vnet with several subnets or follow a hub/spoke architecture, where the appliance would typically be deployed in the hub.

      Reply ↓
  4. Petr

    In the definition of static routes you have: "If my subnet was 10.5.15.0/25, I would use 129 10.5.15.129 as my IP address"
    Why 129? 129 is not part of 10.5.15.0/25 🙁

    Reply ↓
  5. Ash Dubey

    Hi Jack!

    Thanks for the detailed technical narrative! Were your Palos active/active? How did you manage the failover since external Azure Load Balancer does not support HA Ports?

    Thanks.

    Reply ↓
    1. Jack Post author

      HA Ports is not required for the external load balancer. As traffic passes from the internet to the external interface of the Palo, you would NAT the traffic to the private IP of the untrusted NIC, so you retain symmetry.

      Reply ↓
  6. crytpo

    I have a query if we are not using load balancer for health probing do we still need to create 2 Virtual routers ?

    Reply ↓
    1. Jack Post author

      The Azure Load Balancer has to use health probes to determine that the instance is healthy before routing traffic to it.

      Reply ↓
    1. Jack Post author

      Yes, you can establish an IPSec VPN tunnel to a Palo Alto VM-Series appliance in Azure. You'll want to connect to public IPs associated on the VM's NICs vs Azure Load Balancer, since Azure Load Balancer only supports TCP and UDP traffic.

      Reply ↓
  9. Hophead84

    Hi Jack

    Firstly, thank you for this guide and template.

    It is a bit vague to interpret the diagram from Palo, but the diagram you inserted from the Palo reference architecture shows the same public IP/PIP (191.237.87.98) on the Untrusted Load Balancer, and the untrust interfaces of each firewall. In the ARM template you supplied, it creates a unique PIP for each of these (1 for the LB, 1 for FW1 untrust, 1 for FW2 untrust). I guess my question is 1) Why do the untrust interface of the firewalls need a PIP? Is it because the load balancer is only used for inbound traffic? If so, I would think it could cause route asymmetry? Or does the LB source NAT inbound requests before the traffic hits the Palo Alto?

    Thank you

    Reply ↓
    1. Jack Post author

      Ha, yeah it does look like their diagram has a typo. I think what they are trying to depict is 191.237.87.98 being the management interface, there should be a different IP for each of those (most customers remove that public IP after they start the configuration and only access the management interface via private IPs).

      The two public IPs are for scenarios where you have to connect directly to a single Palo for something. For example, let's say you were to establish a VPN connection directly to the Palo's, you wouldn't be able to do that through the Azure Load Balancer.

      Hope this helps,
      Jack

      Reply ↓
  10. PorkChop

    Hi Jack, recently followed your article and so far so good 😀
    I have read & been told of the possibility of asymmetric routing & hoping you could clarify.
    If the Ext LB sends traffic via PA1, the return traffic could be sent via PA2 by the Int LB.
    Is this only an issue with Ext LB or same issue with Int LB subnet to subnet ?
    How do we deal with this?

    Cheers,

    Reply ↓
    1. Jack Post author

      This is correct, you need to be really careful with how you handle traffic between untrust and trust LB or you will run into asymettric traffic as the Azure Load Balancer does not keep track of session state between listeners. All peered VNets/Subnets should forward traffic to the trusted load balancer listener. All untrusted traffic should be to/from the internet. If you decide to label traffic from on-premises or other sources as "untrsuted" that is fine, but you would need to SNAT traffic with the private IP of the instance that handled the traffic so Azure can determine which Palo to send return traffic to.

      Hope this helps!
      Jack

      Reply ↓
  11. JK

    Which NSG/Subnets do the trust/untrust/management parameters correspond to in the diagram? Management is kind of obvious, but is public untrust? private trust? What about the VPN subnet/NSG?

    Thanks!

    Reply ↓
    1. Jack Post author

      Untrust would be the interfaces used to ingress/egress traffic from the internet. Private/trust are what you would push internal traffic within your VNets to.

      Reply ↓
  12. Jimmy

    Great article and thanks for siting your sources!

    I see from the marketplace deployment that PA likes to add public IPs to the MGMT interface, but is that necessary if I'm deploying to a VNET with existing private connectivity?

    Also I noticed that your template creates PIPs for the Untrusted interfaces. Why is that? For just in case connectivity if the Untrusted LB fails?

    Thanks again!

    Reply ↓
    1. Jack Post author

      The public IP is not required on the management interface and can be removed. This is typically leveraged if you don't have any other means to connect to your VNet privately to initially configure the appliance.

      There are public IPs on the untrusted interfaces to allow the scenario of terminating a VPN connection to the Palos. Unfortunately, you cannot terminate a VPN connection to the Azure Load Balancer as AH/ESP traffic would be dropped, so it would need to go directly to the public IP of the VM. If you are only planning on using the Palos to inspect egress traffic to the internet or host specific services that are TCP/UDP, you can eliminate the Instance Level Public IPs on the untrusted NICs.

      Reply ↓
  13. Mustafa

    Hi Jack,

    Thank you for writing a nice article. i have a pair of Pans running in azure. I have a hub & spoke setup, i'm using HA ports for spoke to spoke and on-premise to spoke on a single front-end IP. But in your diagram i can see two front-end IPs. I have a question about traffic flow, how would the asymmetric routing be controlled as when we use multiple front-end IPs, it potentially result in different rendezvous hash values and the traffic flow will not be symmetrical.

    Reply ↓
    1. Jack Post author

      The diagram has 3 public IPs; one public IP on each instance and one public IP on the load balancer. When traffic comes in on the load balancer, return traffic out to the internet will automatically be SNATed with the correct IP address as Azure will remember state from the original packet. Any traffic to a specific instance should be SNATed with the private IP address of the untrusted interface and that will egress with the ILPIP on the NIC.

      Hope this helps!
      Jack

      Reply ↓
  14. PorkChop

    Hi Jack, it seems some vital config has been left out which would be great to clarify.
    All deployments i have read indicate the firewall config routes outbound Internet traffic via the ext public LB and suggests it will just work, however by default with standard LB, only inbound traffic is allowed (as long as NSG is applied) - outbound traffic is not allowed by default.
    This had me stumped for a bit because no deployment doc mentions that you need to manually create outbound rules via cli only!
    I found the 'Azure LB outbound rules' document a bit convoluted, so would be great to see this included & simplified in your document - or better yet, a complete 'step-by-step guide that doesn't seem to exist as yet.......

    Reply ↓
    1. Jack Post author

      Hello PorkChop,

      Outbound traffic is enabled by default on Azure Load Balancer Standard, provided the traffic is TCP/UDP and there is an external facing listener with a public IP. The outbound rules are recommended and are useful when you want to explicitly define how traffic should egress from the backend pool, but is not required. The default behavior for outbound traffic is documented here: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections#scenarios

      Jack

      Reply ↓
  15. Jon C

    Thank you very much for sharing this template. I've been in a whole world of pain simply trying to deploy two HA firewalls. As you say, the marketplace doesn't allow you to select an AV set. The palo alto template has hard coded ip ranges, uses basic SKU, has no load a balances and also includes a web and db server, which isn't needed - all very frustrating, but thank you for sharing.

    Reply ↓
  16. Kha Yu

    Is there a way to setup a server in vnet to use specific public IP when initiating outbound connection? Our setup is ELB-->VM300 x2 -->VNETs.
    We have few applications running in different VNETs behind vm-300. Each is assigned its own public IP on ELB front end. By enabling floating IP feature on LB rule we can NAT public IP to private IP of server on vm-300. But I can't figure out how to setup so when server initiate outbound connection, ELB use the specific public IP for that server.

    Reply ↓
    1. Jack Post author

      If using floating IP, you will need to source NAT replies with the IP address of the floating IP vs the private IP of the NIC that the load balanced traffic is being sent to.

      Jack

      Reply ↓
  17. Joel McMillin

    Can I get a copy of the Visio diagram in this article? Do you know where to get the VM series stencils for Visio?

    Reply ↓
  18. Derrick

    Thanks for putting this together. I was able to deploy using this template but ran into issues when configuring the load balancer for on prem. I started seeing asymmetric routing. What is the appropriate configuration for the 10.5.15.21 LB in your diagram? Does this need floating IP enabled?

    Reply ↓
    1. Jack Post author

      Hello Derrick,

      Are you trying to create another listener or load balancer just for traffic coming from on-prem? You should only use the single trusted/internal load balancer for both azure and on-prem traffic (this will ensure traffic symetry). In addition, if you are establishing an IPSec tunnel to your on-prem environment via Azure's VPN or ER gateways, ensure you have a route table on the GatewaySubnet that forces traffic to the load balancer. This will make sure that you don't have asymmetric traffic flow.

      Hope this helps!
      Jack

      Reply ↓
  19. Richard Bottiglieri

    Great information here! Quick question for you: I have this all setup, and the Palo Alto in Azure is successfully filtering traffic. One thing I can't seem to do from behind the firewall, however, is ping public internet sites. As a result, I cannot run trace routes, either. I'm trying to ping 8.8.8.8, but I'm not getting anything back. Ping and tracert are both allowed through the firewall. Any ideas?

    Thanks!

    Rich

    Reply ↓
  20. Richard Bottiglieri

    Actually, right after I posted this, I made a change on the Azure side that worked.

    For the untrust interface in Azure, I had originally setup a secondary IP address with a public address. This configuration wouldn't work for pings. So, I removed that secondary IP address, and I put the public address right on the untrust interface. So, now one IP configuration on the untrust interface, with both a public and private IP address. The NSG does allow outbound internet traffic, but nothing is permitted to come inbound on that interface.

    Thanks.

    Rich

    Reply ↓
  21. Rag

    Hi Jack, Great post than you for posting this. I am planning to deploy a HA pair Palo Alto firewalls as I don't require elastic scaling. Do I still need internal/external Azure LBs please? Have you done any deployments in this HA scenario if yes, please share your thoughts. Many thanks

    Reply ↓
    1. Jack Post author

      Yes, if you want both Palos to be running and have failover < 1 minute. The HA configuration requires updates to route tables, which increases the amount of time needed for failover (1.5min+).

      Reply ↓
  22. Chaitanya P

    Hi Jack,

    I have one question pertaining to outbound Internet access for Virtual machines. In the article the next-hop is mentioned as Gateway of the untrust subnet for Palo Alto device. Could you please provide me the configuration on the Public LB to pick the traffic from Gateway of the untrust subnet.

    Reply ↓
    1. Jack Post author

      Public LB has the Palo Alto instances in the backend pool and will push traffic from the internet to the VM. When the Palo Alto sends the response back to client on the internet, the next hop needs to be Azure's default gateway so that Azure can route traffic outbound appropriately; you do not send the traffic back to the load balancer directly as it's part of Azure's software defined network.

      Jack

      Reply ↓
  23. Paul S

    Hey Jack,

    Great article, thanks for sharing. In testing this out I was getting some issues with the ALB probe working and when I went over it again I noticed that in the section for the Static Route for the Azure Load Balancer Health Probes on the Untrust Interface, you specified to use the Trust interface default gateway and not the Untrust internface default gateway which seems wrong. Can you please confirm?

    -Paul

    Reply ↓
  25. Ken L

    Jack,
    I know this is an older thread but honestly, it is still the best reference to create a proper load-balanced PAN firewall setup in Azure. Things have changed in Azure and this could use at least one minor update. The rule in Azure is that if you have a Public IP of SKU type standard they REQUIRE a NSG to be on that subnet if connected to a load balancer, or direct (or subnet) on NIC is associated with NIC to allow incoming traffic. Your scripts do not create a NSG for the untrusted NIC assuming that no NSG means all traffic allowed etc. that is no longer the case with the public IP SKU type standard. You need to add the NSG with an ANY ANY ANY rule to allow for incoming traffic, Also the proper settings on the outbound side are not clear now. Do we need a outbound ELB rule to a Public IP Prefix? Also new settings on the LB rules to SNAT or not, lock backend to client IP etc or use floating IP.. those should be clearly defined. PAN would do well to replicate your efforts, great job.

    Reply ↓
    1. Jack Post author

      Hey Ken,

      I made the decision to not add the NSG as if you are deploying into an existing Virtual Network as it may have an NSG already and I don't want to break other things. See in the article this note here: "Note: For the untrust interface, within your Azure environment ensure you have a NSG associated to the untrust subnet or individual firewall interfaces as the template doesn’t deploy this for you (I could add this in, but if you already had an NSG I don’t want to overwrite it). As per Azure Load Balancer’s documentation, you will need an NSG associated to the NICs or subnet to allow traffic in from the internet."

      Jack

      Reply ↓
  26. ManIT

    Hey Jack,
    great article.
    I try this configuration, but I have asymmetric routing.
    If I configure source NAT on both PA VM for inbound traffic (with private ip of trust interface of PA VM), this resolve asymmetry, but on backend VM (web for example) I see obviously the private ip of PA VM as source ip and not real ip of visitors.
    I try many config but I not find a solution.
    How did you solve the problem of asymmetry ?

    Thanks!

    Reply ↓
    1. Jack Post author

      Unfortunately, you must NAT and lose the original source IP as there is no way to ensure symmetry of traffic without doing so in an active/active setup. The only other option is to go with an active/passive configuration or consider using the new Azure Route Server service (which I do not have instructions for).

      Reply ↓
      1. ManIT

        Hello Jack,
        exist another configuration for having PA VM on active/active setup for not losing source IP ?
        An alternative is active/passive with Azure Floating IP, but this configuration create 3-5 minutes of downtime for unexpected problems but also for scheduled maintenance activities on firewalls.

        Reply ↓
  27. ankur

    HI,

    Thanks for posting this article. I tired to deploy this on azure but i am seeing load balancers are not deployed:

    {
    "status": "Failed",
    "error": {
    "code": "InvalidResourceReference",
    "message": "Resource /subscriptions/85cd46fd-6107-4aa8-b78a-e3a091bede1a/resourceGroups/PALOALTO/providers/Microsoft.Network/virtualNetworks/TEST-VNET referenced by resource /subscriptions/85cd46fd-6107-4aa8-b78a-e3a091bede1a/resourceGroups/paloalto/providers/Microsoft.Network/loadBalancers/Contoso-FW-Trust-LB was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.",
    "details": [
    {
    "code": "NotFound",
    "message": "Resource /subscriptions/85cd46fd-6107-4aa8-b78a-e3a091bede1a/resourceGroups/PALOALTO/providers/Microsoft.Network/virtualNetworks/TEST-VNET not found."
    }
    ]
    }
    }
    I am getting this error. Can you help

    Reply ↓
  28. Harcharan Singh

    Thanks Jack, the article is very detailed and helpful, explained the full approach. I have a doubt. I'm deploying Palos in active/active without true HA and without state synchronization, For the scenario- the traffic coming from Internet towards internal web-server, how can the ELB remember the state that the same session packets delivered to same Palo on untrust public interface and not to other Palo which may drop the packet, can we use session persistency on ELB to achieve this?

    Reply ↓
  29. Frank Garcia

    Hello Jack, really appreciate your guidance on PA/Azure deployment. I've been around the block with PA VM's and other NVA's in Azure and respect the content you've put together.

    Any plans to document anything with PRISMA CN?

    Best..

    Frank

    Reply ↓
    1. Jack Post author

      Appreciate the comment Frank. Unfortunately, I do not have access to PRISMA licensing, so I don't have the ability to document anything on that front.

      Jack

      Reply ↓

Leave a Reply

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