Skip to main content
Distributed Cloud Firewall (DCF) uses micro-segmentation to provide granular network security rules for distributed applications in the Cloud. Distributed Cloud Firewall enables network policy enforcement between SmartGroups, WebGroups, and ExternalGroups you define in a single cloud or across multiple clouds. Micro-Seg Topology Currently, DCF contains both Preview and GA features. See Distributed Cloud Firewall Supported Capabilities by Controller Version for more information.
Aviatrix strongly recommends using DCF and its integration with ExternalGroups to monitor for threats and block certain countries. If you are an existing user of ThreatIQ and/or Geoblocking (prior to Controller version 7.2.4820), use these migration recommendations to start using DCF with ExternalGroups. You cannot use ThreatIQ and/or Geoblocking in conjunction with DCF and ExternalGroups.

​
Supported Cloud Providers and Gateways

Distributed Cloud Firewall is supported for the following clouds:
  • AWS, AWS GovCloud, AWS China
  • Azure, Azure Government, Azure in China
  • GCP, Google for Government
  • OCI, Oracle Government Cloud, Oracle China
The following gateway types are supported:
DCF rules will not be applied to traffic originating or terminating on Aviatrix gateways.If you want to use External Connections in your DCF rules, ensure that the Spoke or Transit gateway that the DCF rule terminates on is upgraded to 7.2.4820. DCF rules that use External Connections will not be evaluated or enforced on 7.1 gateways.

​
Minimum Spoke Gateway Sizing

  • 3583MB required for L7 with IDS
  • 3583MB required for IDS and TLS Decryption
  • 8192MB (8 GB) recommended for L7 with IPS
Minimum Spoke gateway sizing is provided in the following table.
When IPS is enabled, spoke gateways require a minimum of 8 GB memory for production workloads. Gateways with 4 GB memory may experience connection timeouts and increased failure rates under sustained IPS inspection. SeeIntrusion Prevention System (IPS)for more information.
DCF can be used to control Egress traffic by enabling Source NAT on the gateway configuration, and creating policies with WebGroups .
As of Controller 7.1, DCF with WebGroups is the recommended method for configuring and implementing Egress Security.This document describes Egress functionality available in the Aviatrix Controller in Controller 7.1 and later. For information on configuring the legacy Egress FQDN solution, clickEgress FQDN Filtering (Legacy) .DCF is in Preview mode for earlier Controller versions. SeeAviatrix Feature Availability by Controller Version for more information.

​
Use Cases

Use cases where you might implement DCF are:
  • Workload isolation: in a typical tiered application, you may want to isolate tiers that do not require access to each other. For example, in a Shopping Cart application, there could be workloads for product inventory, billing, and a Product Logging app. Since the Shopping Cart application does not need to communicate with the Product Logging app, this traffic should be blocked.
  • Quarantine compromised machines: You can isolate a compromised machine by placing it in its own SmartGroup and blocking communication to that SmartGroup.