The Multicloud Defense Gateway and Service VPCs or VNets

Multicloud Defense Gateway is a network-based security platform comprising of a network load balancer with a cluster of Multicloud Defense Gateway instances. It is an auto-scaling and self-healing cluster that scales out or in depending on the traffic load. Multicloud Defense Controller and gateway instances exchange constant and continuous information about the state, health and telemetry. The Multicloud Defense Controller makes the decision to scale out or in by measuring the telemetry data received from the gateway instances. The gateways can be configured to run in multiple availability zones for a highly available, resilient architecture. This ensures that a single availability zone's failure from a cloud service provider does not compromise the security posture for running applications.


Note

If the Multicloud Defense Gateway loses connectivity to the Multicloud Defense Controller for any reason, the Multicloud Defense Gateway will continue to function with existing policies.

Once you have configured a gateway and any corresponding VPCs or VNets, you can use the Gateway Details page in the Multicloud Defense Controller to view and manage the state of them.

Gateway Details

To view the Gateway Details page for already established gateways are available in Infrastructure > Gateways > Gateways. You can add and manage all gateways from this page. Managing a gateway allows you to edit, upgrade, enable, disable, export, or delete the instance. You must click the checkbox of the gateway you want to modify prior to making any changes.

Click Switch to Advanced Search to construct your own search. Use the drop-down option within the search bar to utilize some of the auto-generated search criteria if needed. For searches that have to repeated, you can copy or even save searches for future use.

Gateway Actions

The following gateway actions occur in the background and do not need any additional tasks or items from you:

Gateway Retry

The Multicloud Defense Gateway is a self-healing component Multicloud Defense. If at any point the deployment of your gateway fails or experiences issues, Multicloud Defense automatically attempts to redeploy the gateway with the gateway retry. This action happens infinitely until you manually disable or delete the gateway from the controller.

You can configure the retry action in Terraform in two aspects: first, you can configure how many times Multicloud Defense retries to deploy the gateway. After the maximum number of attempts to redeploy are complete, Multicloud Defense stops retrying. Second, you can configure the time between retry attempts. As an example, you can configure three gateway retry attempts every hour. This means that every hour, Multicloud Defense retries to deploy the gateway three times and then stops. This action repeats until the gateway issues resolve or if you delete the gateway from the controller.

Tunnel Inspection in your Gateway

The Multicloud Defense Gateway automates GRE tunnel inspection by encapsulating the original packet by adding a new GRE header and an outer IP header. The encapsulated packet is then transmitted over the intermediate network and when the encapsulated packet reaches the destination endpoint of the GRE tunnel, the GRE header and the outer IP header are removed, revealing the original packet. The original packet is then forwarded to its final destination.

While GRE itself does not provide encryption, it can be combined with other protocols like IPsec (Internet Protocol Security) to secure the encapsulated traffic. IPsec can provide confidentiality, integrity, and authentication for the GRE tunnel. This is particularly useful for site-to-site VPN tunnel connections and can be used in conjunction with routing protocols to provide redundancy and failover capabilities.

Supported Gateway Use Cases

Firewall Threat Defense Virtual

Cisco Secure Firewall Threat Defense virtual (FTDv) brings next generation firewall functionality to virtualized environments, enabling consistent security policies to follow workloads across your physical, virtual, and cloud environments.

You can provision a tenant on Security Cloud Control to onboard and manage your Firewall Threat Defense virtual device and navigate between Multicloud Defense and Cloud-Delivered Firewall Management Center.

Guidelines

By deploying Firewall Threat Defense virtual (FTDv) gateway using Multicloud Defense, you gain advanced network security and management features that are not available in standard Internet Service Provider gateways. You can also protect your network when you deploy an FTDv gateway using Multicloud Defense.

Because this is a multi-product task, you must navigate between both Multicloud Defense and Cloud-Delivered Firewall Management Center to complete the steps. Multicloud Defense deploys and registers the FTDv device including interfaces, gateway configuration, NAT rules, platform settings, whereas you edit your access policy, rules, and objects in your Cloud-Delivered Firewall Management Center account.

Use these guidelines when you create an FTDv that is managed by Cloud-Delivered Firewall Management Center:

  • When you create a Service VPC and apply a gateway to your FTDv environment, Multicloud Defense automatically creates a subnet and a corresponding security group for the secondary interface.

  • Based on your needs, deploy an ideal number of FTDv gateways in the Cloud-Delivered Firewall Management Center tier within a tenant, for optimal efficiency. During upgrades, additional capacity is temporarily required to bring up new instances before the older instances can be decommissioned.

  • For Azure deployments, the default SSH username for FTDv is "centos", and access is authenticated using the SSH key that was provisioned during the gateway deployment.

    Alternatively, you can use Azure Serial Console to log in to FTDv using the "admin" username and the password provided to you during gateway deployment.

  • In AWS, for East–West traffic inspection, in the Access Control policy, use "VNI" for both the source security zone and destination security zone. Because this is U-turn traffic, the source and destination security zones are the same.

  • In AWS, for egress traffic, in the Access Control policy configure the "VNI" zone as the source security zone and the “Outside” zone as the destination security zone.

  • In Azure, for East-West traffic inspection, in the Access Control policy configure the "Inside" zone as the source security zone and destination security zone. Because this is U-turn traffic, the source and the destination security zone are the same.

  • In Azure, for egress traffic, in the Access Control policy configure the "Inside" zone as the source security zone and the "Outside" zone as the destination security zone.

Prerequisites

  • You must provision a tenant on Security Cloud Control. For more information, refer to Create a Security Cloud Control Tenant.

  • You must have an active Cloud-Delivered Firewall Management Center account.

  • You must have an active Multicloud Defense account.

Limitations

Review these limitations when you create an FTDv gateway that is managed by Cloud-Delivered Firewall Management Center.

  • You cannot deploy FTDv gateways in cluster mode.

  • VPN (Site-to-site and Remote Access) are not supported.

  • Only the centralized model is supported.

  • Only East-West/Egress gateway types are supported.

  • You must create a new Service VPC. VPCs created before this feature was introduced do not support this functionality. New VPCs support both Multicloud Defense gateways and FTDv gateways.

  • If you want to use Cisco Smart Licensing, then you must purchase a license through your Cisco seller or partner.

  • You must perform software upgrades through the Multicloud Defense dashboard.

  • FTDv configuration changes made to the FTDv gateway must be done through the Multicloud Defense dashboard. You must only edit security policies for the devices deployed, from Multicloud Defense. Do not perform any changes directly in Cloud-Delivered Firewall Management Center. Cloud-Delivered Firewall Management Center must be used only to manage Access Control policies and NAT policies.

  • Changes to the Access Control Policy (such as adding and removing security rules) must be done through Cloud-Delivered Firewall Management Center.

  • At this time, Jumbo frames are not supported.

  • At this time, only AWS and Azure cloud-service providers support gateways affiliated with FTDv gateways.


    Note

    If you have an existing AWS or Azure cloud service provider, or a new AWS cloud service provider account, you must manually accept the Marketplace Terms or Terms of Use.

Create and deploy a Firewall Threat Defense Virtual gateway

Follow this set of procedures to successfully create and deploy the FTDv gateway:

  1. Enable Cloud-delivered Firewall Management Center on Your Security Cloud Control Tenant.

  2. Onboard a CSP.

  3. Create a Service VPC.

  4. Create an FTDv Gateway.

  5. Configure your access policy in Cloud-Delivered Firewall Management Center.

Licensing

The Multicloud Defense Gateway supports both Multicloud Defense licensing and Smart Licensing.

Multicloud Defense licensing is subscription-based access to software delivered via the cloud, with benefits such as ease of access, scalability, and regular updates. Multicloud Defense licensing is typically subscription-based with a recurring fee that often includes maintenance, updates, and support as part of the package. Most Multicloud Defense licensing models offer scalability, enabling your organization to easily adjust the number of users or features based on current needs. Because this licensing model is based in the cloud, you can access the latest features and updates immediately. For more information, refer to the Cisco Multicloud Defense Ordering Guide for more information.

Smart Licensing is more suited for utilizing existing licenses for cost savings in specific deployment scenarios. Opting for a smart license allows your organization to use pre-purchased licenses with their cloud or hybrid deployments, leveraging licenses that are already owned by the organization to be more cost effective. Smart licensing is often used for specific deployment types, such as cloud or hybrid scenarios, allowing organizations to migrate existing workloads without acquiring new licenses.

When creating your gateway for your FTDv you have the opportunity to select one of these two options, depending on your resources.


Note

Once you deploy a gateway with an FTDv device, you cannot change the licensing model. You can change the performance tier of the licensing model you selected. If you change the licensing model, you will need to deploy a new gateway.

The different types of licenses are:

  • Base licensing - Enables basic firewall and networking functionality, such as stateful firewalling, routing and NAT features. This is a standard foundational license that is mandatory for all deployments.

  • Carrier Licensing - Enables the inspection of protocols such as GPRS, M3UA, Stream Control Transmission etc. For more information, refer to Carrier License.

  • Threat Licensing (Threat Protection) - Provides access to Intrusion Prevention System (IPS) features, enabling threat detection and prevention. It also includes signature-based detection for known vulnerabilities and threats.

  • Malware Licensing (Malware Defense) - Enables advanced malware protection through Cisco Advanced Malware Protection (AMP) and includes file trajectory, sandboxing, and retrospective malware detection capabilities.

  • URL Filtering Licensing - Allows URL filtering to control and monitor web traffic and provides access to Cisco’s global threat intelligence for web categorization.

To accompany these license types, there is tiered licensing intended to align performance and throughput that can potentially assist in cost optimization and scalability:

  • FTDv5: Up to 100 Mbps. This is only supported in Azure.

  • FTDv10: Up to 1 gigabit per second (Gbps). This is only supported in Azure.

  • FTDv20: Up to 3 Gbps

  • FTDv30: Up to 5 Gbps

  • FTDv50: Up to 10 Gbps

  • FTDv100: Up to 16 Gbps

Auto-Scaling

Auto-scaling helps ensure that applications have the necessary resources to maintain performance while optimizing cost efficiency.

Note that auto-scaling in FTDv gateways is not the same as auto-scaling in Multicloud Defense Gateway. For more information, refer to Gateway Auto-Scaling in the section Multicloud Defense Gateway Components for native auto-scaling abilities. The information provided here addresses how auto-scaling impacts FTDv gateways.

  • Monitored Metrics - To ensure auto-scaling is performed appropriately and timely for your specific environment, the metrics of system memory, Snort CPU and data plane are monitored.

  • Scale Out - If any of the metrics register above the allowed thresholds, the environment scales up or out to accommodate the load or resources associated with the instances to handle traffic spikes. This triggered event is for the availability zone and not the designated region.


    Note

    Scaling out your environment increases deployment time.

  • Scale In - If any of the metrics register below the allowed thresholds, the environment scales down or in to to ensure efficiency and reduce cost. This triggered event is for the availability zone and not the designated region.

Multicloud Defense Egress Gateways

Egress/East-West

Deploying an Egress/East-West gateway to protect traffic leaving their public cloud networks. The egress gateway functions as a transparent forward proxy, performing full decryption and embedding advanced security features like intrusion prevention, antimalware, data loss prevention, and full-path URL filtering. Optionally, it can also operate in a forwarding mode, where it doesn't proxy or decrypt traffic but still applies security functionalities like malicious IP blocking and FQDN filtering.

The diagram is an example of an AWS account with an egress gateway in a centralized mode:

An AWS egress architecture where multiple application VPCs connect to a central Transit gateway, routes traffic for Internet egress through a dedicated security VPC containing a gateway load balancer and firewalls.

NAT Gateways in Egress


Note

At this time, Multicloud Defense supports native gateways in an egress deployment for AWS and Azure ony.

Network Address Translation (NAT) gateways are gateways designed to originate from within your cloud service provider. Egress traffic appears from a single IP address, or at least one per availability zone. By building a gateway and hosting it from within your cloud environment you can potentially increase efficiency and reduce costs. Note that if the association between the VPC or VNet in Multicloud Defense and the gateway in your cloud service provider fails, Multicloud Defense system logs capture the instance for troubleshooting.

These are the configurations that are supported:

  • Azure supports one subnet.

  • You must have at least one public IP address configured in your NAT gateway.

The diagram is an example of an Azure account with an egress gateway in a centralized mode:

Centralized egress Azure architecture containing two spoke VNets (Production and Development), each with virtual machines that peer into a VNet hub. Within the hub, Egress Gateways in two availability zones route traffic via an Internal Load Balancer to dual NAT Gateways.

AWS CloudWAN

At this time, Multicloud Defense supports the inclusion of AWS' CloudWAN in egress gateways. CloudWAN is an intent-driven managed wide area network (WAN) service that unifies your data center, branch, and AWS networks. While it is possible to create a global network by interconnecting multiple Transit Gateways across regions, CloudWAN offers built-in automation, segmentation, and configuration management features specifically designed for building and operating global networks based on your core network policy.

This option provides enhanced features such as automated VPC attachments, integrated performance monitoring, and centralized configuration, all managed within AWS Network Manager. This enables you to centrally manage and visualize your CloudWAN core network and Transit Gateway networks across AWS accounts, regions, and on-premises locations.

Key Benefits:

  • Simplified Network Management: AWS CloudWAN provides a centralized dashboard through AWS Network Manager for managing network configurations, policies, and monitoring traffic. This greatly reduces the complexity of dealing with multiple, disparate networking solutions and offers a unified view of the network.

  • Scalability: It enables customers to easily scale their network as their business grows. As organizations expand their cloud presence and global footprint, CloudWAN can accommodate the increased demand without requiring significant manual reconfiguration

  • Optimized Performance: By leveraging AWS’s global infrastructure, CloudWAN ensures high performance and low latency connectivity across various geographic locations, improving application performance and user experience.

CloudWAN Simplification:

  • Centralized Policy Management: The core network policy, written in a declarative language, defines segments, AWS region routing, and how attachments should map to segments. With a single network policy, customers can manage their entire network’s routing and security policies, reducing the need for manual configurations and minimizing errors.

  • Automated Operations: CloudWAN automates many network management tasks, such as route propagation and policy enforcement, freeing up IT teams to focus on more strategic initiatives.

  • Seamless Integration: It integrates with other AWS services and third-party solutions, enabling customers to build a cohesive and comprehensive network infrastructure with minimal friction.

  • Enhanced Visualization: AWS Network Manager provides several dashboard visualizations, including world maps pinpointing network resources, monitoring with CloudWatch events, real-time event tracking, and topological diagrams of your network. This makes it easier to manage and monitor all aspects of your global network.

Security service insertion refers to the practice of integrating security services directly into the network path. Here are the benefits of implementing this with Multicloud Defense:

  • Enhanced Security Posture: By inserting security services into the network, traffic can be inspected, monitored, and filtered in real-time, ensuring that threats are detected and mitigated before they can impact critical resources.

  • Consistent Security Policies: Security service insertion ensures that consistent security policies are applied across the entire network, regardless of the underlying infrastructure or geographic location. This uniformity simplifies compliance and governance.

  • Improved Visibility and Control: Integrating security services provides enhanced visibility into network traffic and potential threats. Administrators can leverage advanced analytics and monitoring tools to gain deeper insights and more effectively manage security risks.

  • Reduced Latency and Complexity: By embedding security functions into the network path rather than routing traffic through separate security appliances, latency is minimized, and network complexity is reduced, leading to better performance and simpler network architecture.

  • Flexibility and Scalability: Security service insertion with Multicloud Defense enables organizations to dynamically scale their security measures in response to changing network conditions and emerging threats, ensuring robust protection at all times.

  • Centralized Security: Consolidates security resources, reducing management burden and saving on infrastructure costs.

  • Simplified Routing: Easily steer network traffic to security appliances without complex routing configurations or third-party automation tools.

  • Multi-Region Security Inspection: Simplifies multi-region deployments, allowing intra-region and inter-region traffic to pass through security infrastructure without complex configurations.

By leveraging AWS CloudWAN and Multicloud Defense for security service insertion, customers can achieve a high-performing, secure, and easily manageable network infrastructure that supports their business growth and operational resilience. Multicloud Defense allows users to create a security services VPC, attach it to an existing CloudWAN, create a Network Functions Group (NFG), and secure spoke segments by updating routing—all in an automated manner.

An AWS Cloud WAN Core Network managing global network regions, connecting VPCs and external sites. Another block of Multicloud Defense architecture where regional VPCs route traffic to a Network Function Group within a dedicated Security VPC.

How to Create a Service VPC with AWS CloudWAN

To successfully create a service VPC with AWS CloudWAN, follow these steps:

  • Create Service VPCs: Establish service VPCs in multiple CNEs with required gateways.

  • Create Network Function Groups (NFGs).

  • Attach Service VPCs as NFGs: Use attachment policy rules to attach service VPCs.

  • Attach Workload VPCs: Attach VPCs to respective segments using attachment policy rules.

  • Update Routing: Modify policies and Workload VPCs to update the routing.

  • Update Core Network Policies: Apply and execute the required changes in the Core Network policies.

Consider the following limitations before you create a service VPC with AWS CloudWAN:

  • NAT gateways are mandatory for service VPCs.

  • Dual-Hop and Edge Selection is currently not supported.

  • Due to a limitation in AWS CloudWAN limitation that does not support SNAT-enabled traffic for forwarding, traffic drops for policy rulesets configured with SNAT. We strongly recommend you disable SNAT in your Multicloud Defense policy ruleset.

  • To add an additional service VPCs in different regions (CNE) use one of the two options:

    • Manual execution and application of policies are needed to update the routing for the new NFG attachment.

    • Manually update the routing tables of new service VPC datapath subnets with workload VPC routes through the Core Network.

Multicloud Defense Ingress Gateways

Deploying an Ingress gateway protects our public-facing applications. The Ingress gateway acts as a reverse proxy that carries out full decryption and applies advanced security functionalities such as intrusion prevention, antimalware, web application firewall (WAF), and full-path URL filtering.

The diagram is an example of an AWS account with an ingress gateway in a centralized mode.

Multiple Spoke VPCs and an on-premises data center connects to a Transit Gateway. This gateway routes traffic to a Security VPC, which then uses an NLB to direct traffic.

Multicloud Defense East-West Gateways

An Egress/East-West gateway deployment implements East-West L4 segmentation between subnets or VPCs/VNets within their public cloud environments. The gateway functions in a forwarding mode with L4 firewall rules, allowing or denying traffic based on set parameters, with optional logging enabled.

The diagram shows an example of an AWS account with an east-west gateway in a centralized mode:

Forward proxy/forwarding mode architecture. Multiple Spoke VPCs and a Data Center connect via a Transit Gateway to a central Security VPC where traffic is processed through Gateway Load Balancers and datapath instances and then routed to the Internet.

Multicloud Defense Distributed Gateways

You have applications running in multiple VPC/VNets. Deploy a Multicloud Defense Gateway in each of the VPCs/VNets.

DIstributed firewall with security inside each VPC/VNet

Gateways Deployed in Centralized / Hub Mode

You have applications running in multiple VPCs/VNet. You would like to secure all the applications through a centralized security service VPCs or VNets. This model deploys the Multicloud Defense Gateway in a service VPC. You attach all the application VPCs (Spoke VPCs) and the Service VPC to the AWS Transit Gateway or VNet and VPC peering in Azure and GCP. Multicloud Defense provides an option to orchestrate the AWS Transit Gateway, Service VPC and the Spoke VPC Attachments. This is the recommended solution for ease of deployment, removing the complexity of multiple route tables and Transit Gateway attachments.

Figure 1. AWS - Using AWS Transit Gateway
Centralized security - AWS Transit Gateway
Figure 2. Azure - VNet Peering
Azure VNet Peering
Figure 3. GCP - VPC Peering
GCP-VPC Peering

Advanced Gateway Configuration: Use Your Own Load Balancer

You can use a load balancer that is native to either AWS or Azure when creating a Multicloud Defense Gateway. Because AWS and Azure are different platforms, they do not use the same word for "load balancer" but the functionality mentioned below is identical in performance. Continue reading the appropriate information for the cloud service provider you currently have.

To configure your Multicloud Defense Gateway to use your own load balancer, see Add a Gateway.


Note

Note that both of these configurations support ingress gateway deployments only.

AWS Global Accelerator

Multicloud Defense can integrate with a set of one or more AWS global accelerators to use as an ingress point to load balance traffic across the Multicloud Defense Gateway instances. This is similar to the AWS network load balancer that is created and managed by Multicloud Defense when an ingress gateway is deployed, but offers an alternative ingress point for the ingress gateway to protect applications and workloads.

Accelerator manages the global accelerators' listener endpoint group to ensure the endpoint group has the active set of gateway instances. Client IP addresses are preserved as they pass through the global accelerator to the Multicloud Defense ingress gateway.

In order to integrate Multicloud Defense with a global accelerator, you must first create the global accelerator within AWS, defined a desired listener and created an empty endpoint group (or an endpoint group that contains the existing Multicloud Defense ingress gateway instances). Once the AWS resources exist, then configure the Multicloud Defense ingress gateway to integrate with the global accelerator.

For any additional configuration information, see the Amazon AWS documentation.

Azure Load Balancer

If you have an Azure cloud service provider, you can now use your own load balancer from Azure as part of your Multicloud Defense Gateway. The Azure load balancer funnels and processes traffic from multiple proxy servers to a system-provided backend pool that contains at least one cluster of Multicloud Defense Gateway instances. This scenario is ideal if you want to create a security policy for multiple proxy servers that handle non-HTTP traffic.

You must create a Multicloud Defense Gateway that defers to the Azure load balancer to be able to use this capability. Consider the following prerequisites and limitations:

  • You must have your Azure load balancer already configured.

  • For the load balancer to work, you must enable the floating IP for your load balancer rules.

  • We strongly recommend creating and configuring a backend pool in Azure for your custom load balancer. The backend pool does not have to contain any resources at this time and can be modified later.

  • If you opt to configure your Azure load balancer with a resource group, the Azure resource group and the Multicloud Defense Gateway's resource group must be configured for the same region.

  • If you choose to configure your Azure load balancer with a resource group, note that the load balancer resource group and the Multicloud Defense Gateway resource group do not have to be the same.

  • You can configure a health probe for your Azure load balancer but is not required.

  • The Multicloud Defense Gateway's virtual network and the Azure load balancer's virtual network should be the same.

  • The Multicloud Defense Gateway's datapth subnet and the Azure load balancer's subnet should be the same.

  • You must attach your gateway to a VPC that has at least one availaibilty zone.

For any information on how to create, modify, or complete an Azure load balancer, see Microsoft Azure documentation.

Azure UDP Fragmentation

While it is recommended to avoid fragmentation in general, there may be scenarios where fragmentation does occur and the Azure load balancer drops packets.

To enable support for fragmentation, contact Cisco Support.

Configure Service VPCs and Service VNets

While not strictly mandatory, we do strongly recommend creating and attaching a VPC or VNet to your Multicloud Defense Gateway as part of the deployment process. VPCs and VNets provide the necessary framework to secure, organize, and efficiently manage your network resources while integrating with a firewall gateway.

When you attach a VPC or VNet, you open your network to the following bonuses:

  • Isolation and Security - A VPC/VNet allows you to create a logically isolated network within a cloud provider, ensuring that your resources are segregated from other users. You can also define security rules that control inbound and outbound traffic to and from your resources, using the firewall gateway to enforce these rules, thus controlling access.

  • Customizable Network Architecture - The ability to create subnets within a VPC or VNet and organize and segment your resources, while also managing IP address ranges as well as customizing routing tables to direct traffic efficiently within your network.

  • Scalability and Flexibility with Resource Management - Easily add or remove resources, scale your network, and adjust configurations to meet changing demands.

Without it, your environment faces increased security risks and reduced control.

Before You Begin

Before you create a VPC or VNet for your gateway, we recommend looking over the following prerequisites. Some of these are specific to the cloud service provider you use.

Prerequisites

  • If you opt to configure a Service VPC or VNet with a native gateway (NAT gateway), you must have a native gateway configured from your cloud service provider. See your cloud service provider documentation for more information.

  • If you intend to deploy a Service VNet with an Azure NAT gateway, confirm you have all of the permissions in your custom role within the Azure dashboard prior to creating and deployng. See Create a Custom Role to Assign to the Application for the complete list of permissions.

  • If you provide your own transit gateway, you are able to attach more than one Service VPC or VNet to it. It is even possible to replace an existing Service VPC or VNet with a new one without re-deploying the gateway.

  • If you create a Service VPC for an FTDv gateway, only AWS and Azure accounts are supported.

Shared VPCs in GCP

If you intend to create, or have already created, a shared VPC in your GCP environment, you must do an additional step to enable inventory in the Multicloud Defense Controller. Without these permissions, asset discovery fails and the Inventory page is not reliable. Access the IAM page of your GCP host project (shared VPC) and grant access to the Multicloud Defense Controller service account from the service project . This access is required to allow the service project to interact with shared network resources. You need to grant the following IAM roles for every GCP project that is affiliated with the shared VPC:

  • Compute Viewer

  • Compute Network User


Important

If you create an environment in GCP where there is a shared VPC setup on one GCP project and the instances are attached to a different GPC project, the Multicloud Defense Gateway ignores all received logs from GCP. This is a default action because Multicloud Defense expects DNS logs to come from a singular project where the instances and network are both located.

Create a Service VPC or VNet

Be sure to review the prerequisites and use cases that affect specific cloud service providers in the Before You Begin section for VPCs and VNets. Use the following procedure to create a Service VPC or VNet.

Procedure

Step 1

From the Multicloud Defense Controller, navigate to Infrastructure > Gateways > VPCs/VNets.

Step 2

Click Create Service VPC/VNet.

Step 3

Input parameter values:

  • Name - Assign a name to the Service VPC/VNet.

  • CSP Account - Select the CSP account to create the Service VPC/VNet.

  • Region - Select the region the Service VPC will be deployed to.

  • (Azure only) CIDR Block – The CIDR Block for Service VNet. This must not overlap with your Spoke(application) VNets.

  • (AWS/GCP only) Datapath CIDR Block - The CIDR Block for the Multicloud Defense Gateway datapath Service VPC. This CIDR block must not overlap with address ranges in your Spoke (application) VPCs.

  • (AWS/GCP only) Management CIDR Block - The CIDR Block for the Multicloud Defense Gateway management Service VPC. This CIDR block must not overlap with address ranges in your Spoke (application) VPCs.

  • Availability Zones - If you are attaching this Servrice VPC to an AWS or Azure NAT gateway, you must have at least one availability zone configured. Note that once you add availability zones to an AWS service VPC you cannot edit the zones to add or remove them if you deploy in an edge or centralized mode. For a a Service VNet, Multicloud Defense recommends to select at least two availability zones for resiliency.

  • (AWS CloudWAN only) Network Type - Select CloudWAN.

  • (AWS CloudWAN only) Network ID - Expand the drop-down menu to select the core network that is associated with the global network in your AWS account.

  • (AWS CloudWAN only) Network Function Group - Use the drop-down menu to select an existing network function group. This selection attaches the service VPC to the network function group in the core network. Alternatively, select Create New to create a new group for this VPC. If you create a new network function group, you will be prompted in this Service VPC window to enter a new name for the network function group.

  • (Azure only) Resource Group - The resource group to deploy service VNet.

  • (AWS only)Transit Gateway - The Transit Gateway connects virtual private cloud and on-premises networks through a central hub. Use the drop-down menu to select an existing gateway for this VPC. If there is no pre-existing gateway for you to select, choose Create_new. This option allows Multicloud Defense to create one as part of the VPC creation process.

  • (AWS only) Transit Gateway Name - If you opted to create a new Transit Gateway, enter a name for the gateway in this field.

  • (AWS only) Auto accept shared attachments - If you opted ot create a new Transit Gateway and intend to use this VPC for a multi-account hub gateway deployment, check this option.

  • (AWS and Azure only) Use NAT Gateway - Enable this option if you want all egress traffic will go through NAT Gateway. If you are using a NAT gateway for an Azure account, confirm you have all of the permissions in your custom role within the Azure dashboard before finish creating this service VNet. See Create a Custom Role to Assign to the Application for the complete list of permissions.

    Caution

     

    Do not enable this NAT Gateway option if you intend to deploy this Service VPC to deploy a Multicloud Defense VPN gateway in your AWS or Azure environment.

Step 4

Click Save.

What to do next

If you have just created a service VPC for an AWS or GCP account, you must first Manage the Service VPC/VNet and then Add a Gateway and associate the VPC or VNet with the gateway.

If you are creating a Service VPC for an FTDv gateway, continue with Create an FTDv Gateway

If you have created a service VNet for Azure, we strongly recommend you Add a Gateway.

Secure Spoke VPC or VNet

By securing the spoke VPCs, you create a more robust and resilient network that can respond to security threats. Securing spoke VPCs helps protect sensitive data that may be transmitted between the service VPC and the spoke VPCs; this can help reduce the overall attack surface as well as proper security measures in spoke VPCs support network segmentation, which is a key strategy in limiting the spread of potential security incidents.

We strongly recommend you secure your spoke VPCs for AWS and GCP accounts before you create or add a gateway.

Below is an example of how spoke VPCs interact with your network:

Figure 4. Azure Combined Hub - Multisubscriptions
Spoke VPCs interacting within a network. Two VNet peering to Azure Subscription Hub containing gateways and load balancers.

Prerequisites and Limitations

Complete these requirements before you secure your spoke VPC or VNet:

AWS

  • AWS does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

  • AWS accounts with CloudWAN must have the following configured through the AWS Network Manager before you secure a spoke VPC or add a gateway:

    • For AWS accounts that are already onboarded, manually modify the permissions list in the AWS dashboard to include networkmanager:* to the MCDControllerRole IAM policy. See AWS' "Adding and removing IAM Identity permission" documentation for more information.

    • You must attach an egress/east-west gateway to the service VPC.

    • You must have at least one global network configured.

    • You must have at least one core network already created, does not have to contain segments already.

Azure

  • VNet pairing is supported across accounts within the same CSP type. You can add spoke VPC/VNets within an account and across accounts. In Azure, for spoke VPCs peering across subscriptions, the CSP accounts should be onboarded using the same app registrations, and subscriptions should be within the same Active Directory.

  • Azure environments require a route table attached prior to securing spoke VPC/VNet. See the "Associate a route table to a subnet" chapter in the Azure user guide for more.

  • Azure does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

GCP

  • GCP does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode; this also applies to Azure, GCP, and OCI for environments deployed in edge mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

OCI

  • OCI does not support adding or removing availability zones from a service VPC after its creation for environments deployed in edge or centralized mode. If you need to modify the availabilty zones after creating a service VPC, you must create a new VPC with the correct zones included.

Manage the Service VPC/VNet

Use the following procedure to manage a spoke VPC or spoke VNet:

Before you begin

When you protect an AWS service VPC that is configured to utilize the AWS CloudWAN, the table shown in this page has a separate row for each edge region. You can add/remove segments to secure the segment using the service VPC. Each segment can be edited with a list of VPCs that can be attached or dettached from the segment. Any traffic flowing through the segment will be protected by the network function group configured in the VPC. Anything forwarded from the segments seen in this table pass through the network function group configured in the VPC.

Procedure

Step 1

From the Multicloud Defense Controller dashboard, navigate to Infrastructure > Gateways > VPCs/VNets.

Step 2

Select Service VPC or Service VNet and click Actions.

Step 3

Click Manage Spoke VPC/VNet.

Step 4

To add a segment to a region that is attached to the VPC or VNet displayed in the table, click Add.

Step 5

Use the drop-down menu to select an available network segment. This action assigns an existing network segement to a service VPC or the network fucntion group inside your service VPC. Note that Multicloud Defense does not create network segments, you must create network segments as part of the core network in you AWS account.

Step 6

To Remove a network segment, select the segment and then click Remove

Step 7

Click + Add VPC to add a VPC and associate a user VPC to the network segment.

  1. In the Add VPC to Segment window, select all spoke VPC or VNets in the left side of the window and click ">" to assign them to the segment. Altenatively, select any existing VPCs or VNets and click "<" to remove it from the segment.

  2. Click Save to confirm the VPC changes.

Step 8

Click Save to confirm the network segment changes. Note that it may take up to 30 minutes for these changes to go into effect and for the affected VPC or VNet to become "Active".

Export a Spoke VPC or VNet

Use the following procedure to export the configuration of a spoke VPC or VNet:

Procedure

Step 1

From the Multicloud Defense Controller dashboard, navigate to Infrastructure > Gateways > VPCs/VNets.

Step 2

Select the Service VPC or Service VNet from the table and click Actions.

Step 3

Click Export.

Step 4

Multicloud Defensegenerates an export wizard.

Step 5

Either click Download to download the terraform locally or scroll down and click Copy Code to copy the JSON resource.

Step 6

Manually paste into the terraform script.

Step 7

Within the terraform prompt, execute the command provided in the lower half of the window.

Step 8

Follow the prompts within the terraform prompt to complete the task. Close the export window.

Delete a Spoke VPC or Vnet

Use the following procedure to delete a spoke VPC or VNet from your account configuration. Note that you may have to confirm the deletion through the dashboard of your cloud service provider.

Procedure

Step 1

From the Multicloud Defense Controller dashboard, navigate to Infrastructure > Gateways > VPCs/VNets.

Step 2

Select the Service VPC or Service VNet from the table and click Actions.

Step 3

Click Delete.

Step 4

Confirm the deletion of the service VPC or VNet and click Yes.

Configure Your Gateway

View your Multicloud Defense Gateways and statistic in Infrastructure > Gateways > Gateways. From this page you can search and filter your gateways, view the cloud service providers assocaited with each gateway, current instance count and type, and more.

For more information on the supported use cases for specific gateway environments, see Supported Gateway Use Cases.

Before You Begin

You can also orchestrate a Transit Gateway through the Multicloud Defense Gateway or attach an existing Transit Gateway.

Multicloud Defense Gateway Prerequisites and Limitations

Prerequisites

The supported cloud service providers (AWS, Azure, GCP, OCI) are separate entities that use their own vocabulary and gateway environment. Not every option available in the Multicloud Defense Controller is compatible with your cloud service provider. For example, AWS uses its own Transit Gateway and you can add VPCs to it while Azure utilizes a load- balancer to manage web traffic and applications and you can add VNets to it. Keep this in mind when proceeding.


Note

For AWS environments, when securing spoke VPCs in centralized mode, Multicloud Defense attaches VPCs to the Transit Gateway that is associated to the service VPC. By default, Multicloud Defense will randomly select a subnet in each availability zone for Transit Gateway attachment. You can change this option when you add a VPC or you can modify a VPC that is already assigned to the gateway.

Limitations

Be aware of the following limitations when creating a Multicloud Defense Gateway:

  • If you deploy a Multicloud Defense Gateway that uses a site-to-site VPN tunnel containing an IPSec profile, you must deploy the gateway with a service VPC or service VNet and without a Network Address Translation (NAT) gateway on either side of the VPN connection.

  • Autoscaling is not supported for gateways containing an IPSec profile.

  • Policy rules within the gateway must be Forwarding only.

  • If you intend to include an IPSec profile in a Multicloud Defense Gateway for an AWS or Azure account, the gateway instance must be configured with core 8. Multicloud Defense Gateway does not currently support gateways with core 2 or core 4 options.

FTDv Gateway Prerequisites and Limitations

Multicloud Defense orchestrates only the process of creating, deploying and maintaining the gateway. Any policy or rule creation occurs in Cloud-Delivered Firewall Management Center. Consider the following prerequisites, limitations, and recommendations to support the integration of both managerial products before you create a gatway.

Prerequisites

You must have the following completed and configured before you create a Multicloud Defense Gateway for your FTDv:

  • You must create a new Service VPC. VPCs created before this feature do not support this functionality; note that when you create a new VPC it can still be used for both Multicloud Defense gateways or FTDv gateways.

  • You must have a cloud service provider onboarded to your Multicloud Defense tenant.

  • If you are using an AWS account as your designated cloud service provider for the FTDv gateway, you must manually accept the AWS Marketplace Terms of Service. Without it, the Multicloud Defense Controller cannot send the required API requests.

  • You must have at least one license purchased through your Cisco seller or partner.

  • You must have a subscription to Cloud-Delivered Firewall Management Center.

For limitations and requirements for this environment, please refer to Firewall Threat Defense Virtual.

Resources Created by Multicloud Defense

The following resources are created by Multicloud Defense when you create a gateway, VPC, or VNet. These are created as part of the process and do not require any additional actions from the user. Note that difference resources are created per each cloud service provider requirements.

GCP Resources

Multicloud Defense creates two service VPCs and four firewalls. See the following for the exact resource allocation:

Service VPC

  • Management

  • Datapath

Firewall Rules

  • Management (ingress)

  • Management (egress)

  • Datapath (ingress)

  • Datapath (egress)


Note

The Service VPC CIDR cannot overlap with the Spoke VPC.

AWS Resources

Multicloud Defense creates three service VPCs to address the supported use cases (ingress, egress/ east-west). Created and affiliated with each of these VPCs is the following:

  • Four subnets in each availability zone.

  • One route table for each of the subnets.

  • Two security-groups: management and datapath.

  • One Transit Gateway.


    Note

    This Transit Gateway is created and attached to the gateway during the creation of the service VPC. This gateway can be reused with other service VPCs.

  • A Transit Gateway route table.


    Note

    The route table is attache to the Service VPC as part of the creation process.


Note

The AWS Gateway Load Balancer (GWLB) does not support add/remove of availability zones after initial deployment of a GWLB. You will need to redeploy the service VPC if you need to change availability zones. See AWS documentation for more information.

Azure Resources

Multicloud Defense created one Service VNet with the following resources:

  • One VNet.

  • Two network security groups.

The Service VNet CIDR value must not overlap with spoke VNet.

FTDv Resources

Multicloud Defense creates the following resources for Service VPCs that are used with Secure Firewall Firewall Threat Defense virtual (FTDv) devices:

  • Management subnet.

  • Datapath 1 subnet.

  • Datapath 2 subnet.

  • Three security groups corresponding to subnets.

Add a Multicloud Defense Gateway

Use the following procedure to add a Multicloud Defense Gateway for your cloud service provider:

Before you begin

Review the Before You Begin for information or requirements pertaining to your specific environment before you create a gateway.

If you are planning on using an AWS global accelerator or Azure load balancer, be sure the load balancer is already configured prior to adding it to a Multicloud Defense Gateway. See Advanced Gateway Configuration: Use Your Own Load Balancer for more information.

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Click Add Gateway.

Step 3

Select the cloud service provider you want to add the gateway to.

Step 4

Click Next.

Step 5

Enter your gateway information.

  • Instance Type - Choose the type of cloud service provider. You may encounter different instance types, depending on your cloud service provider.

    • (Azure only) If you are creating a VPN, and you use Red Hat Enterprise Linux 9 (RHEL 9) as a base operating system, we recommended that you use a Dsv3-Series V3 instance type instead of a Dsv5-Series V5 instance type, as the V5 instance type may not be compatible.

  • Gateway Type - Select either Ingress or Egress.

    Note

     

    Select Egress if you have an east-west network flow.

  • Minimum Instances - Select the minimum number of instances that you plan to deploy.

  • Maximum Instances - Select the maximum number instances that you plan to deploy. This is the maximum number that is used for auto-scaling in each availability zone.

  • HealthCheck Port - Default is 65534. The port number used by Multicloud Defense load balancer to check the health of the instances. Datapath security groups assigned to the instance(s) must allow traffic on this port.

  • (Optional) Packet Capture Profile - Packet Capture Profile for threat and flow PCAPs.

  • (Optional) Diagnostics Profile - Diagnostics Profile used to store Technical Support information.

  • (Optional) Log Profile - Log Forwarding Profile used to forward Events/Logs to a SIEM.

  • (Optional) NTP Profile - Network Time Protocol (NTP) for time synchronization.

  • (Optional) BGP profile - Border Gateway Protocol (BGP) used to support VPN Connections. If you intend on utilizing site-to-site VPN tunnels with a Multicloud Defense Gateway you must include this profile.

Step 6

Click Next.

Step 7

Provide the following parameters:

  • Security - Select either Egress or Ingress.

    Note

     

    Select Egress if you have an east-west network flow.

  • Gateway Image - Image to be deployed.

  • Policy Ruleset - Select the policy ruleset to associate with this gateway.

  • Region - Select the region this gateway will be deployed into.

  • Resource Groups - Select the resource group to associate the gateway with.

  • SSHPublic Key - Paste the SSH public key. The controller uses this key to access the CLI of deployed gateway instances for debugging and monitoring.

  • VNet ID - Select the VNet to associate with the gateway.

  • (Azure only) User Assigned Identity ID - Enter the cloud service provider identity to associate with this gateway. User-assigned managed identities can be used in place of credentials for resources. For Azure services, these identities can access a private key stored in Azure Key Vault or write PCAP files to Azure Blob Storage.

  • Mgmt. Security Group - Select the security group to associate with the management interface.

  • Datapath Security Group - Select the security group to associate with the datapath interface.

  • Disk Encryption - Select the appropriate option from the drop-down menu. If you use a customer-managed encryption key, input the encryption key’s resource ID.

Step 8

Select the Availability Zone, the Mgmt Subnet and the Datapath Subnet. The available subnets will be based on the VPC or VNet you selected. For high availability purposes, you can deploy the gateway instances in multiple availability zones. Click the plus button to add a new availability zone and select the parameters for the selected zones. Some cloud service provider regions support only single availability zone and not multiple availability zones. In such regions, the gateway instances are deployed in only a single zone.

Note

 

If your gateway is deployed in hub mode, availability zones cannot be edited after the initial deployment. Reconfirm your zones before deploying.

Step 9

(Azure only, optional) If you are deploying in distributed model with Multicloud Defense Gateway in the same VNet as application, ensure you complete the following:

  • Add a route table in the Azure portal and associate the route table with all the subnets.

  • Add a default route for 0.0.0.0/0 with next-hop as the IP address of the Gateway Network Load Balancer.

Step 10

Click Next to view the Advanced Settings.

Step 11

By default, the Multicloud Defense Gateway enables the use of the public IP of the router available. If you do not want this enabled, check the Disable Public IP box.

Step 12

(AWS and Azure only) Attach Load Balancer. Click Add Load Balancer to create a row for your custom load balancer. You can also remove unnecessary rows by selecting them and clicking Remove.

  1. Expand the Load Balancer drop-down to select a load balancer from your AWS or Azure cloud service provider.

  2. Expand the Backend Pool drop-down to select a backend pool to be associated with your gateway.

Step 13

Click Save.

What to do next

Multicloud Defense deploys the gateway.

You must attach at least one ruleset to the gateway before you secure a spoke VPC/VNet. See Rule Sets and Rule Set Groups for more information.

Create an FTDv Gateway

Use the following procedure to create an FTDv gateway:

Before you begin

Review the Before You Begin for information or environment limitations before you create a gateway.

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Click Add Gateway.

Step 3

Select the cloud service provider you want to add the gateway to.

Step 4

Click Next.

Step 5

Enter the following Gateway Information. Note that if you do not have the feature enabled, the options for "Gateway Type" may differ and you should refer to Add a Gateway.

  • Account - Expand the drop-down menu and select a cloud service provider account that is already onboarded to Multicloud Defense Controller. At this time, only AWS and Azure accounts are supported.

  • Gateway Type - Expand the drop-down menu and select FTDv Gateway.

  • Name - Enter a name for the gateway as it will be displayed in the Multicloud Defense Controller.

  • (Optional) Description - Enter a description for the gateway. We recommend using unique identifiers to differentiate this gateway from others that may have a similar name or purpose.

  • Instance Type - Choose the type of cloud service provider. This selection should match the cloud service provider that is selected in the before-mentioned "Account" field. Note that there may be multiple variations of instances depending on which cloud service provider you are using.

  • Minimum Instances - Select the minimum number of instances that you plan to deploy.

  • Maximum Instances - Select the maximum number instances that you plan to deploy. This is the maximum number that is used for auto-scaling in each availability zone.

  • HealthCheck Port - Default is 65534. The port number used by Multicloud Defense load balancer to check the health of the instances. Datapath security groups assigned to the instance(s) must allow traffic on this port.

Step 6

Click Next.

Step 7

Provide the following parameters where applicable. Note that several fields are auto-filled in based on the configuration of the Service VPC you created for this gateway. See Create a Service VPC or VNet for more information.

  • Security - East-West/Egress is auto-selected. At this time, Ingress gateways are not supported.

  • FTDv Version - Select the version of software to run on the FTDv device when Multicloud Defense creates and deploys the device.

  • Policy Ruleset - Select the access control policy ruleset to associate with this gateway. If you do not already have an access policy ready you can either use the default policy or create a new policy from this menu.

  • Admin Password - Enter a password for the admin of the FTDv device. Follow the on-screen prompts for a strong password.

  • License Model - Click the toggle to highlight your preferred licensing model:

    • Multicloud Defense Licensing - The Multicloud Defense licensing model allows you to use all the FTDv features without procuring individual feature licenses in Cisco Smart Licensing account.

    • Smart Licensing - Select this option if you intend to purchase a license or have an unused license already purchased through your Cisco Smart Account.

  • Performance Tier - Expand the drop-down menu and select the appropriate performance tier for your device. Note that FTDv50 is auto-selected. See the tiers listed in Licensing.

  • License Types - Expand the drop-down menu and select the appropriate license type that you have purchased or will purchase in the future. Note that the Base license is auto-selected. See the different licensing types listed in Licensing.

  • Region - Select the region this gateway will be deployed into.

  • VPC/VNet ID - Select the ID of the Service VPC or VNet to associate with the gateway. Identifying a Service VPC or VNet in this step confirms the management and datapath security groups as well as the availability zones. To modify these values, create a new service VPC and add it to this gateway.

  • (AWS only) Key Pair - Expand the drop-down menu and select the key pair that is associated with the cloud account you selected in the previous screen.

  • (Azure only) Key Selection - Select the type of key, its size, and its activation and expiration dates. Choose either "SSH Public Key" or "SSH Key Pair". Based on your selection, enter the appropriate information in the text field when prompted.

  • Resource Groups - Select the resource group to associate the gateway with.

  • (AWS only) Gateway IAM Role - Expand the drop-down menu and select the IAM role that allows the gateway to perform READ and WRITE operations on your AWS account. Multicloud Defense creates this role for you when you save and deploy the gateway.

  • (Azure only) User Assigned Identity ID - Enter the cloud service provider identity to associate with this gateway. User-assigned managed identities can be used in place of credentials for resources. User-assigned managed identities can be used for Azure services such as a private key stored in Azure Key Vault or to write PCAP files to an Azure Blob Storage.

  • Mgmt. Security Group - Select the security group to associate with the management interface.

  • DataPath Security Group 1 - Select the security group to associate with the datapath 1 interface.

  • DataPath Security Group 2 - Select the security group to associate with the datapath 2 interface.

  • (AWS only) EBS Encryption - Expand the drop-down menu and select the appropriate EBS encryption for your specific AWS account.

  • (Azure) Disk Encryption - Select the appropriate option from the drop-down menu. For customer managed encryption key, the user will need to input the resource ID of the encryption key.

Step 8

The Instance Details are auto-populated based on the VPC you select. Review the VPC configuration before you deploy the gateway. Click Next.

Step 9

(Optional) In the Advanced Settings window, check the Disable Public IP checkbox; if you opt to disable this step you reduce the exposure of your network to external threats. Private IP addresses can help protect against unauthorized access and potential attacks. They also offer better control of internal traffic.

Step 10

Click Next.

Step 11

Review the configuration of the gateway. If you are satisfied with the gateway and want to deploy it, click Finish. If you want to modify the settings, click Back.

What to do next

Clicking Finish at the end of this procedure deploys the gateway; creating and deploying the gateway may take up to 30 minutes. While Multicloud Defense deploys the gateway, it also registers the gateway instance in Cloud-Delivered Firewall Management Center for your convenience, creates and applies subnets and security groups for the appropriate interfaces, and applies the access policy you selected in this procedure.

Once the gateway deploys and is displayed in the Cloud-Delivered Firewall Management Center we recommend making any necessary updates or inclusions to the policy. Any network objects associated with the policy are shared and displayed in Multicloud Defense's Object page as network objects for visibility. Policy orchestration and management is done through Cloud-Delivered Firewall Management Center.

We strongly recommend the following actions once the gateway is deployed:

Edit a Multicloud Defense Gateway

You can edit a gateway in any state, whether it is enabled or disabled.


Note

If you edit a gateway that is attached to an FTDv device, note that you cannot change the licensing model, only the performance tier of the smart license.

Use the following procedure to edit an existing Multicloud Defense Gateway:

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to edit in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Edit.

Step 4

Modify the gateway configuration as needed.

If you are modifying the license peformance tier for a gateway that is asssociated with an FTDv device, note that existing instances are automatically updated in Cloud-Delivered Firewall Management Center; Multicloud Defense creates new instances to support the new license configuration and sync to Cloud-Delivered Firewall Management Center for you.

Step 5

Click Save to confirm the changes. Alternatively, click Cancel to exit the changes.

Upgrade the Multicloud Defense Gateway

Multicloud Defense Gateways serve as an autoscaling self-healing Platform-as-a-Service (Paas), functioning as inline network-based security enforcement nodes. Unlike traditional firewalls, Multicloud Defense eliminates the need for customers to construct virtual firewalls, configure high-availability setups, or manage software installations.

Multicloud Defense Gateway instances operate on highly optimized software, incorporating a single-pass datapath pipeline for efficient traffic processing and advanced security enforcement. Each gateway instance comprises three core processes: a "worker" process responsible for policy enforcement, a "distributor" process for traffic distribution and session management, and an "agent" process communicating with the controller. Gateway instances can seamlessly transition "in service" for a "datapath restart," enabling smooth upgrades without disrupting traffic flow.

New instances are spun up with new image. Once the instances are fully up, they are placed in the loadbalancer's (layer 4 sprayer of flows to gateway instances) target pool. The old instances are put in flow draining mode or flow timeout mode for the existing flows going through them. New flows will hit the new instances. Once the timeout (Azure) or the flows are drained (AWS), the old instances are reaped by the controller.

Use the following procedure to

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the checkbox for the gateway you want to upgrade. You can make only one selection at this time.

Step 3

Select Actions > Upgrade.

Step 4

From the Gateway Image list, select the desired image.

Step 5

Click Save.

Step 6

Confirm the cloud service provider resource allocation necessary for the upgrade.

Step 7

Click Yes if the resource allocation is sufficient. Click No if the resource allocation is insufficient, increase the resource allocation in the cloud service provider, and return to continue the upgrade.

Note

 

You can view the upgrade progress and new gateway instances being created from theinstances info for the gateway. Select the gateway and view the Instances in the Details pane.

Upgrade Your Firewall Threat Defense Virtual Device

This procedure explains how to upgrade the Firewall Threat Defense virtual (FTDv) devices that are affiliated with a cloud service povider and a Multicloud Defense Gateway. We strongly recommend upgrading your FTDv device through the Multicloud Defense Controller.

Procedure

Step 1

Navigate to Infrastructure > Gateway > Gateways and select the gateway associated with your Firewall Threat Defense virtual device.

Step 2

Click Actions and select Upgrade.

Step 3

Expand the FTDv Version drop-down menu and select the version you want to upgrade to. If there are no versions listed, click the refresh icon located to the right of the drop-down menu or confirm with the Cisco Secure Firewall Threat Defense release notes to see if a new version is publicly available.

Step 4

Click Save. Multicloud Defense initiates the upgrade and redeploys that gateway.

Abort a Multicloud Defense Gateway

You can only abort a Multicloud Defense Gateway that is currently going through an in-progress gateway update.

Use the following procedure to abort an existing Multicloud Defense Gateway:

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to abort in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Abort.

Step 4

Confirm you want to abort the gateway and click Yes. To back out of the action, click No.

Enable a Multicloud Defense Gateway

You can only enable gateways that have been disabled. Use the following procedure to enable a

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to enable in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Enable.

Step 4

Multicloud Defense validates the gateway configuration. If the validation is successful, a table of current and required resources for an upgrade generate for review. If you approve of the gateway resource allocation, click Yes to confirm the action.

What to do next

Wait a few minutes for the Multicloud Defense Gateway to successfully enable.

If you've disabled a Multicloud Defense Gateway and deleted the site-to-site VPN tunnels affiliated with it, you must create a new site-to-site VPN tunnel connection, or recreate the previous VPN tunnel connection and then add it to the gateway. When a gateway is disabled, Multicloud Defense forgets the public IP address associated with the VPN tunnel. You must create a new tunnel connection to establish a new IP for the gateway instance.

Disable a Multicloud Defense Gateway

You can only disable a Multicloud Defense Gateway if it is currently enabled. You cannot disable gateways that are already disabled.

Use the following procedure to disable a Multicloud Defense Gateway:

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to disable in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Disable.

Step 4

Confirm you want to disable the gateway and click Yes. To cancel this action, click No.

What to do next

Wait a few minutes for the gateway to succesfully disable.

To completely disable the gateway, you must delete any site-to-site VPN tunnels affiliated with the gateway.

Export a Multicloud Defense Gateway

Use the following procedure to export the configuration of a Multicloud Defense Gateway:

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to export in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Export.

Step 4

Multicloud Defense generates an export wizard.

Step 5

Either click Download to download the terraform locally or scroll down and click Copy Code to copy the JSON resource.

Step 6

Manually paste into the terraform script.

Step 7

Within the terraform prompt, execute the command provided in the lower half of the window: terraform import "ciscomcd_gateway"."object-name" <object name>.

Step 8

Follow the prompts within the terraform prompt to complete the task. Close the export window in Multicloud Defense. There are no more steps in the dashboard.

Delete a Multicloud Defense Gateway

Use the following procedure to delete a Multicloud Defense Gateway. Note that this action is different from disabling the gateway.

Procedure

Step 1

Navigate to Infrastructure > Gateways > Gateways.

Step 2

Select the Multicloud Defense Gateway you want to delete in the table so it is highlighted.

Step 3

Expand the Actions drop-down menu and click Delete.

Step 4

Confirm the action and click Yes. To cancel the deletion action, click Cancel.

What to do next

We strongly recommend deleting any site-to-site VPN tunnel connections associated with this gateway after it is successfully deleted from the gateway table.