Firewall Threat Defense Virtual Integration with AWS Cloud WAN Using Service Insertion

This document describes the integration of Threat Defense Virtual with AWS Cloud WAN using service insertion.

AWS Cloud WAN Service Insertion

AWS Cloud WAN is a global service that can be used to build, manage, and monitor wide area networks (WAN) using a centralized dashboard.

Starting with Release 10.0.0, Threat Defense Virtual supports AWS Cloud WAN service insertion. Service insertion is a capability that allows users to add AWS and third-party networking and security services on Cloud WAN using a central core network policy.

AWS service insertion feature simplifies the integration of security and inspection services into global networks based on Cloud WAN. Using a central Cloud WAN policy or the AWS management console, you can route network traffic between Amazon VPCs (Virtual Private Cloud), AWS Regions, on-premises locations, and the internet through threat inspection appliances.

Threat Defense Virtual is integrated into AWS Cloud WAN to protect intra-segment, inter-segment, and North-South (ingress and egress) traffic. Threat Defense Virtual instances will reside in a separate security VPC along with other AWS components required to steer traffic. The security VPC includes an additional subnet for connecting to the core network. It also contains Management, Inside and Outside subnets.

Prerequisites

  • Make sure that the Management Center is installed with version 7.6.0 or later. You must assign a public IP address and register the system with a Smart License, or make sure that evaluation mode is enabled.

  • Make sure that you have deployed the AWS Cloud WAN Core Network with workload segments and attached a security Network Function Group (NFG) to the core network. Specify a policy that includes segment actions (such as send–via or send–to) to steer traffic to the security VPC.

You can use service insertion to define the traffic flow between segments or the Network Function Group.

  • North-South traffic flows:

    • Send ingress or egress traffic from the segment virtual1production to virtualNFG1 for inspection.

    • Send ingress or egress traffic from the segment virtual1development to virtualNFG1 for inspection.

  • East–West traffic flows:

    Send traffic between the segments virtual1production and virtual1development through a Network Firewall gateway virtualNFG1 for traffic inspection.


Note

The segment names given here are examples only.

Licensing

BYOL (Bring Your Own License) and PAYG (Pay-As-You-Go) licenses are supported.

Use Cases

East–West (Segment–to–Segment) use case

This use case involves connecting the security VPC to the Core Network, which contains multiple workload segments. This enables east-west traffic inspection using AWS Gateway Load Balancer (GWLB) and Threat Defense Virtual within the Core Network.

Traffic from the Core Network is routed to the GWLB endpoint in the security VPC. The GWLB forwards the traffic to the Threat Defense Virtual for inspection. After inspection, the traffic exits through the egress interface of the Threat Defense Virtual and returns to the GWLB. The inspected and processed traffic is sent back to the Core Network attachment.

Egress (Segment–to–Internet) use case

This use case involves Security VPC packet flow for outbound traffic to the internet.

Traffic from the Core Network is routed to the GWLB endpoint in the security VPC. The GWLB endpoint forwards the traffic to the GWLB, which distributes the traffic across multiple Threat Defense Virtual instances. The GWLB sends the traffic to the ingress interface of the Threat Defense Virtual, which performs Source Network Address Translation (SNAT). During this process, the original source IP address is replaced with either the public IP address or the interface IP address of the Threat Defense Virtual. SNAT is required to handle the return traffic from the internet. The Threat Defense Virtual handles return traffic by reversing the NAT process. The response is routed back to the GWLB and GWLB endpoint, and then returned to the Core Network.

Ingress (Internet–to–Segment) use case

This use case handles the security VPC packet flow for inbound traffic from the internet. An External Load Balancer is used for the Threat Defense Virtual and outside interface.

Incoming internet traffic is directed to the public IP address of an External Load Balancer (ELB). The ELB distributes this traffic to the Threat Defense Virtual instances. Each Threat Defense Virtual instance inspects the traffic and applies Destination Network Address Translation (DNAT) to translate the public IP address to the internal private IP address of the destination, and Source Network Address Translation (SNAT) to modify the source IP address, ensuring the response traffic is correctly routed back. After inspection, the Threat Defense Virtual forwards the traffic to the internal subnet, which routes it to the Core Network attachment.

AWS Cloud WAN Solution Deployment Flow

  1. Deploy AWS Cloud WAN Core Network, attach segments, and configure policy.

  2. Deploy Management Center using a public IP address.

  3. Deploy Security VPC and Threat Defense Virtual using Terraform.

  4. Attach Security VPC to Core Network and set up routing, Network Address Translation (NAT), and health checks.


Note

  • Step 1 and step 2 procedures are not explicitly mentioned in the document and should be done by the user.

    For step 1, see the AWS documentation for the detailed procedure - https://docs.aws.amazon.com/network-manager/latest/cloudwan/cloudwan-getting-started.html

    For Step 2, see the chapter Deploy the Management Center Virtual on AWS, in Cisco Secure Firewall Management Center Virtual Getting Started Guide.

  • Use Terraform-based deployment procedure to complete Step 3.

  • Complete Step 4 manually after the deployment is successful.

AWS Cloud WAN Deployment Using Terraform Scripts

This section describes how to deploy the Security VPC and its associated components using Terraform. The deployment includes the setup of the Gateway Load Balancer, internet-facing Elastic Load Balancer, Threat Defense Virtual instances, and their integration with the Management Center.

  1. Deploy the Security VPC that includes a Gateway Load Balancer (GWLB), an internet-facing Elastic Load Balancer (ELB), multiple Threat Defense Virtual instances operating in dual-arm mode, and supporting infrastructure components..

  2. Register the Inside interfaces of Threat Defense Virtual instances to the GWLB's target group, and Outside interfaces to ELB's target group.

  3. Register the Threat Defense Virtual instances to Management Center and configure the required interfaces and static routes.


    Note

    You can also deploy the Security VPC, Threat Defense Virtual, and related resources manually. It is not mandatory to use Terraform.

Parameters for Terraform-based Deployment

Set the variable values in terraform.tfvars file before using Terraform deployment scripts.

Table 1. Cloud-WAN repository structure

Folder

File Name

Description

CLOUD-WAN/cloud-wan

terraform.tfvars

Terraform variables input file for user to specify networking details, credentials and so on.

CLOUD-WAN/cloud-wan

main.tf

Terraform template for deploying the security components.

CLOUD-WAN/cloud-wan

outputs.tf

Output variables generated during the deployment.

CLOUD-WAN/cloud-wan/modules

cloudwan, firewall_instance, fmc_config, gwlb, gwlbe, load_balancer, nat_gw, network

Local terraform modules used by the template.
Table 2. List of input variables (terraform.tfvars)

Input Variables

Description

Example

service_vpc_cidr

 IP address range of the Security VPC.

10.0.0.0/16

service_vpc_name

 The name of the Security VPC. cisco-ftd-vpc
keyname Key name of the Security VPC.

instances_per_az

 Number of Threat Defense Virtual instances to be deployed per Availability Zone. 2

availability_zone_count

 Number of Availability Zones to deploy on Threat Defense Virtual. 2
prefix Prefix to name all security resources. cisco-cwan

use_ftd_eip

 Define if a public Elastic IP address is required for the management interface. true

gwlb_name

 The name of the GWLB.

reg_key

 Registration key for Management Center registration. cisco

ftd_admin_password

 Admin password of Threat Defense Virtual. C15co@!23

fmc_mgmt_ip, fmc_username, fmc_password

 Credentials for Terraform script to access Management Center.

54.23.58.100, admin, C15co@!23

ftd_version, ftd_size

 Threat Defense Virtual version (7.6.0+) and Instance size.

10.0.0-1045, c5.xlarge

Performance_tier

 Threat Defense Virtual performance tier. FTDv50
byol Licensing type – BYOL or PAYG. true

Deploy Threat Defense Virtual Security VPC Using Terraform

Procedure

Step 1

Clone the Cloud WAN repository to your local machine.

Use the command git clone https://github.com/CiscoDevNet/secure-firewall.git.

Step 2

Navigate to Cloud WAN directory.

Use the command cd secure-firewall/FTD/AWS/Terraform/Cloud_WAN.

Step 3

Set values for the variables in the input file terraform.tfvars as per your requirements.

Specify region and credentials for your AWS account. See Table2: List of input variables (terraform.tfvars).

Step 4

Use the following CLI commands to deploy the security solution using Terraform.

$ terraform init 
$ terraform apply

Step 5

Type Yes to proceed. AWS resources will begin to deploy.

Step 6

Navigate to the newly created file FTD_Mgmt_Public_Ips in your local machine.

This contains Management Public IP addresses of the deployed Threat Defence Virtual instances.

Step 7

On the AWS console, navigate to the Management Center security group, EC2 > Network & Security > Security Groups.

Add inbound rules to this security group to allow traffic from the IP addresses listed in the FTD_Mgmt_Public_Ips file. This is required for the Threat Defence Virtual instances to successfully register with the Management Center.

Step 8

Wait until the deployment of AWS resources and the configuration of the Management Center is completed.

Post-deployment Checks

Once the deployment is completed, check the following:

  • All Threat Defense Virtual instances are powered on and operational, registered to Management Center, and have an associated Access Policy.

  • The Management, Diagnostic, Inside, Outside, and Virtual Network Identifier (proxy dual-arm) interfaces are configured and assigned to their respective Security Zones.

  • Static routes for interfaces Inside, Outside, and Virtual Network Identifier are configured.

  • NAT Rule is configured for egress traffic.

Check the following on AWS:

  • Threat Defense Virtual is deployed.

    In the AWS console, navigate to EC2 > Instances.

    Click the Instance ID and verify the details.

  • GWLB, ELB, and associated Target Groups are deployed using Terraform.

    In the AWS console, navigate to EC2 > Load Balancers. Verify the associated load balancers. Navigate to EC2 > Target Groups. Verify the associated target groups.

  • Route Tables are deployed using Terraform. In the AWS console, navigate to VPC Dashboard > Virtual private cloud > Route tables. Verify the route tables and subnet associations.

Check the following in Management Center:

  • Threat Defense Virtual interfaces are configured in Management Center. In the Management Center console, go to the Devices tab and select the registered device. Click on the Interfaces tab and check that the interfaces are configured properly.

  • Static Routing is configured on Virtual Network Identifier, Inside, and Outside interfaces. In the management Center console, go to the Devices tab and select the registered device. Navigate to the Routing tab and click on Static Route and verify the configurations.

  • NAT rule is configured for Virtual Network Identifier and Outside interfaces for egress traffic. In the Management Center console, click on Policies and select NAT. In the NAT Policies list, locate and click on the policy name that is used during deployment. Confirm that the egress NAT rule is correctly configured.

AWS Cloud WAN Post-deployment Configuration

Procedure

Step 1

Create platform settings using Management Center.

  1. Log in to the Management Center.

  2. Navigate to Devices > Platform Settings > New Policy > Threat Defense Settings.

  3. Provide the policy name.

  4. Select the device group from the Targeted Devices drop-down list.

  5. Click Add to Policy and Save.

  6. Click on the newly created policy and select HTTP Access.

  7. Enable the HTTP server on port 443 for the Threat Defense Virtual Inside interface to respond to GWLB health checks and Outside interface to respond to ELB health checks.

  8. Click Add.

  9. Select any from the IP Address drop-down list.

  10. select the Outside-sz, from the Available Zones/Interfaces window.

  11. Click Add to move the interface to the Selected Zones/Interfaces window.

  12. Click OK.

  13. Click Save.

Step 2

Verify that all targets in GWLB and ELB target groups are healthy in the AWS console.

Log in to the Management Center.

Navigate to Devices and select the Threat Defense Virtual instance. Provide the policy name. In the device's settings menu, go to the HTTP Access tab. Ensure Enable HTTP Server is checked. Set the port and define the interfaces and the network. Click Save to apply the settings.

Step 3

Attach Security VPC to Core Network.

On the AWS console, navigate to your VPC > Network Manager > Global Networks. Select your Core Network. Click Attachments. Click Create attachment. Choose VPC as the attachment type. Select the Security VPC you created earlier. Enable the check-box for Appliance mode support. Create appropriate tag to map the Network Function Group (NFG) of the Core Network to this VPC.

Step 4

Set up routing between the Security VPC and the Core Network.

On the AWS console, go to VPC dashboard and select VPC. Click Route tables.

Identify the route tables associated with GWLB-E subnet and Inside subnet. For each route table: Click the Routes tab. Click Edit routes > Add route (0.0.0.0/0 > core-network-attachment). In the Target field: Choose Core Network Attachment from the drop-down. It will appear as core-network-attachment-xxxxxxxx. Click Save changes.

Step 5

For incoming traffic, configure a NAT rule in Management Center to route it to applications in workload segments.

Log in to Management Center. Click Devices. Under the Devices tab, select the Threat Defense Virtual for which you want to view or verify the NAT policy. On the device configuration window, go to NAT under the Policies section. Open the relevant NAT Policy.

You will see the Rules tab, where NAT rules are listed. Verify the rules for Ingress traffic.

AWS Cloud WAN Upgrade

You can upgrade the Threat Defense Virtual instances deployed in an AWS Cloud WAN environment using one of the following methods:

  1. Upgrading from Management Center.

    Perform a standard software upgrade of the existing Threat Defense Virtual instances directly from the Management Center.

  2. Upgrade using Terraform.

    Update the ftd_version parameter in the terraform.tfvars file with the required Threat Defense Virtual image version and use the following commands: 

    $ terraform destroy -target module.fmc_configuration 
$ terraform apply

    Warning

    This procedure will replace the existing Threat Defense Virtual instances with a newer version.

Troubleshooting

If traffic is not working as expected, check these items:

  • Make sure that the segments and NFG are attached to the Core Network.

  • Make sure that the segment actions (send-to or send-via) are defined correctly in the policy.

  • Verify that the interfaces are registered to their respective Load Balancers and they are in a healthy state. Check ELB Target group for ingress traffic. Check GWLB Target group for egress and East-West traffic.

  • Make sure that routing is set up correctly for all subnets.

  • Make sure that the NAT is configured properly for both egress and ingress traffic.