Deploy the Firewall Threat Defense Virtual Auto Scale Solution on AWS

This document explains how to deploy the Firewall Threat Defense Virtual auto scale solution on AWS.

About the Firewall Threat Defense Virtual Auto Scale Solution on AWS

The Firewall Threat Defense Virtual instances deployed in public cloud environments such as AWS support applications that experience occasional spikes and dips in network traffic. A spike in traffic could lead to a scenario in which the number of deployed threat defense virtual instances is not enough to inspect the network traffic. A dip in traffic could lead to idle threat defense virtual instances leading to unnecessary operational costs.

The auto scale solution helps organisations to automatically scale up the number of threat defense virtual instances if there is a spike in traffic and also scale down the number of instances during a lull in traffic. This leads to efficient handling of network resources and reduces operational costs.

The Firewall Threat Defense Virtual auto scale in AWS is a completely serverless implementation (no helper VMs involved in the automation of this feature) that adds auto scaling capability to Firewall Threat Defense Virtual instances in the AWS environment.

Starting from version 6.4, Network Load Balancer (NLB)-based auto scale solution is supported on Firewall Threat Defense Virtual managed by management center. Starting from version 7.2, Gateway Load Balancer (GWLB)-based auto scale solution is also supported.

Cisco provides CloudFormation templates and scripts for deploying an auto-scaling group of Firewall Threat Defense Virtual firewalls using several AWS services, including Lambda, auto scaling groups, Elastic Load Balancing (ELB), Amazon S3 Buckets, SNS, and CloudWatch.

The Firewall Threat Defense Virtual auto scale solution is a CloudFormation template-based deployment that provides:

  • Completely automated Firewall Threat Defense Virtual instance registration and de-registration with the Firewall Management Center.

  • NAT policy, access control policy, and routes automatically applied to the scaled-out Firewall Threat Defense Virtual instances.

  • Support for load balancers and multi-availability zones.

  • Works only with the Firewall Management Center; the Firewall Device Manager is not supported.

Enhancements to Auto Scale (Version 6.7)

  • Custom metric publisher―A new lambda function polls the Firewall Management Center every second minute for memory consumption of all the Firewall Threat Defense Virtual instances in the auto scale group, then publishes the value to the CloudWatch metric.

  • A new scaling policy based on memory consumption is available.

  • Firewall Threat Defense Virtual private IP connectivity for SSH and Secure Tunnel to the Firewall Management Center.

  • Firewall Management Center configuration validation.

  • Support for opening more listening ports on the ELB.

  • Modified to single stack deployment. All lambda functions and AWS resources are deployed from a single stack for a streamlined deployment.

Auto Scale Solution with NLB

As the AWS Load Balancer allows only inbound-initiated connections, only externally generated traffic is allowed to pass inside via the Cisco threat defense virtual firewall.

The internet-facing load balancer can be a Network Load Balancer or an Application Load Balancer. All the AWS requirements and conditions hold true for either case. As indicated in the sample topology given below, the right side of the dotted line is deployed via the threat defense virtual templates. The left side is user-defined.


Note

Application-initiated outbound traffic will not go through the threat defense virtual.

Port-based bifurcation for traffic is possible. This can be achieved via NAT rules; see Create a Host object, Add a Device Group, Configure and Deploy NAT Policy, Create a Basic Access Control Policy, Create a Basic Access Control Policy in Management Center. For example, traffic on Internet-facing LB DNS, Port: 80 can be routed to Application-1; Port: 88 traffic can be routed to Application-2.

Sample Topology

Figure 1. Firewall Threat Defense Virtual Auto Scale Solution with NLB

End-to-End Process for Deploying Auto Scale Solution with NLB

The following flowchart illustrates the workflow for deploying Firewall Threat Defense Virtual auto scale solution with NLB on Amazon Web Services (AWS).

Workspace

Steps

Local Host

Download the required files from GitHub

Amazon CloudFormation Console

Auto Scale Solution with NLB - Customize and Deploy the NLB Infrastructure Template on the Amazon CloudFormation Console

Management Center

Configure Network Infrastructure in the Management Center

Local Host

Update the configuration.json and configuration-schema.json Files

Local Host

Configure Infrastructure Components using AWS CLI

Local Host

Create Target Folder

Local Host

Upload Files to Amazon S3 Bucket

Amazon CloudFormation Console

Auto Scale Solution with NLB - Deploy the Auto Scale Solution with NLB

Amazon EC2 Console

Edit the Auto Scale Group

Amazon VPC Console

Configure Routing for VPC

Auto Scale Solution with Gateway Load Balancer

The AWS Gateway Load Balancer (GWLB) allows both inbound and outbound connections. Therefore, both internally and externally generated traffic is allowed to pass through the Firewall Threat Defense Virtual firewall.

The GWLB endpoint sends traffic to the GWLB, and then to the threat defense virtual for inspection. All of the AWS requirements and conditions hold true for either case. As indicated in the Use Case diagram, the right side of the dotted line is threat defense virtual GWLB Autoscale solution deployed via the threat defense virtual templates. The left side is completely user-defined.

Sample Topology

Figure 2. Firewall Threat Defense Virtual Auto Scale Solution with GWLB

End-to-End Process for Deploying Auto Scale Solution with GWLB

The following flowchart illustrates the workflow for deploying Firewall Threat Defense Virtual auto scale solution with GWLB on Amazon Web Services (AWS).

Workspace

Steps

Local Host

Download the required files from GitHub

Amazon CloudFormation Console

Auto Scale Solution with GWLB - Customize and Deploy the GWLB Infrastructure Template on the Amazon CloudFormation Console

Management Center

Configure Network Infrastructure in the Management Center

Local Host

Update the configuration.json and configuration-schema.json Files

Local Host

Configure Infrastructure Components using AWS CLI

Local Host

Create Target Folder

Local Host

Upload Files to Amazon S3 Bucket

Amazon CloudFormation Console

Auto Scale Solution with GWLB - Deploy the Auto Scale Solution with GWLB

Amazon EC2 Console

Edit the Auto Scale Group

Amazon VPC Console

Auto Scale with GWLB solution - Create the GWLB Endpoint

Amazon VPC Console

Configure Routing for VPC

Guidelines and Limitations for the Firewall Threat Defense Virtual and AWS

Licensing

  • BYOL (Bring Your Own License) using a Cisco Smart License Account is supported.

  • PAYG (Pay As You Go) licensing, a usage-based billing model that allows customer to run Firewall Threat Defense Virtual without having to purchase Cisco Smart Licensing. All licensed features (Malware/Threat/URL Filtering/VPN, etc.) are enabled for a registered PAYG device. Licensed features cannot be edited or modified from the Firewall Management Center. (Version 6.5+)


    Note

    PAYG licensing is not supported with Firewall Device Manager.

See Cisco Secure Firewall Management Center Administration Guide for licensing guidelines.

Performance Tiers for Firewall Threat Defense Virtual Smart Licensing

In Version 7.0+, Firewall Threat Defense Virtual supports performance-tiered licensing that provides different throughput levels and VPN connection limits based on deployment requirements.

Table 1. Firewall Threat Defense Virtual Licensed Feature Limits Based on Entitlement

Performance Tier

Device Specifications (Core/RAM)

Rate Limit

RA VPN Session Limit

FTDv5

4 core/8 GB

100 Mbps

50

FTDv10

4 core/8 GB

1 Gbps

250

FTDv20

4 core/8 GB

3 Gbps

250

FTDv30

8 core/16 GB

5 Gbps

250

FTDv50

12 core/24 GB

10 Gbps

750

FTDv100

16 core/34 GB

16 Gbps

10,000

Best Practices

Prerequisites

  • An AWS account. You can create one at http://aws.amazon.com/.

  • An SSH client (for example, PuTTY on Windows or Terminal on macOS) is required to access the device console.

  • A Cisco Smart Account. You can create one at Cisco Software Central https://software.cisco.com/.

  • A GitHub account to download the configuration files and templates.

  • Firewall Threat Defense Virtual interface requirements:

    • Management interfaces (2) — One used to connect the device to the Firewall Management Center, second used for diagnostics; cannot be used for through traffic.

    • You can optionally configure a data interface for Firewall Management Center management instead of the Management interface. The Management interface is a pre-requisite for data interface management, so you still need to configure it in your initial setup. For more information about configuring a data interface for Firewall Management Center access, see configure network management-data-interface in the Cisco Secure Firewall Threat Defense Command Reference.

    • Traffic interfaces (2) — Used to connect the device to inside hosts and to the public network.

  • Communication Paths — Public/elastic IP addresess for access to the device

Components Required to Set Up the Auto Scale Solution with GWLB or NLB

The following components make up the auto scale solution.

CloudFormation Template

The CloudFormation template is used to deploy resources required to set up the auto scale solution in AWS. The template consists of:

  • Auto Scale Group, Load Balancer, Security Groups, and other miscellaneous components.

  • The template takes user input to customize the deployment.


    Note

    The template has limitations in validating user input, hence it is the user’s responsibility to validate input during deployment.

Lambda Functions

The auto scale solution is a set of Lambda functions developed in Python, which gets triggered from Lifecycle hooks, SNS, CloudWatch event/alarm events. The basic functionality includes:

  • Add/Remove Diag, Gig0/0, and Gig 0/1 interfaces to instance.

  • Register Gig0/1 interface to Load Balancer’s Target Groups.

  • Register a new Firewall Threat Defense Virtual with the Firewall Management Center.

  • Configure and deploy a new Firewall Threat Defense Virtual via Firewall Management Center.

  • Unregister (remove) a scaled-in Firewall Threat Defense Virtual from the Firewall Management Center.

  • Publish the memory metric from the Firewall Management Center.

Lambda Functions are delivered to customer in the form of a Python package.

Lifecycle Hooks

  • Lifecycle hooks are used to get lifecycle change notification about an instance.

  • In the case of instance launch, a Lifecycle hook is used to trigger a Lambda function which can add interfaces to the Firewall Threat Defense Virtual instance, and register outside interface IPs to target groups.

  • In the case of instance termination, a Lifecycle hook is used to trigger a Lambda function to deregister the Firewall Threat Defense Virtual instance from the target group.

Simple Notification Service (SNS)

  • Simple Notification Service (SNS) from AWS is used to generate events.

  • Due to the limitation that there is no suitable orchestrator for Serverless Lambda functions in AWS, the solution uses SNS as a kind of function chaining to orchestrate Lambda functions based on events.

VPC

You should create the VPC as required for your application requirements. It is expected that the VPC have an internet gateway with at least one subnet attached with a route to the internet. Refer to the appropriate sections for the requirements for Security Groups, Subnets, etc.

Security Groups

All connections are allowed in the provided Auto Scale Group template. You only need the following connections for the auto scale solution to work.

Port

Usage

Subnet

8305

Management Center to Threat Defense Virtual Secured tunnel connection

Management subnets

Health Probe port (default: 8080)

Internet-facing Load Balancer health probes

Outside, Inside Subnets

Application ports

Application data traffic

Outside, Inside Subnets

Security Groups or ACLs for the Management Center Instance

These are needed to allow HTTPS connections between lambda functions and the management center. As lambda functions are to be kept in lambda subnets having a NAT gateway as the default route, the management center should be allowed to have inbound HTTPS connections from the NAT gateway IP address.

Subnets

Subnets can be created as needed for the requirements of the application. The threat defense virtual requires 3 subnets for operation.


Note

If multiple availability zone support is needed, then subnets are needed for each zone as subnets are zonal properties within the AWS Cloud.

Outside Subnet

The Outside subnet should have a default route with '0.0.0.0/0' to the Internet gateway. This will contain the Outside interface of the threat defense virtual, and also the Internet-facing NLB will be in this subnet.

Inside Subnet

This can be similar to the application subnets, with or without NAT/Internet gateway. Please note that for the threat defense virtual health probes, it should be possible to reach the AWS Metadata Server (169.254.169.254) via port 80.


Note

In this Auto Scale solution, Load Balancer health probes are redirected to the AWS Metadata Server via inside/Gig0/0 interface. However, you can change this with your own application serving the health probe connections sent to the threat defense virtual from the Load Balancer. In that case, you need to replace the AWS Metadata Server object with the application IP address to provide the health probe response.

Management Subnet

This subnet includes the threat defense virtual management interface. If you are using the management center on this subnet, then assigning an elastic IP address (EIP) to the threat defense virtual is optional. The diagnostic interface is also on this subnet.

Lambda Subnets

The AWS Lambda function requires two subnets having the NAT gateway as the default gateway. This makes the Lambda function private to the VPC. Lambda subnets do not need to be as wide as other subnets.

Application Subnets

There is no restriction imposed on this subnet from the auto scale solution, but if the application needs outbound connections outside the VPC, the respective routes should be configured on the subnet. This is because outbound-initiated traffic does not pass through load balancers.For more information, see AWS Elastic Load Balancing User Guide.

Serverless Components

S3 Bucket

Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. You can place all the required files in the S3 bucket.

When templates are deployed, Lambda functions get created referencing zip files in the S3 bucket. Hence, the S3 bucket should be accessible to the user account.

CloudFormation Templates on GitHub

There are two sets of templates are provided for the supported auto scale solutions-one set for setting up the Auto Scale solution using an Network Load Balancer (NLB) and another set for setting up the Auto Scale solution using a Gateway Load Balancer (GWLB).

Auto Scale Solution with Network Load Balancer

The following templates are available on GitHub:

Table 2. List of Template Parameters

Parameter

Allowed Values/Type

Description

PodNumber

String Allowed Pattern: '^\d{1,3}$'

This is the pod number. This will be suffixed to the Auto Scale Group name (threat defense virtual-Group-Name). For example, if this value is '1', then the group name will be threat defense virtual-Group-Name-1.

It should be at least 1 numerical digit but not more than 3 digits. Default: 1.

AutoscaleGrpNamePrefix

String

This is the Auto Scale Group Name Prefix. The pod number will be added as a suffix.

Maximum: 18 characters

Example: Cisco-threat defense virtual-1.

NotifyEmailID

String

Auto Scale events will be sent to this email address. You need to accept a subscription email request.

Example: admin@company.com.

VpcId

String

The VPC ID in which the device needs to be deployed. This should be configured as per AWS requirements.

Type: AWS::EC2::VPC::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LambdaSubnets

List

The subnets where Lambda functions will be deployed.

Type: List<AWS::EC2::Subnet::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LambdaSG

List

The Security Groups for Lambda functions.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

S3BktName

String

The S3 bucket name for files. This should be configured in your account as per AWS requirements.

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LoadBalancerType

String

The type of Internet-facing Load Balancer, either “application” or “network”.

Example: application

LoadBalancerSG

String

The Security Groups for the Load Balancer. In the case of a network load balancer, it won't be used. But you should provide a Security Group ID.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LoadBalancerPort

Integer

The Load Balancer port. This port will be opened on LB with either HTTP/HTTPS or TCP/TLS as the protocol, based on the chosen Load Balancer type.

Make sure the port is a valid TCP port, it will be used to create the Load Balancer listener.

Default: 80

SSLcertificate

String

 The ARN for the SSL certificate for secured port connections. If not specified, a port opened on the Load Balancer will be TCP/HTTP. If specified, a port opened on the Load Balancer will be TLS/HTTPS.

TgHealthPort

Integer

This port is used by the Target group for health probes. Health probes arriving at this port on the threat defense virtual will be routed to the AWS Metadata server and should not be used for traffic. It should be a valid TCP port.

If you want your application itself to reply to health probes, then accordingly NAT rules can be changed for the threat defense virtual. In such a case, if the application does not respond, the threat defense virtual will be marked as unhealthy and deleted due to the Unhealthy instance threshold alarm.

Example: 8080

AssignPublicIP

Boolean

If selected as "true" then a public IP will be assigned. In case of a BYOL-type threat defense virtual, this is required to connect to https://tools.cisco.com.

Example: TRUE

InstanceType

String

The Amazon Machine Image (AMI) supports different instance types, which determine the size of the instance and the required amount of memory.

Only AMI instance types that support the threat defense virtual should be used.

Example: c4.2xlarge

LicenseType

String

The threat defense virtual license type, either BYOL or PAYG. Make sure the related AMI ID is of the same licensing type.

Example: BYOL

AmiId

String

The threat defense virtual AMI ID (a valid Cisco threat defense virtual AMI ID).

Type: AWS::EC2::Image::Id

Please choose the correct AMI ID as per the region and desired version of the image. The Auto Scale feature supports version 6.4+, BYOL/PAYG images. In either case you should have accepted a License in the AWS marketplace.

In the case of BYOL, please update 'licenseCaps' key in Configuration JSON with features such as 'BASE', 'MALWARE', 'THREAT', 'URLFilter' etc.

NoOfAZs

Integer

The number of availability zones that the threat defense virtual should span across, between 1 and 3. In the case of an ALB deployment, the minimum value is 2, as required by AWS.

Example: 2

ListOfAzs

Comma separated string

A comma-separated list of zones in order.

Note

 

The order in which these are listed matters. Subnet lists should be given in the same order.

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

Example: us-east-1a, us-east-1b, us-east-1c

MgmtInterfaceSG

String

The Security Group for the threat defense virtual Management interface.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

InsideInterfaceSG

String

The Security Group for the threat defense virtual inside interface.

Type: AWS::EC2::SecurityGroup::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

OutsideInterfaceSG

String

The Security Group for the threat defense virtual outside interface.

Type: AWS::EC2::SecurityGroup::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

Example: sg-0c190a824b22d52bb

MgmtSubnetId

Comma separated list

A comma-separated list of management subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

InsideSubnetId

Comma separated list

A comma-separated list of inside/Gig0/0 subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

OutsideSubnetId

Comma separated list

A comma-separated list of outside/Gig0/1 subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

KmsArn

String

The ARN of an existing KMS (AWS KMS key to encrypt at rest). If specified, the management center and threat defense virtual passwords should be encrypted. The password encryption should be done using only the specified ARN.

Generating Encrypted Password Example: " aws kms encrypt --key-id <KMS ARN> --plaintext <password> ". Please used such generated passwords as shown.

Example: arn:aws:kms:us-east-1:[AWS Account]:key/7d586a25-5875-43b1-bb68-a452e2f6468e

ngfwPassword

String

All the threat defense virtual instances come up with a default password, which is entered in the Userdata field of the Launch Template (Autoscale Group).

This input will change the password to new provided password once the threat defense virtual is accessible.

Please use a plain text password if KMS ARN is not used. If KMS ARN is used, then an encrypted password should be used.

Example: Cisco123789! or AQIAgcQFAGtz/hvaxMtJvY/x/rfHnI3lPpSXU

fmcServer

Numeric string

The IP address of managing the management center, which is reachable to both Lambda functions and the threat defense virtual management interface.

Example: 10.10.17.21

fmcOperationsUsername

String

The Network-Admin or higher privileged user created in managing the management center. See the information about creating users and roles in the Cisco Secure Firewall Management Center Device Configuration Guide.

Example: apiuser-1

fmcOperationsPassword

String

Please use a plain text password if KMS ARN is not mentioned. If mentioned, then an encrypted password should be used.

Example: Cisco123@ or AQICAHgcQAtz/hvaxMtJvY/x/rnKI3clFPpSXUHQRnCAajB

fmcDeviceGrpName

String

The management center device group name.

Example: AWS-Cisco-NGFW-VMs-1

fmcPerformanceLicenseTier

String

The performance tier license used while registering the Firewall Threat Defense Virtual device on the Firewall Management Center Virtual.

Allowed values: FTDv/FTDv5/FTDv10/FTDv20/FTDv30/FTDv50/FTDv100

fmcPublishMetrics

Boolean

If set to "TRUE", then a Lambda function will be created which runs once in every 2 minutes to fetch the memory consumption of registered threat defense virtual sensors in the provided device group.

Allowed values: TRUE, FALSE

Example: TRUE

fmcMetricsUsername

String

The unique management center user name for metric publication to AWS CloudWatch. See the information about creating users and roles in the Cisco Secure Firewall Management Center Device Configuration Guide.

If the "fmcPublishMetrics' is set to "FALSE" then there is no need to provide this input.

Example: publisher-1

fmcMetricsPassword

String

The management center password for metric publication to AWS CloudWatch. Please use a plain text password if KMS ARN is not mentioned. If mentioned, then an encrypted password should be used.

If the "fmcPublishMetrics' is set to "FALSE" then there is no need to provide this input.

Example: Cisco123789!

CpuThresholds

Comma separated integers

The lower CPU threshold and the upper CPU threshold. The minimum value is 0 and maximum value is 99.

Defaults: 10, 70

Please note that the lower threshold should be less than the upper threshold.

Example: 30,70

MemoryThresholds

Comma separated integers

The lower MEM threshold and the upper MEM threshold. The minimum value is 0 and maximum value is 99.

Defaults: 40, 70

Please note that the lower threshold should be less than the upper threshold. If the "fmcPublishMetrics" parameter is "FALSE" then this has no effect.

Example: 40,50

Instance Metadata Service Version

Boolean

The Instance Metadata Data Service (IMDS) version you want enable for Firewall Threat Defense Virtual instances.

  • V1 and V2 (token optional) : To enables either IMDSv1 or IMDSv2 or a combination of both IMDSv1 and IMDSv2 API calls.

  • V2 only (token required) : To enable only IMDSv2 mode.

Note

 

Firewall Threat Defense Virtual version 7.6 and later supports only IMDSv2 service.

If you are enabling IMDSv2 service for versions earlier than 7.6, then you must select combination of both IMDSv1 and IMDSv2 V1 and V2 (token optional) parameter.

Note

 

If you are using a custom template (that is not provided by Cisco), then note that you must include the HttpEndpoint: enabled and HttpTokens: required properties under MetadataOptions in your template to enable IMDSv2 Required mode.

Auto Scale Solution with Gateway Load Balancer

The following templates are available on GitHub:

Table 3. List of Template Parameters

Parameter

Allowed Values/Type

Description
DeploymentType String

Deployment type that helps to process the traffic from Firewall Threat Defense Virtual to GWLB or the internet.

  • Single-arm: This deployment type enables the Firewall Threat Defense Virtual to return the traffic to AWS GWLB (U-turn) after inspection. By default, the proxy type is set to single-arm when not specified.

  • Dual-arm: This deployment type enables the Firewall Threat Defense Virtual to perform NAT and forward outbound traffic from the outside interface to the internet through the NAT gateway.

PodNumber

String

Allowed Pattern: '^\d{1,3}$'

This is the pod number. This will be suffixed to the Auto Scale Group name (Firewall Threat Defense Virtual-Group-Name). For example, if this value is '1', then the group name will be Firewall Threat Defense Virtual-Group-Name-1.

It should be at least 1 numerical digit but not more than 3 digits. Default: 1

AutoscaleGrpNamePrefix

String

This is the Auto Scale Group Name Prefix. The pod number will be added as a suffix.

Maximum: 18 characters

Example: Cisco-Firewall Threat Defense Virtual-1

NotifyEmailID

String

Auto Scale events will be sent to this email address. You need to accept a subscription email request.

Example: admin@company.com

VpcId

String

The VPC ID in which the device needs to be deployed. This should be configured as per AWS requirements.

Type: AWS::EC2::VPC::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LambdaSubnets

List

The subnets where Lambda functions will be deployed.

Type: List<AWS::EC2::Subnet::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LambdaSG

List

The Security Groups for Lambda functions.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

S3BktName

String

The S3 bucket name for files. This should be configured in your account as per AWS requirements.

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LoadBalancerType

String

The type of Internet-facing Load Balancer, either “application” or “network”.

Example: application

LoadBalancerSG

String

The Security Groups for the Load Balancer. In the case of a network load balancer, it won't be used. But you should provide a Security Group ID.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

LoadBalancerPort

Integer

The Load Balancer port. This port will be opened on LB with either HTTP/HTTPS or TCP/TLS as the protocol, based on the chosen Load Balancer type.

Make sure the port is a valid TCP port, it will be used to create the Load Balancer listener.

Default: 80

SSLcertificate

String

The ARN for the SSL certificate for secured port connections. If not specified, a port opened on the Load Balancer will be TCP/HTTP. If specified, a port opened on the Load Balancer will be TLS/HTTPS.

TgHealthPort

Integer

This port is used by the Target group for health probes. Health probes arriving at this port on the Firewall Threat Defense Virtual will be routed to the AWS Metadata server and should not be used for traffic. It should be a valid TCP port.

If you want your application itself to reply to health probes, then accordingly NAT rules can be changed for the Firewall Threat Defense Virtual. In such a case, if the application does not respond, the Firewall Threat Defense Virtual will be marked as unhealthy and deleted due to the Unhealthy instance threshold alarm.

Example: 8080

AssignPublicIP

Boolean

If selected as "true" then a public IP will be assigned. In case of a BYOL-type Firewall Threat Defense Virtual, this is required to connect to https://tools.cisco.com.

Example: TRUE

InstanceType

String

The Amazon Machine Image (AMI) supports different instance types, which determine the size of the instance and the required amount of memory.

Only AMI instance types that support the Firewall Threat Defense Virtual should be used.

Example: c4.2xlarge

LicenseType

String

The Firewall Threat Defense Virtual license type, either BYOL or PAYG. Make sure the related AMI ID is of the same licensing type.

Example: BYOL

AmiId

String

The Firewall Threat Defense Virtual AMI ID (a valid Cisco Firewall Threat Defense Virtual AMI ID).

Type: AWS::EC2::Image::Id

Please choose the correct AMI ID as per the region and desired version of the image. The Auto Scale feature supports version 6.4+, BYOL/PAYG images. In either case you should have accepted a License in the AWS marketplace.

In the case of BYOL, please update 'licenseCaps' key in Configuration JSON with features such as 'BASE', 'MALWARE', 'THREAT', 'URLFilter' etc.

NoOfAZs

Integer

The number of availability zones that the Firewall Threat Defense Virtual should span across, between 1 and 3. In the case of an ALB deployment, the minimum value is 2, as required by AWS.

Example: 2

ListOfAzs

Comma separated string

A comma-separated list of zones in order.

Note

 

The order in which these are listed matters. Subnet lists should be given in the same order.

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

Example: us-east-1a, us-east-1b, us-east-1c

MgmtInterfaceSG

String

The Security Group for the Firewall Threat Defense Virtual Management interface.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

InsideInterfaceSG

String

The Security Group for the Firewall Threat Defense Virtual inside interface.

Type: AWS::EC2::SecurityGroup::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

OutsideInterfaceSG

String

The Security Group for the Firewall Threat Defense Virtual outside interface.

Type: AWS::EC2::SecurityGroup::Id

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

Example: sg-0c190a824b22d52bb

MgmtSubnetId

Comma separated list

A comma-separated list of management subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

InsideSubnetId

Comma separated list

A comma-separated list of inside/Gig0/0 subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

OutsideSubnetId

Comma separated list

A comma-separated list of outside/Gig0/1 subnet-ids. The list should be in the same order as the corresponding availability zones.

Type: List<AWS::EC2::SecurityGroup::Id>

If the "infrastructure.yaml" file is used to deploy the infrastructure, the output section of the stack will have this value. Please use that value.

KmsArn

String

The ARN of an existing KMS (AWS KMS key to encrypt at rest). If specified, the Firewall Management Center and Firewall Threat Defense Virtual passwords should be encrypted. The password encryption should be done using only the specified ARN.

Generating Encrypted Password Example: " aws kms encrypt --key-id <KMS ARN> --plaintext <password> ". Please used such generated passwords as shown.

Example: arn:aws:kms:us-east-1:[AWS Account]:key/7d586a25-5875-43b1-bb68-a452e2f6468e

ngfwPassword

String

All the Firewall Threat Defense Virtual instances come up with a default password, which is entered in the Userdata field of the Launch Template (Autoscale Group).

This input will change the password to new provided password once the Firewall Threat Defense Virtual is accessible.

Please use a plain text password if KMS ARN is not used. If KMS ARN is used, then an encrypted password should be used.

Example: Cisco123789! or AQIAgcQFAGtz/hvaxMtJvY/x/rfHnI3lPpSXU

fmcServer

Numeric string

The IP address of managing the Firewall Management Center, which is reachable to both Lambda functions and the Firewall Threat Defense Virtual management interface.

Example: 10.10.17.21

fmcOperationsUsername

String

The Network-Admin or higher privileged user created in managing the Firewall Management Center. See the information about creating users and roles in the Cisco Secure Firewall Management Center Device Configuration Guide.

Example: apiuser-1

fmcOperationsPassword

String

Please use a plain text password if KMS ARN is not mentioned. If mentioned, then an encrypted password should be used.

Example: Cisco123@ or AQICAHgcQAtz/hvaxMtJvY/x/rnKI3clFPpSXUHQRnCAajB

fmcDeviceGrpName

String

The Firewall Management Center device group name.

Example: AWS-Cisco-NGFW-VMs-1

fmcPerformanceLicenseTier

String

The performance tier license used while registering the Firewall Threat Defense Virtual device on the Firewall Management Center Virtual.

Allowed values: FTDv/FTDv20/FTDv30/FTDv50/FTDv100

Note

 

FTDv5 and FTDv10 performance tier licenses are not supported with AWS Gateway Load Balancer.

fmcPublishMetrics

Boolean

If set to "TRUE", then a Lambda function will be created which runs once in every 2 minutes to fetch the memory consumption of registered Firewall Threat Defense Virtual sensors in the provided device group.

Allowed values: TRUE, FALSE

Example: TRUE

fmcMetricsUsername

String

The unique Firewall Management Center user name for metric publication to AWS CloudWatch. See the information about creating users and roles in the Cisco Secure Firewall Management Center Device Configuration Guide.

If the "fmcPublishMetrics' is set to "FALSE" then there is no need to provide this input.

Example: publisher-1

fmcMetricsPassword

String

The Firewall Management Center password for metric publication to AWS CloudWatch. Please use a plain text password if KMS ARN is not mentioned. If mentioned, then an encrypted password should be used.

If the "fmcPublishMetrics' is set to "FALSE" then there is no need to provide this input.

Example: Cisco123789!

CpuThresholds

Comma separated integers

The lower CPU threshold and the upper CPU threshold. The minimum value is 0 and maximum value is 99.

Defaults: 10, 70

Please note that the lower threshold should be less than the upper threshold.

Example: 30,70

MemoryThresholds

Comma separated integers

The lower MEM threshold and the upper MEM threshold. The minimum value is 0 and maximum value is 99.

Defaults: 40, 70

Please note that the lower threshold should be less than the upper threshold. If the "fmcPublishMetrics" parameter is "FALSE" then this has no effect.

Example: 40,50

Instance Metadata Service Version

Boolean

The Instance Metadata Data Service (IMDS) version you want enable for Firewall Threat Defense Virtual instances:

  • V1 and V2 (token optional) : Enables either IMDSv1, IMDSv2, or a combination of both IMDSv1 and IMDSv2 API calls.

  • V2 only (token required) : Enables only the IMDSv2 mode.

Note

 

Firewall Threat Defense Virtual Version 7.6 and later support only IMDSv2.

If you are enabling IMDSv2 service for versions earlier than 7.6, you must select combination of both IMDSv1 and IMDSv2 V1 and V2 (token optional) parameters.

Note

 

If you are using a custom template (that is not provided by Cisco) note that you must include the HttpEndpoint: enabled and HttpTokens: required properties under MetadataOptions in your template to enable the IMDSv2 Required mode.

Download the Required Files and CFTs from GitHub to your Local Host

Download the lambda-python-files folder from GitHub. This folder contains the following files:

  • Python (.py) files that are used to create the lambda layer.

  • A configuration.json file that is used to add static routes and customize any network parameters, as required.

Download the following CloudFormation templates from GitHub:

  • Templates for the Auto Scale solution with NLB-

    • infrastructure.yaml – Used to customize the components in the AWS environment.

    • deploy_ngfw_autoscale.yaml – Used to deploy the AWS Auto Scale with NLB solution.

  • Templates for the Auto Scale solution with GWLB-

    • infrastructure_gwlb.yaml – Used to customize the components in the AWS environment.

    • deploy_ngfw_autoscale_with_gwlb.yaml – Used to deploy the AWS Auto Scale with GWLB solution.


Note

Collect values for the template parameters, wherever possible. This will make it easier to enter the values quickly while deploying the templates on the AWS Management console.

Auto Scale Solution with NLB - Customize and Deploy the NLB Infrastructure Template on the Amazon CloudFormation Console

Perform the steps given in this section if you are deploying the auto scale solution with NLB.

Procedure

Step 1

On the AWS Management console, go to Services > Management and Governance > CloudFormation, and click Create stack > With new resources(standard).

Step 2

Choose Upload a template file, click Choose file, and select infrastructure.yaml from the folder in which you downloaded the files.

Step 3

Click Next

Step 4

On the Specify stack details page, enter a name for the stack.

Step 5

Provide values for the input parameters in the infrastructure.yaml template.

Step 6

Click Next.

Step 7

Click Next on the Configure Stack Options window.

Step 8

On the Review page, review and confirm the settings.

Step 9

Click Create Stack to deploy the infrastructure.yaml template and create the stack.

Step 10

After the deployment is complete, go to Outputs and note the S3 Bucket Name.

Auto Scale Solution with GWLB - Customize and Deploy the GWLB Infrastructure Template on the Amazon CloudFormation Console

Perform the steps given in this section if you are deploying the auto scale solution using GWLB.

Procedure

Step 1

On the AWS Management console, go to Services > Management and Governance > CloudFormation, and click Create stack > With new resources(standard).

Step 2

Choose Upload a template file, click Choose file, and select infrastructure_gwlb.yaml from the folder in which you downloaded the files.

Step 3

Click Next

Step 4

On the Specify stack details page, enter a name for the stack.

Step 5

Provide values for the input parameters in the infrastructure_gwlb.yaml template.

Step 6

Click Next.

Step 7

Click Next on the Configure Stack Options window.

Step 8

On the Review page, review and confirm the settings.

Step 9

Click Create Stack to deploy the infrastructure_gwlb.yaml template and create the stack.

Step 10

After the deployment is complete, go to Outputs and note the S3 Bucket Name.

Configure Network Infrastructure in the Management Center

Create and configure device droups, objects, health check port, NAT policy, and access policies, in the Management centre for the registered Threat Defense Virtual.

You can manage the threat defense virtual using the management center, a full-featured, multidevice manager on a separate server. The threat defense virtual registers and communicates with the management center on the Management interface that you allocated to the threat defense virtual virtual machine.

See About Secure Firewall Threat Defense Virtual with the Secure Firewall Management Center for more information.

All the objects used for the threat defense virtual configuration should be created by user.

Add Users

Procedure

Step 1

Log in to the Management Center. You must create two user accounts in the management center: one for Autoscale automation and the other for user publishing metrics to CloudWatch.

Step 2

Choose Settings > Users.

Step 3

To create a new user:

  1. Click Create User.

  2. Enter a User Name.

    The username must comply with the following restrictions:

    • Maximum 32 alphanumeric characters, plus hyphen (-) and underscore (_).

    • Letters may be upper case or lower case.

    • Cannot include any punctuation or special characters other than period (.), hyphen (-), and underscore (_).

Step 4

Enter values in the Password and Confirm Password fields.

The values must conform to the password options you set for this user.

Step 5

In the User Role Configuration area, check the Administrator check box.

Note down these user credentials to use when deploying the Autoscale Solution Template. You need to mention these user credentials in the FMC Automation Configuration and FMC Device Group Metrics Publish Configuration.

Step 6

Click Save.

Add Device Group

The management centre allows you to group devices so you can easily deploy policies and install updates on multiple devices. You can expand and collapse the list of devices in the group.


Important

A device group should be created and rules should be applied on it. All the configurations applied on the device group will be pushed to the Threat Defense Virtual instances.

Procedure

Step 1

Choose Devices > Device Management.

Step 2

From the Add drop-down menu, choose Add Group.

Step 3

To edit an existing group, click Edit (edit icon) for the group you want to edit.

Step 4

Enter a Name.

Step 5

Click OK to add the device group.

Note

 

Enter this Device Group Name under fmcDeviceGrp when creating Autoscale Stack.

Create a Host object

Before you begin

You must create a host object when using the AWS Network Load Balancer (NLB).

Note

AWS Gateway Load Balancer (GWLB) does not require a host object.

Procedure

Step 1

Log in to the Management Center.

Step 2

Choose Objects > Object Management.

Step 3

Choose Network from the list of object types.

Step 4

Choose Add Object from the Add Network drop-down menu.

Step 5

Enter a Name.

Step 6

Enter a Description.

Step 7

In the Network field, select the Host option and enter the following values.

  1. Name of the object type as aws-metadata-server.

  2. Depending on the type of host protocol, enter the following IP address for IPv4 - 169.254.169.254.

Step 8

Click Save.

Create a Port object

Before you begin

You must create a port object when using the AWS Network Load Balancer (NLB).

Note

AWS Gateway Load Balancer (GWLB) does not require a port object.

Procedure

Step 1

Log in to the Management Center.

Step 2

Choose Objects > Object Management.

Step 3

Choose Port from the list of object types.

Step 4

Choose Add Object from the Add Port drop-down menu.

Step 5

Enter a Name.

Step 6

Choose a Protocol. You must choose the protocol that you have entered for the Host object type. Depending on the protocol you chose, constrain by Port, or choose an ICMP Type and Code.

Step 7

Enter 8080. Note that you can customise the port number that you enter here as per your requirement.

Note

 

You must constrain the object by port if you chose to match All protocols, using the Other drop-down list.

Step 8

Click Save.

Create Security Zone and Interface Group Objects

Procedure

Step 1

Choose Objects > Object Management.

Step 2

Choose Interface from the list of object types.

Step 3

Click Add > Security Zone.

Step 4

Enter a Name - Inside-sz.

Step 5

Choose Routed from the Interface Type drop-down list.

Step 6

Click Save.

Step 7

Similarly, you must create Outside-sz by repeating Step 1 through Step 6.

Step 8

Create VNI Security Zone if deploying GWLB Dual-arm.

Enable Port for Health Check Probe

You can enable port 22 (SSH) or port 443 (HTTP) for the health check probe.


Note

AWS Gateway Load Balancer (GWLB) does not require the health check probe.

Enable Port 22 (SSH) for Health Check Probe

If you are using port 22 (SSH) for the health check probe, perform the following procedure to enable the port for the health check probe.

Procedure

Step 1

Choose Devices > Platform Settings > SSH Access.

Step 2

Click + Add.

Step 3

Select any IP Address from the drop-down list.

Step 4

From the Available Zones/Interfaces window, select the outside interface that is connected to the GWLB or the outside subnet.

Step 5

Click Add to add that interface to the Selected Zones/Interfaces window.

Step 6

Click OK.

Step 7

Click Save.

Enable Port 443 (HTTP) for Health Check Probe

If you are using port 443 (HTTP) for the health check probe, perform the following procedure to enable the port for the health check probe.

Procedure

Step 1

Choose Devices > Platform Settings > HTTP Access.

Step 2

Select the Enable HTTP Server checkbox.

Step 3

Enter 443 in the Port field.

Step 4

Click + Add.

Step 5

Select the relevant IP Address from the drop-down list.

Step 6

From the Available Zones/Interfaces window, select the outside interface that is connected to the GWLB or the outside subnet.

Step 7

Click Add to add that interface to the Selected Zones/Interfaces window.

Step 8

Click OK.

Step 9

Click Save.

Auto Scale Solution with NLB - Configure and Deploy Network Address Translation (NAT) Policy

A typical NAT rule converts internal addresses to a port on the outside interface IP address. This type of NAT rule is called interface Port Address Translation (PAT). See Configure NAT in Managing the Secure Firewall Threat Defense Virtual with the Secure Firewall Management Center for information about the NAT policy.

One mandatory rule is required in your NAT policy. An example of a NAT rule is given below:

  • Source Zone: Outside Zone

  • Dest Zone: Inside Zone

  • Original-sources: any-ipv4

  • Original source port: Original/default

  • Original Destinations: Interface

  • Original-destination-port: 8080/or any health port that user configures

  • Translated-sources: any-ipv4

  • Translated source port: Original/default

  • Translated-destination: aws-metadata-server

  • Translated-destination-port: 80/HTTP

Similarly, any data-traffic NAT rules can be added, so that this configuration will be pushed to the threat defense virtual devices.


Important

NAT Policy created should be applied on the device group. The management center validation from the Lambda function verifies this.

Procedure

Step 1

Log in to Secure Firewall Management Center.

Step 2

On the Devices menu, click NAT.

Step 3

Click New Policy > Threat Defense NAT to create a new policy.

Step 4

Enter the Name and Description for the NAT policy.

Step 5

Click Save.

You can see a new policy is added and listed on the NAT page.

Step 6

Click Add Rule.

Step 7

Select the Manual NAT Rule from the NAT Rule drop-down list.

Step 8

Select In Category and NAT Rule Before from the Insert drop-down list.

Step 9

Select Static from the Type drop-down menu.

Step 10

Enter the description.

Step 11

In the Interface Objects menu, add the source and destination objects.

Step 12

In the Translations menu, add the following values for each parameter.

Parameter

Values

Original Source

any-ipv4

Original Destination

Address

Original Source Port

HTTP

Original Destination Port

8080

Translated Source

any-ipv4

Translated Source Port

Original/default

Translated Destination

aws-metadata-server

Translated Destination Port

80/HTTP

Step 13

Click Save to save and add the Rule.

Step 14

Select the new rule you have created to deploy on the threat defense virtual.

Step 15

Click Deploy > Deployment to deploy the policy to assigned devices. The changes are not active until you deploy them.

Create a Basic Access Control Policy

When you create a new access control policy, it contains default actions and settings. After creating the policy, you are immediately placed in an edit session so that you can adjust the policy to suit your requirements.

Procedure

Step 1

Choose Policies > Access Control.

Step 2

Click New Policy.

Step 3

Enter a unique Name - aws-asg-policy and Description.

Step 4

Specify the initial Default Action - Block all traffic.

Step 5

Click Save.

Step 6

Click the Targeted Devices on the upper right side of the page to assign the policy.

Step 7

Select the Device Group created previously.

Step 8

Click Add to Policy and then click OK to add to policy.

Step 9

Click the Edit icon for the new policy that you created.

Step 10

Click Add Rule.

Step 11

Set the following parameters:

  • Name: inside-to-outside

  • Insert: into Mandatory

  • Action: Allow

  • Add a source zone and destination zone.

Step 12

Click Apply.

Update the configuration.json and configuration-schema.json Files

The configuration.json and configuration-schema.json files are in the lambda_python_files folder that you downloaded from GitHub. Update the parameters in the configuration.json file with the parameters set up by you in the management center. Note that the JSON key should not be changed.

When editing the configuration.json file, ensure that the names of interfaces, security zone objects, device groups, and policies exactly match the corresponding object names in the management center.

The sample scripts for the configuration.json and configuration-schema.json files are available in the sample-az-configuration-jsons folder at https://github.com/CiscoDevNet/cisco-ftdv/tree/master/autoscale/aws/sample-configuration-jsons.

Based on your deployment topology, you must replace the script in the configuration.json and configuration-schema.json files with the sample script from the files with the same name as follows.

  • For deploying GWLB single-arm topology - Use gwlb-single-arm-Configuration.json and gwlb-single-arm-Configuration-schema.json.

  • For deploying GWLB dual-arm topology - Use 'gwlb-dual-arm-configuration.json and gwlb-dual-arm-configuration-schema.json.

  • For deploying NLB topology - Use nlb-Configuration.json and nlb-Configuration-schema.json.

Configure Infrastructure Components using AWS CLI

The templates do not create the Lambda layer and encrypted passwords for the threat defense virtual and management center. Configure these components using the procedures given below. See AWS Command Line Interface for more information on the AWS CLI.

Create the Lambda Layer Zip File to Manage Compute Resources

Create Lambda Layer autoscale_layer.zip needed for Lambda Functions.

The autoscale_layer.zip can be created on an Amazon Linux VM, with Python 3.11 installed. It is recommended to use AWS Cloudshell, which runs the latest version of Amazon Linux.

For creating the autoscale_layer.zip file, you need to first create requirements.txt file that consists of the python library package details and then run the shell script.

Procedure

Step 1

Create the requirements.txt file by specifying the python package details. 

$ cat requirements.txt 
pycryptodome
paramiko
requests
scp
jsonschema
cffi
zipp
importlib-metadata

Step 2

Run the following commands to create autoscale_layer.zip file.

$ pip3 install --platform manylinux2014_x86_64 
--target=./python/lib/python3.11/site-packages 
--implementation cp --python-version 3.11 --only-binary=:all: 
--upgrade -r requirements.txt
$ zip -r autoscale_layer.zip ./python

Note

 

If you encounter a dependency conflict during installation, for example, for packages urllib3 or cryptography, include the conflicting packages along with their recommended versions in the requirements.txt file. Run the installation command again to resolve the conflict.

Step 3

Place the resultant autoscale_layer.zip file in the directory cisco-ftdv/autoscale/aws/lambda-python-files.

Step 4

Create autoscale_manager.zip, lifecycle_ftdv.zip and custom_metric_fmc.zip files.

  1. Run the following make.py file that is available in the cloned repository of the top-level directory. 

    python3 make.py build
    It creates compressed python files into four separate zip files and then copies them to the target folder.

  2. Upload these four zip files to the S3 bucket created by the infrastructure template. Ensure that the Python 3 environment is available.

(Optional) Create Encrypted Passwords for the Threat Defense Virtual and Management Center

If a KMS ARN value has been entered in the infrastructure_gwlb.yaml template file, the passwords that you set up in the threat defense virtual and management centre have to be encrypted. See Finding the key ID and key ARN to identify the key ARN using the AWS KMS console. On your local host, encrypt the password by running the following AWS CLI command. 

$ aws kms encrypt --key-id <KMS-ARN> --plaintext 
'MyC0mplIc@tedProtect1oN'
{
    "KeyId": "KMS-ARN", 
    "CiphertextBlob": 
"AQICAHgcQFAGtz/hvaxMtJvY/x/rfHnKI3clFPpSXUU7HQRnCAFwfXhXH
JAHL8tcVmDqurALAAAAajBoBgkqhki
G9w0BBwagWzBZAgEAMFQGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM45
AIkTqjSekX2mniAgEQgCcOav6Hhol
+wxpWKtXY4y1Z1d0z1P4fx0jTdosfCbPnUExmNJ4zdx8="
}
$

The value of “CiphertextBlob” is the encrypted password. Use this password as the value of the NGFWv Password (threat defense virtual password) or the FMC Password for AutoScale Automation (management center password) parameter in the infrastructure_gwlb.yaml file. You can also use this password as the value of the FMC Password for Publishing Metrics to CloudWatch.

Create Target Folder

On the local host, use the command given below to create a target folder containing the files that have to be uploaded to the Amazon S3 bucket.

python3 make.py build

This creates a folder named ‘target’ on your local host. The target folder contains the zip files and yaml files required for deployment of the auto scale solution.

Upload Files to Amazon S3 Bucket

On the local host, use the commands given below to upload all the files in the target directory to the Amazon S3 bucket.

$ cd ./target

$ aws s3 cp . s3://<bucket-name> --recursive

Auto Scale Solution with NLB - Deploy the Auto Scale Solution with NLB

Perform the steps given in this section if you are deploying the auto scale solution with NLB.

Procedure

Step 1

On the AWS Management console, go to Services > Management and Governance > CloudFormation > Stacks, and click the stack that was created by the template.

Step 2

Click Create stack > With new resources(standard).

Step 3

Select Upload a template file, click Choose File, and select deploy_ngfw_autoscale.yaml from the target folder.

Step 4

Click Next.

Step 5

On the Specify stack details page, enter a name for the stack.

Step 6

Provide values for the input parameters in the deploy_ngfw_autoscale.yaml template.

Step 7

Click Next on the Configure Stack Options window.

Step 8

On the Review page, review and confirm the settings.

Step 9

Click Create Stack to deploy the deploy_ngfw_autoscale.yaml template and create the stack.

This completes deployment of both the templates that are required to set up the auto scale solution for threat defense virtual with NLB.

Auto Scale Solution with GWLB - Deploy the Auto Scale Solution with GWLB

Perform the steps given in this section if you are deploying the auto scale solution with GWLB.

Procedure

Step 1

On the AWS Management console, go to Services > Management and Governance > CloudFormation > Stacks, and click the stack that was created by the template.

Step 2

Click Create stack > With new resources(standard).

Step 3

Select Upload a template file, click Choose File, and select deploy_ngfw_autoscale_with_gwlb.yaml from the target folder.

Step 4

Click Next.

Step 5

On the Specify stack details page, enter a name for the stack.

Step 6

Provide values for the input parameters in the deploy_ngfw_autoscale_with_gwlb.yaml template.

Step 7

Click Next on the Configure Stack Options window.

Step 8

On the Review page, review and confirm the settings.

Step 9

Click Create Stack to deploy the deploy_ngfw_autoscale_with_gwlb.yaml template and create the stack.

This completes deployment of both the templates that are required to set up the auto scale solution for threat defense virtual using GWLB.

AWS Security Group Changes

  1. Allow eipNat created by Infrastructure Stack to FMC Security Group (If using FMC Public IP address).

  2. Allow FMC IP to FTD Instance Security Group (If using public FTD IP address).

Auto Scale with GWLB solution - Create the GWLB Endpoint

Perform the steps given in this section if you are deploying the auto scale solution using GWLB.

Procedure

Step 1

On the AWS Management console, go to Services > Networking & Content Delivery > VPC > Endpoint Services.

Step 2

Click Create Endpoint Service

Step 3

Under Load balancer type, choose Gateway.

Step 4

Under Available load balancers, choose the Gateway Load balancer that was created as part of the Auto scale deployment.

Step 5

Under Require acceptance for endpoint, choose Acceptance required. This ensures that you have to manually accept any endpoint service connection requests.

Step 6

Under Supported IP address types, choose IPv4.

Step 7

Click Create.

Step 8

Copy the Service name of the newly created endpoint service.

Step 9

Go to Services > Networking & Content Delivery > VPC > Endpoints.

Step 10

Click Create endpoint.

Step 11

Under Service category, choose Other endpoint services.

Step 12

For Service name, enter the name of the service, and then choose Verify service.

Step 13

In the VPC field, select the VPC in which to create the endpoint.

Step 14

Under Subnets, select the subnet in which to create the endpoint.

Step 15

For IP address type, choose the IPv4 option to assign IPv4 addresses to the endpoint network interfaces.

Step 16

Click Create endpoint.

Configure Routing for VPC

Procedure

Step 1

On the AWS Management console, go to Services > Networking & Content > Virtual Private Cloud > Route tables.

Step 2

Select the route table for the internet gateway and perform the following steps:

  1. Click Actions > Edit routes.

  2. For IPv4, click Add route. For Destination, enter the IPv4 CIDR block of the subnet for the application servers. For Target, select the VPC endpoint.

  3. Click Save changes.

Step 3

Select the route table for the subnet with the application servers and perform the following steps:

  1. Click Actions > Edit routes.

  2. For IPv4, click Add route. For Destination, enter 0.0.0.0/0. For Target, select the VPC endpoint.

  3. Click Save changes.

Step 4

Select the route table for the subnet with the Gateway Load Balancer endpoint, and perform the following steps:

  1. Click Actions > Edit routes.

  2. For IPv4, click Add route. For Destination, enter 0.0.0.0/0. For Target, select the internet gateway.

  3. Click Save changes.

Edit the Auto Scale Group

By default, the Auto Scale group has the minimum and maximum number of threat defense virtual instances set to 0 and 2 respectively. Change these values as per your requirement.

Procedure

Step 1

On the AWS Management console, go to Services > Compute > EC2, and click Auto Scaling Groups.

Step 2

Select the auto scaling group created by you and click Edit to modify the values in the Desired capacity, Minimum capacity, Maximum capacity fields as per your requirement. These values correspond to the number of threat defense virtual instances that you want to bring up for the auto scaling functionality. Set the Desired capacity to a value that is within the minimum and maximum capacity values.

Step 3

Click Update.


Note

We recommend that you launch only one threat defense virtual instance and verify that the behaviour of this instance is as expected. You can then launch more instances as per your requirement.

Validate Deployment

Once the template deployment is successful, go to the Amazon CloudWatch console to ensure that logs are being collected and the required alarms have been created.

Logs

Check the log files to troubleshoot any issues with management center connectivity.

Procedure

Step 1

On the AWS Management console, go to Services > Management & Governance > CloudWatch.

Step 2

Click Log groups and click any log group displayed here to view the logs.

Alarms

Ensure that the required alarms have been created on the Amazon CloudWatch console.

Procedure

Step 1

On the AWS Management console, go to Services > Management & Governance > CloudWatch.

Step 2

Click Alarms > All Alarms to display the list of alarms along with the conditions which will trigger the scale-out and scale-in functions.

Maintenance Tasks

Scaling Processes

This topic explains how to suspend and then resume one or more of the scaling processes for your Auto Scale group.

Start and Stop Scale Actions

To start and stop scale out/in actions, follow these steps.

Health Monitor

Every 60 minutes, a CloudWatch Cron job triggers the Auto Scale Manager Lambda for the Health Doctor module:

  • If there are unhealthy IPs which belong to a valid Firewall Threat Defense Virtual VM, that instance gets deleted if the Firewall Threat Defense Virtual is more than an hour old.

  • If those IPs are not from a valid Firewall Threat Defense Virtual machine, then only IPs are removed from the Target Group.

The health monitor also validates the Firewall Management Center configuration for device group, access policy, and NAT rules. In case of an unhealthy IP/instance, or if the Firewall Management Center validation fails, the health monitor sends an email to the user.

Disable Health Monitor

To disable a health monitor, in constant.py make the constant as “True”.

Enable Health Monitor

To enable a health monitor, in constant.py make the constant as “False”.

Disable Lifecycle Hooks

In the unlikely event that Lifecycle hook needs to be disabled, if disabled it won’t add additional interfaces to Instances. It can also cause a series of failed deployment of the Firewall Threat Defense Virtual instances.

Disable Auto Scale Manager

To disable Auto Scale Manager, respective CloudWatch Events “notify-instance-launch” and “notify-instance-terminate” should be disabled. Disabling this won’t trigger Lambda for any new events. But already executing Lambda actions will continue. There is no abrupt stop of Auto Scale Manager. Trying abrupt stopping by stack deletion or deleting resources can cause an indefinite state.

Load Balancer Targets

Because the AWS Load Balancer does not allow instance-type targets for instances having more than one network interface, the Gigabit0/1 interface IP is configured as a target on Target Groups. As of now however, the AWS Auto Scale health checks work only for instance-type targets, not IPs. Also, these IPs are not automatically added or removed from target groups. Hence our Auto Scale solution programmatically handles both of these tasks. But in the case of maintenance or troubleshooting, there could be a situation demanding manual effort to do so.

Register a Target to a Target Group

To register the Firewall Threat Defense Virtual instance to the Load Balancer, its Gigabit0/1 instance IP (outside subnet) should be added as a target in Target Group(s). See Register or Deregister Targets by IP Address.

Deregister a Target from a Target Group

To deregister the Firewall Threat Defense Virtual instance to the Load Balancer, its Gigabit0/1 instance IP (outside subnet) should be deleted as a target in Target Group(s). See Register or Deregister Targets by IP Address.

Instance Stand-by

AWS does not allow instance reboot in the Auto Scale group, but it does allow a user to put an instance in Stand-by and perform such actions. However, this works best when the Load Balancer targets are instance-type. However, the Firewall Threat Defense Virtual machines cannot be configured as instance-type targets, because of multiple network interfaces.

Put an Instance in Stand-by

If an instance is put into stand-by, its IP in Target Groups will still continue to be in the same state until the health probes fail. Because of this, it is recommended to deregister respective IPs from the Target Group before putting the instance into stand-by state; see Load Balancer Targets for more information.

Once the IPs are removed, see Temporarily Removing Instances from Your Auto Scaling Group.

Remove an Instance from Stand-by

Similarly you can move an instance from stand-by to running state. After removal from stand-by state, the instance's IP should be registered to Target Group targets. See Load Balancer Targets.

For more information about how to put instances into stand-by state for troubleshooting or maintenance, see the AWS News Blog.

Remove/Detach Instance from Auto Scale Group

To remove an instance from the Auto Scale group, first it should be moved to stand-by state. See "Put Instances on Stand-by". Once the instance is in the stand-by state it can be removed or detached. See Detach EC2 Instances from Your Auto Scaling Group.

There won’t be any changes on the Firewall Management Center side. Any changes required should be performed manually.

Terminate an Instance

To terminate an instance it should be put into stand-by state; see Instance Stand-by. Once the instance is in stand-by, you can proceed to terminate.

Instance Scale-In Protection

To avoid an accidental removal of any particular instance from the Auto Scale group, it can be made as Scale-In protected. If an instance is Scale-In protected, it won’t be terminated due to a Scale-In event.

Please refer to the following link to put an instance into Scale-In protected state.

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html


Important

It is recommended to make the minimum number of instances which are healthy (the target IP should be healthy, not just the EC2 instance) as Scale-In protected.

Changes to Configuration

Any changes in configuration won’t be automatically reflected on already running instances. Changes will be reflected on upcoming devices only. Any such changes should be manually pushed to already existing devices.

If you are facing issues while manually updating the configuration on existing instances, we recommend removing these instances from the Scaling Group and replacing them with new instances.

Change the Firewall Management Center User Name and Password

In the case of changes to the Firewall Management Center IP, username, or password—the respective changes should be performed on Auto Scale Manager Lambda function and custom metric publisher Lambda function environment variables. See Using AWS Lambda Environment Variables.

When Lambda runs next time, it will reference the changed environment variables.


Note

Environment variables are directly fed to Lambda functions. There is no password complexity check here.

Change the Firewall Threat Defense Virtual Admin Password

A change to the Firewall Threat Defense Virtual password requires the user to change it on each device manually for running instances. For new Firewall Threat Defense Virtual devices to be onboarded, the Firewall Threat Defense Virtual password will be taken from the Lambda environment variables. See Using AWS Lambda Environment Variables.

Change Registration and NAT IDs

For new Firewall Threat Defense Virtual devices to be onboarded with different registration and NAT IDs, for the Firewall Management Center registration this information should be changed in Configuration.json file. The Configuration.json file can be located in Lambda resource page.

Changes to Access Policy and NAT Policy

Any changes to Access policies or NAT policies are automatically applied to upcoming instances with the help of the Device Group assignment. However, to update existing Firewall Threat Defense Virtual instances you need to manually push configuration changes and deploy them from the Firewall Management Center.

Changes to AWS Resources

You can change many things in AWS post deployment, such as the Auto Scale Group, Launch Configuration, CloudWatch events, Scaling Policies etc. You can import your resources into a CloudFormation stack or create a new stack from your existing resources.

See Bringing Existing Resources Into CloudFormation Management for more information about how to manage changes performed on AWS resources.

Configure IMDSv2 Required Mode for Existing Autoscale Group Instances

You can configure the IMDSv2 Required mode for the Firewall Threat Defense Virtual autoscale group instances that are already deployed on the AWS.

Before you begin

The IMDSv2 Required mode is only supported in Firewall Threat Defense Virtual Version 7.6 and later. Ensure that your existing instances' version is compatible (upgraded to Version 7.6) with the IMDSv2 mode before configuring the IMDSv2 mode for your deployment.

Procedure

Step 1

Log in to http://aws.amazon.com/.

Step 2

Click EC2 and select Auto Scaling > Auto Scaling Groups.

Step 3

Select the Auto Scaling group from the list to configure the IMDSv2 Required mode for that group's associated instances.

Step 4

Click the Launch Template.

Step 5

On the Launch templates page, choose Modify template (Create new version) from the Actions drop-down list.

Step 6

Update the AMI ID with the IMDSv2-supported image.

Step 7

Under Advanced Details, enable the IMDSv2 metadata:

  1. Choose Enabled from the Metadata accessible drop-down list.

  2. Choose V2 only (token required) from the Metadata version drop-down list.

Step 8

Use this Metadata version of the launch template to deploy the auto scaling group instances with the IMDSv2 Required mode enabled.

Troubleshooting

AWS CloudFormation Console

You can verify the input parameters to your CloudFormation stack in the AWS CloudFormation Console, which allows you to create, monitor, update and delete stacks directly from your web browser.

Navigate to the required stack and check the parameter tab. You can also check inputs to Lambda Functions on the Lambda Functions environment variables tab. The configuration.json file can also be viewed on the Auto Scale Manager Lambda function itself.

To learn more about the AWS CloudFormation console, see the AWS CloudFormation User Guide.

Amazon CloudWatch Logs

You can view logs of individual Lambda functions. AWS Lambda automatically monitors Lambda functions on your behalf, reporting metrics through Amazon CloudWatch. To help you troubleshoot failures in a function, Lambda logs all requests handled by your function and also automatically stores logs generated by your code through Amazon CloudWatch Logs.

You can view logs for Lambda by using the Lambda console, the CloudWatch console, the AWS CLI, or the CloudWatch API. To learn more about log groups and accessing them through the CloudWatch console, see the Monitoring system, application, and custom log files in the Amazon CloudWatch User Guide.

Load Balancer Health Check Failure

The load balancer health check contains information such as the protocol, ping port, ping path, response timeout, and health check interval. An instance is considered healthy if it returns a 200 response code within the health check interval.

If the current state of some or all your instances is OutOfService and the description field displays the message that the Instance has failed at least the Unhealthy Threshold number of health checks consecutively, the instances have failed the load balancer health check.

You should check the health probe NAT rule in the Firewall Management Center configuration. For more information, see Troubleshoot a Classic Load Balancer: Health checks.

Traffic Issues

To troubleshoot traffic issues with your Firewall Threat Defense Virtual instances, you should check the Load Balancer rules, the NAT rules, and the static routes configured in the Firewall Threat Defense Virtual instances.

You should also check the AWS virtual network/subnets/gateway details provided in the deployment template, including security group rules, etc. You can also refer to AWS documentation, for example, Troubleshooting EC2 instances.

Connection to the Firewall Management Center Failed

If the management connection is disrupted, you should check the configuration and credentials. See "Requirements and Prerequisites for Device Management" in Secure Firewall Management Center Configuration Guide.

Device Failed to Register with the Firewall Management Center

If the device fails to register with the Firewall Management Center fails, you need to determine if the Firewall Management Center configuration is faulty/unreachable, or if the Firewall Management Center has the capacity to accommodate a new device. See "Add a Device to the Management Center " in Secure Firewall Management Center Configuration Guide.

Unable to SSH into the Firewall Threat Defense Virtual

If you are unable to SSH into the Firewall Threat Defense Virtual, check to see if the complex password was passed to the Firewall Threat Defense Virtual via the template.

Troubleshooting Dual-arm Proxy Configuration

Firewall Threat Defense Virtual EC2 instances fail to launch or go into a continuous launch-terminate loop.

You must verify the activity history: go to Autoscale Group > Autoscale Group > Activity > Activity History to start debugging.

A possible cause may include missing AMI and error in the Lambda function execution.

  • Ensure the AMI is present in AWS Account.

  • Check Connection, Configuration, and Licensing.

  • Check the Tags associated with the Firewall Threat Defense Virtual EC2 instances to get the device’s connection status, configuration status, licensing status and other statuses.

  • Check CloudWatch Logs

    • Logs of individual Lambda functions can be viewed in CloudWatch Logs.

    • If there are issues connecting or configuring the device, proceed to CloudWatch Logs of Lambda functions to understand the root cause.

    • Verify the log groups for Lambda functions.

AWS Cloud-Side Debugging: Traffic Not Passing

  • Check routing tables of all AWS subnets are as specified in the topology diagram. Ensure Egress (East-West traffic routes are present on devices.

  • Ensure AWS Security Groups associated with all device interfaces allow the expected IP address ranges.