VM-Series Deployment Guide
    : Auto Scaling on Azure—How it Works
    Focus
    Download PDF
    Focus
    1. Home
    2. VM-Series
    3. VM-Series Deployment Guide
    4. Set up the VM-Series Firewall on Azure
    5. Auto Scaling the VM-Series Firewall on Azure
    6. Auto Scaling on Azure—How it Works
    Download PDF

    VM-Series Deployment Guide

    Auto Scaling on Azure—How it Works

    Table of Contents

    Auto Scaling on Azure—How it Works

    The primary reason you want to deploy an auto scaling set of VM-Series firewalls is to ensure operational efficiency and to secure traffic to your highly available internet-facing applications when demand spikes, and to maintain cost efficiency when demand drops and the application workloads scale in.
    The first step in the process of enabling auto scaling with the VM-Series firewalls is to launch the infrastructure template which provides the messaging infrastructure. The Panorama plugin for Azure uses this infrastructure to learn about the VM-Series firewall VMSS that are deployed when you launch the Hub or Inbound firewall templates and to learn when a new application server pool is added and needs to be secured by the Hub or Inbound firewall templates or both.
    Then, you set up the Auto Scaling definition on Panorama to authorize access using the Service Bus name, Service Bus Key Name, the Shared Access Token, and the Service Principal for the Azure subscription. These details enable Panorama to access the metadata on your Azure resources and to read the messages that the Azure function publishes to the Service Bus.
    When you deploy the Inbound firewall template to secure all inbound traffic to the application server pool, the VMSS for the VM-Series firewalls is launched along with the Azure Application Insights instance to which these firewalls publish the PAN-OS metric that you want to trigger auto scaling. As a part of the template inputs, you choose the PAN-OS scaling metric and threshold values for the Application Insights alarms that trigger the scaling process. The firewalls are automatically bootstrapped using your inputs in the template and added as managed devices to Panorama.
    On Panorama, you can now add the Inbound firewall Resource Group details and enable the auto-programming of routes. The Inbound firewall template has three static routes.
    • A default route to forward traffic to the trust interface, and when enabled this route is used if a more specific route is not available.
    • A route to send return traffic from the application back to the Application Gateway IP address in the Inbound firewall VMSS.
    • A route to perform health checks, which enable load balancing to the firewall instances in the VMSS.
    When the newly launched firewall connects to Panorama, Panorama pushes the device group and template stack configuration which includes the virtual router and policy rules you’ve defined and the auto programmed static routes. In addition, the Panorama plugin also retrieves that Application Insights instrumentation key and adds it to the template stack to which the firewall are assigned. When the firewall reaches the configured threshold, and a scale out event occurs, a new instance of the VM-Series firewall is launched. The firewall is bootstrapped, connects to Panorama and gets its license and configuration to ensure that it can secure your applications.
    When a scale in event occurs, the Panorama plugin deactivates the license on the firewall and manages the lifecycle of the firewall. The IP address of the firewall is removed from the VMSS and the internal load balancer does not route traffic to the firewall.
    The flow in the Hub firewall template is similar, with a slight difference in the static routes configuration.
    In order to direct traffic through the Inbound firewall or Hub VMSS to the applications, there is some configuration that you need to complete:
    To secure inbound application traffic, the application must be connected to the Inbound firewall VMSS. When you onboard your application, you need to do the following:
    • Configure the Application Gateway with the frontend and backend configuration to point to the internal load balancer that fronts the application server pool. Refer to the Azure Application Gateway documentation.
    • In the default BackendUDR, add a route with application subnet as the destination, and the next hop IP address as that of the internal load balancer that fronts the firewall VMSS.
    • Set up VNet peering between the application VNet and the Inbound firewall VMSS VNet, if they are in different VNets. When you use the sample application template included in the GitHub repository, VNet peering is set up for you.
    • Tag the internal load balancer that fronts the application with these name-value pairs. 
      PanoramaManaged-yes
      InboundRG-<Name of the Inbound Firewall Resource Group>
    To secure outbound traffic, you need to complete the following to connect the Hub firewall VMSS to the application VNet:
    • Add a UDR in the route table and associate the application’s subnet to the route table. Refer to the Azure documentation.
    • On the Azure portal, add a default route (0.0.0.0/0) to forward all traffic to the internal load balancer that fronts the Hub firewall VMSS.
    • Tag the internal load balancer that fronts the application with the following name-value pair. 
      HubRG-<Name of the Hub Firewall Resource Group>
      When you tag the internal load balancer in the Application VNet, Panorama learns this and automatically creates a static route in the Hub firewall template stack to direct return traffic to the application workloads.
      Otherwise, you must add a static route on the template stack that manages the configuration of the firewalls in the Hub VMSS, to enable the firewalls in the Hub VMSS to direct traffic back to the application workloads.

    Recommended For You

    © 2024 Palo Alto Networks, Inc. All rights reserved.