PDF(1.3 MB) View with Adobe Reader on a variety of devices
ePub(1.4 MB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(1.0 MB) View on Kindle device or Kindle app on multiple devices
Updated:March 14, 2021
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to deploy the autoscaled Cisco Firepower Threat Defense Virtual (FTDv) in Azure in a high trust environment.
Cisco recommends that you have knowledge of these topics:
NGFW and Firepower Management Center should communicate over Private IP
External Load Balancer should not have public IP.
Function’s App should be able to communicate to Private IP
The information in this document is based on these software and hardware versions:
Firepower Management Center
Virtual Machine Scale Set
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
FTDv brings Cisco's Firepower Next-Generation Firewall functionality to virtualized environments, enabling consistent security policies to follow workloads across your physical, virtual, and cloud environments, and between clouds.
With these deployments being available in a virtualized environment, currently support for HA is not available for NGFW. Hence, to provide a highly available solution Cisco Next-Generation Firewall (NGFW) utilizes Azure's native features such as Availability Sets and Virtual Machine Scale Set (VMSS) to make NGFW highly available and cater to increasing traffic on demand.
This document focuses on Configuring Cisco NGFW to AutoScale based on different parameters wherein NGFW scales in or scales out ON-DEMAND. This covers the use case where the customer has a requirement to use Firepower Management Center (FMC) which is available in colocation datacenter and needed to centrally manage all NGFW, also customers don't want to have FMC and FTD to communicate over Public IP for management traffic.
Before going deeper into configuration and design consideration following are the few concepts that should be well understood wrt to Azure:
Availability Zone: An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking.
VNET: Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. VNet is similar to a traditional network that you'd operate in your own data center but brings with it additional benefits of Azure's infrastructure such as scale, availability, and isolation. Every subnet within a VNET is reachable to each other by default, but the same is not true for subnets in different VNETs.
Availability Set: Availability sets are another datacenter configuration to provide VM redundancy and availability. This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA.
VMSS: Azure virtual machine scale sets let you create and manage a group of load-balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets provide high availability to your applications and allow you to centrally manage, configure, and update a large number of VMs. With virtual machine scale sets, you can build large-scale services for areas such as compute, big data, and container workloads.
Functions App: Azure Functions is a cloud service available on-demand that provides all the continually-updated infrastructure and resources needed to run your applications. You focus on the pieces of code that matter most to you, and Azure Functions handles the rest. You can use Azure Functions to build web APIs, respond to database changes, process IoT streams, manage message queues, and more. In this Autoscaled solution, Azure Function are various API requests to FMC for creating objects, registering/de-registering FTDv, checking the parameters, etc.
Logic App: Azure Logic Apps is a cloud service that helps you schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, systems, and services across enterprises or organizations. Logic Apps simplifies how you design and build scalable solutions for app integration, data integration, system integration, enterprise application integration (EAI), and business-to-business (B2B) communication, whether in the cloud, on-premises, or both. This solution provides logical sequencing of the Functions to be executed for the functioning of the Autoscaled solution.
Currently, the AutoScale solution available for NGFW does not provide a management plan to communicate with the Private IP local to the VNet and requires Public IP to exchange communication between Firepower Management Center and NGFW.
This article aims to solve this problem until the verified solution is available for Firepower Management Center and NGFW communication over private IP.
In order to create an Autoscaled NGFW solution this Configuration Guide is used:
The Function App is a set of Azure functions. The basic functionality includes:
Communicate/Probe Azure metrics periodically.
Monitor the FTDv load and trigger Scale In/Scale-Out operations.
Register a new FTDv with the FMC.
Configure a new FTDv via FMC.
Unregister (remove) a scaled-in FTDv from the FMC.
As mentioned in the requirement the various Function being created for On-Demand NGFW creation or deletion is done based on the NGFW’s Public IP. Hence we need to tweak C# code to get private IP instead of Public IP. After Tweaking the code the zip file to create the Function App is available at https://github.com/Madhuri150791/FunctionApp_with_Premiium_Plan.git
with the name ASM_Function.zip. This enables the Functions app to communicate to Internal Resources without having the Public IP.
The Auto Scale Logic App is a workflow, i.e. a collection of steps in a sequence. Azure functions are independent entities and cannot communicate with each other. This orchestrator sequences the execution of these functions and exchanges information between them.
The Logic App is used to orchestrate and pass information between the Auto Scale Azure functions.
Each step represents an Auto Scale Azure function or built-in standard logic.
The Logic App is delivered as a JSON file.
The Logic App can be customized via the GUI or JSON file.
Here the Azure Subscription, Resource Group Name, and Function App Name need to be replaced before use, else it does not allow to save successfully.
Click Save. Navigate to Logic App Overview and Enable Logic App.
Once the Logic App is enabled then immediately it starts executing in the interval of 5 min.
If everything is configured correctly then you see trigger actions getting successful.
Also, VM is created under VMSS.
Log in to FMC and check that FMC and NGFW are connected over FTDv Private IP:
While you login to the NGFW CLI you see these :
Hence FMC communicates to NGFW over Azure Private VNet Subnet.
Sometimes Logic App fails while building up a new NGFW, to troubleshoot such condition these steps can be taken:
Check if the Logic App is running successfully.
Identify the cause of Failure.
Click on the failed trigger.
Try to identify the failure point from the code flow. From the above snippet, it is clear that ASM logic failed as it was not able to connect to FMC. Next, you need to identify why FMC was not reachable as per flow within Azure.