Overview
Multicloud Defense Gateway is a network-based security platform comprised 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 and 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/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 zones failure from a cloud service provider does not compromise the security posture for running applications.
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.
Multicloud Defense Gateways can be deployed in two ways; Hub mode and Edge mode.
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 maximu 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.
Supported Gateway Use Cases
Egress
Egress/East-West Gateways
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 following diagram is an example of an AWS account with an egress gateway in a centralized mode:
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475051.jpg)
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 ervice provider fails, Multicloud Defense system logs capture the instance for troubleshooting.
See the following supported configurations:
-
Azure supports one subnet.
-
You must have at least one public IP address configured in your NAT gateway.
The following diagram is an example of an Azure account with an egress gateway in a centralized mode:
![](/c/dam/en/us/td/i/400001-500000/480001-490000/484001-485000/484202.jpg)
Ingress
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 following diagram is an example of an AWS account with an ingress gateway in a centralized mode:
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475050.jpg)
East-West
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 following diagram is an example of an AWS account with an east-west gateway in a centralized mode:
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475052.jpg)
Distributed
You have applications running in multiple VPC/VNets. Deploy a Multicloud Defense Gateway in each of the VPCs/VNets.
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475053.jpg)
Centralized / Hub
You have applications running in multiple VPCs/VNet. You would like to secure all the applications through a centralized security services VPC/VNet. This model deploys the Multicloud Defense Gateway in a service VPC. You attach all the application VPCs (Spoke VPCs) and the Services VPC to the AWS Transit Gateway or VNet/VPC peering in Azure and GCP. Multicloud Defense provides an option to orchestrate the AWS Transit Gateway, Services 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.
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475054.jpg)
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475055.jpg)
![](/c/dam/en/us/td/i/400001-500000/470001-480000/475001-476000/475056.jpg)
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 Multicloud Defense 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 onstances. 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 Amazon AWS documentation.
Azure Load Blanacer
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 backendpool that contains at least one cluster of Multicloud Defense Gateway instances. This scenario is ideal if you want 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 ot use this capability. Beware the following prerequisites and limitations:
-
You must have your Azure load balancer already configured.
-
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 opt to configure your Azure load balancer with a resource group, 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.
Gateways Details
To view the Gateway Details page for already established gateways are available in
. 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.![]() Note |
You must be an Admin or SuperAdmin for these actions. To filter and search the list of gateways, use the following criteria can be any of the following items:
|
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.