End-of-Life (EoL)
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-yesInboundRG-<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
Recommended Videos
Recommended videos not found.