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:

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:

AWS CloudWAN

At this time, Multicloud Defense supports the inclusion of AWS' CloudWAN in egress gateways. CloudWAN is 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 tegion 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.

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) you one of 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.

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.

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 (egress)

• 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.