> ## Documentation Index > Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt > Use this file to discover all available pages before exploring further. # Migrating from Legacy Egress to Distributed Cloud Firewall > If you configured Egress FQDN filtering in the Aviatrix Controller, Aviatrix strongly recommends that you upgrade to Distributed Cloud Firewall (DCF) with its accompanying WebGroups functionality. This migration requires Controller 8.1 or greater. If you configured Egress FQDN filtering in the Aviatrix Controller, Aviatrix strongly recommends that you upgrade to Distributed Cloud Firewall (DCF) with its accompanying WebGroups functionality. This migration requires **Controller 8.1 or greater**. If you migrate to DCF you can no longer use Legacy Egress FQDN. DCF allows for more granular security policies and a higher level of threat protection. DCF provides significant performance improvements through distributed processing, optimized rule evaluation, and elimination of duplicate gateway-specific rules. Reach out to your Aviatrix Sales Representative for assistance with this migration. This guide assumes Controller 8.1 or greater. The DCF behaviors described below — including DCF on FireNet gateways and the single default policy action — apply from Controller 8.1 forward. ## Considerations Before Migration * Existing High Availability setups are compatible and encouraged. * Protocol Migration: DCF WebGroups apply to HTTP and TLS traffic. DCF detects HTTP and TLS based on the traffic itself, not the destination port, so a WebGroup applies wherever HTTP or TLS is detected and is not tied to a fixed port set. For Legacy Egress filters using other protocols (SSH, SMTP, FTP, and so on), migrate using SmartGroups: * Use HostName SmartGroups for FQDN-based filtering of non-HTTP/TLS protocols. * Use CIDR-based SmartGroups when static IP addresses are known and suitable. * Wildcard Compatibility: DCF WebGroups have full wildcard support, which will accommodate legacy filters with mid-string wildcards (sub.\*.domain.com). * Gateway Requirements — DCF is supported on the following gateway types: * Spoke Gateways * Public Subnet Filtering (PSF) Gateways * FireNet gateways * Transit gateways for site-to-cloud (S2C) traffic * Standalone Gateways must be redeployed as Spoke Gateways Alternative Approach: users running FireNet egress can instead enable Local Egress on each Spoke gateway. This distributes egress enforcement to the spoke level (each gateway inspects and SNATs its own outbound traffic) rather than backhauling egress traffic through the FireNet gateway for centralized inspection. Spoke gateways must meet the minimum size (for example, t3.small for AWS) to handle the distributed processing of DCF rules. If you have Spoke Gateways that are smaller than the minimum size, you must upgrade them to a supported size before migrating. For per-feature gateway sizing, see the Aviatrix Gateway Feature Modes reference, and tune performance using the About Auto Right-Sizing feature. ## Combined Comparison: Legacy Egress vs. Distributed Cloud Firewall The following table combines the comparison of capabilities and the mapping of Legacy Egress features to Distributed Cloud Firewall (DCF) components: | Capability/Component | Legacy Egress | DCF | Benefits/Notes | | --------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | FQDN Filtering | Create tags containing domain lists, then attach gateways to tags | Create WebGroups with domain lists, reference in DCF rules | Centralized domain management; Better performance; Advanced threat protection | | Resource Definition | Assign individual Spoke Gateways to FQDN tags | Create SmartGroups with flexible match criteria (VPC/VNet, Subnets, VMs, IP/CIDR, External Connections, Hostnames) | Dynamic resource matching; Scalable policy management; Reduced configuration overhead | | Policy Actions | Select Allowlist/Denylist per tag | Configure Allow/Deny actions per DCF rule with granular control | Rule-level action control; More flexible policy combinations; Support for complex scenarios | | Policy Enforcement | Enable/Disable entire tags | Enable/Disable individual DCF rules with monitoring mode | Granular rule control; Safe testing with monitor mode; Independent rule lifecycle | | Protocol Support | All protocols and ports supported | WebGroups apply to TLS or HTTP traffic detected on any port (not tied to a fixed port set); HostName SmartGroups for non-Web traffic; all protocols for CIDR-based rules | Optimized for Web traffic (TLS or HTTP); FQDN filtering for non-Web protocols; Deep packet inspection; Protocol-aware filtering | | Rule Scope | Gateway-specific (duplicate rules needed for HA pairs) | Global rules apply across all gateways | Simplified management; Automatic HA coverage; Consistent policy enforcement | | Performance | Per-gateway processing with potential bottlenecks | Distributed processing with optimized rule evaluation | Higher throughput; Lower latency; Better scalability | | Logging & Monitoring | Gateway-specific logs in CoPilot FlowIQ | Centralized DCF Monitor with enhanced visibility | Unified log view; Advanced filtering; Better troubleshooting | | Wildcard Support | Full wildcard support (*.domain.com, sub.*.domain.com) | Full wildcard support (*.domain.com, sub.*.domain.com) | Simplified pattern matching; Better performance; Consistent behavior | | Gateway Types | Spoke, Standalone, FireNet Gateways | Spoke, Public Subnet Filtering (PSF), FireNet, and Transit (S2C) gateways | Broader gateway coverage including FireNet; Optimized performance; Simplified deployment | | FQDN Tag with domains | Legacy Egress Component | WebGroup(s) for HTTP/TLS traffic, or HostName SmartGroup(s) for non-HTTP/TLS traffic | May create multiple WebGroups if different port/protocol combinations exist; use HostName SmartGroups for protocols WebGroups do not match | | Gateway attachment to FQDN tag | Legacy Egress Component | SmartGroup (VPC/VNet-based) | Uses account, region, and VPC/VNet name as match criteria | | Stateful Firewall Tag (CIDR list) | Legacy Egress Component | SmartGroup (CIDR-based) | Maintains original tag name | | Individual CIDR in policies | Legacy Egress Component | SmartGroup (CIDR-based) | Named as cidr\_(CIDR)-(mask) unless matches existing tag | | Discovery mode | Legacy Egress Component | Special DCF Rules | Creates rules with "Any-Web" WebGroup and logging enabled | | Default stateful firewall action | Legacy Egress Component | DCF default policy action | DCF exposes a single default policy action that is a full permit-any/any or deny-any/any. You can change the default action and toggle logging on it. This replaces the earlier behavior of generating per-entity catch-all rules. | ## Manual Migration Process For manual migration, follow these steps to replicate your Legacy Egress FQDN configurations in Distributed Cloud Firewall: ### Step 1: Inventory Current Configuration Document your existing Legacy Egress configuration: | Element | Information to Record | | -------------------- | ----------------------------------------------------------------------- | | Tags | All tags in Security > Egress Control > Egress FQDN Filter | | Domain Lists | FQDNs/URLs associated with each tag | | Gateway Attachments | Which gateways are attached to each tag (from Egress FQDN Gateway View) | | Allow/Deny Actions | ALLOWLIST/DENYLIST setting for each tag | | Status | Enabled/Disabled status for each tag | | Source Configuration | Any custom source IP settings for tags with attached gateways | | Port/Protocol | Port and protocol information for each FQDN rule | ### Step 2: Create WebGroups For each Legacy Egress FQDN tag that targets HTTP or TLS traffic: 1. Navigate to Security > Distributed Cloud Firewall > WebGroups. 2. Click *+ WebGroup*. 3. Configure the WebGroup: * Name: Provide a descriptive name for the WebGroup * Domains: Add the FQDNs from the legacy tag You do not designate a WebGroup as TLS or HTTP; the same WebGroup is used for both. When traffic is TLS, DCF matches the SNI field against the WebGroup domains. When traffic is HTTP, DCF matches the Host header. You do not need separate WebGroups for HTTP and TLS variants of the same FQDN list. Create a separate WebGroup only when the legacy tag mixes web (HTTP/TLS) and non-web traffic, or when you need to apply different policy to different domain subsets. For non-HTTP/TLS protocols, use a HostName SmartGroup instead. See [Step 5: Handle Non-WebGroup Protocols](#step-5-handle-non-webgroup-protocols). ### Step 3: Create SmartGroups Create SmartGroups to represent the resources that were attached to the legacy FQDN tags: #### VPC/VNet SmartGroups 1. Navigate to Security > Distributed Cloud Firewall > SmartGroups. 2. Click *+ SmartGroup*. 3. Configure for VPC/VNet matching: * Name: Provide a descriptive name * Resource Type: VPC/VNet * Match Criteria: Account, Region, Name * Values: Specify the VPC/VNet details #### CIDR SmartGroups (for Stateful Firewall Tags) For any Stateful Firewall tags being migrated: 1. Navigate to Security > Distributed Cloud Firewall > SmartGroups. 2. Click *+ SmartGroup*. 3. Create CIDR-based SmartGroups. * Name: Provide a descriptive name * Resource Type: IP/CIDR * CIDR: Enter the IP ranges from the legacy tag #### HostName SmartGroups (for Non-HTTP/TLS Domain Filtering) For any legacy FQDN tag whose traffic is **not** HTTP or TLS (for example, domains that are reached over SSH, SMTP, FTP, or other protocols WebGroups do not match), create a HostName SmartGroup rather than a WebGroup. HostName SmartGroups let DCF resolve FQDNs to IP addresses dynamically and apply the resulting rules on any protocol or port. 1. Navigate to Security > Distributed Cloud Firewall > SmartGroups. 2. Click *+ SmartGroup*. 3. Select **Hostname** as the resource type. 4. Configure the group: * Name: Provide a descriptive name * Hostname: Enter the FQDNs from the legacy tag You then reference the HostName SmartGroup as the destination in the DCF rule that matches your non-HTTP/TLS protocol. See [Step 5: Handle Non-WebGroup Protocols](#step-5-handle-non-webgroup-protocols) for the complete flow. ### Step 4: Create DCF Rules For each legacy configuration, create corresponding DCF rules: 1. Navigate to Security > Distributed Cloud Firewall > Policies. 2. Select a ruleset or create a new one. 3. Click *+ Rule*. 4. Configure the rule: * Name: Provide a descriptive name * Source SmartGroups: Select the VPC/VNet SmartGroups * Destination: Select **Public Internet** for egress rules * WebGroups: Select the appropriate WebGroup for FQDN filtering * Protocol: TCP (for HTTP/TLS traffic) * Port: Specifying a port is good practice when the port is known but is not strictly required, because WebGroups are matched by detected protocol rather than by port. However, because Legacy Egress only inspected a fixed set of ports (80, 443, 8080, 8443), restricting your migrated rules to those ports is the most direct way to reproduce the legacy scope. * Action: Allow or Deny (matching legacy configuration) * Logging: Enable for monitoring * Enforcement: Start with disabled for testing ### Step 5: Handle Non-WebGroup Protocols For Legacy Egress rules using protocols not supported by WebGroups (non-HTTP/TLS traffic), migrate using HostName SmartGroups or CIDR-based SmartGroups. #### For Protocols Requiring FQDN Filtering 1. Navigate to Groups > Settings > DNS Server for Hostname Resolution. 2. Configure either Gateway's Management DNS Server or custom DNS servers. 3. Create a HostName SmartGroup: 1. Navigate to Security > Distributed Cloud Firewall > SmartGroups. 2. Click *+ SmartGroup*. 3. Select **Hostname** as the resource type. * Hostname: Enter the FQDN from your legacy rule * Name: Provide a descriptive name 4. Create DCF rules: 1. Source SmartGroups: Select the VPC/VNet SmartGroups 2. Destination: Select the HostName SmartGroup 3. Protocol: Specify the protocol (for example, TCP, UDP) 4. Port: Specify the ports (for example, 22 for SSH, 25 for SMTP) #### For Protocols with Known Static IP Destinations 1. Check whether DCF already ships an external feed for the destination. The Groups > Feeds tab includes Aviatrix-managed SaaS-based service feeds (for example, **Azure Services** and **GitHub Services**), which you can wrap in an ExternalGroup instead of maintaining a static IP list yourself. See Managing the Relationship Between Feeds and ExternalGroups . 2. If no external feed covers the destination, research the current IP addresses for the FQDNs and create a CIDR-based SmartGroup: * Resource Type: IP/CIDR * IP/CIDRs: Enter the IP ranges * Name: Provide a descriptive name HostName SmartGroups provide dynamic DNS resolution and are the preferred method for maintaining FQDN-based filtering. Use CIDR-based SmartGroups only when a HostName SmartGroup or an Aviatrix-managed external feed is not suitable for your use case. ### Step 6: Create Catch-All Rules For each VPC/VNet, create appropriate catch-all rules based on the security posture of the VPC/VNet. Scope the destination of every catch-all rule to **Public Internet**, not Anywhere. Legacy Egress only inspected traffic heading to the public internet, so an Anywhere catch-all would also affect east-west (VPC-to-VPC) traffic and is broader than the legacy behavior: * For VPCs with Stateful Firewall Default Deny: Create deny rules with destination Public Internet for those VPCs. * For VPCs with Stateful Firewall Default Allow: Create allow rules with destination Public Internet (placed below deny rules to avoid unintentionally overriding or blocking the effect of a valid lower-priority rule). * For VPCs without Stateful Firewall Policies: Create "Catch All Unknown" rules with destination Public Internet (review manually). * Global Catch-All: Create a final rule with source Any and destination **Public Internet**; set to ALLOW initially and change to DENY after testing. ## Post-Migration DCF Ruleset Example The following example illustrates a typical DCF ruleset after migrating three VPCs with different Legacy Egress configurations: | Rule Name | Source SmartGroup | Destination | WebGroup/Protocol | Port | Action | Purpose | | --------------------------- | ----------------- | ------------------------------------------------------------- | --------------------- | ------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Allow-HTTP-to-Google | sg-app-servers | Public Internet | wg-google / HTTP | 80 | Allow | Allow app servers to access Google over HTTP | | Deny-FTP-to-External | sg-dmz | Public Internet (or a HostName SmartGroup for specific hosts) | N/A / FTP | 21 | Deny | Block DMZ servers from accessing external FTP sites; specify a HostName SmartGroup as the destination if you only want to block FTP to certain hosts | | Allow-TLS-to-Internal-API | sg-backend | 10.10.10.0/24 | wg-internal-api / TCP | 443 | Allow | Permit backend servers to reach internal API over TLS | | Monitor-AnyWeb-to-Discovery | sg-discovery | Public Internet | wg-any-web / TCP | 80, 443 | Monitor | Log web (HTTP and TLS) traffic from discovery group for analysis | This example demonstrates how Legacy Egress FQDN tags are replaced by WebGroups for HTTP/TLS traffic and HostName SmartGroups for non-Web protocols, with appropriate source SmartGroups representing each VPC. Destinations for catch-all or egress-style rules are scoped to **Public Internet** so the rules do not inadvertently affect east-west traffic. ## Best Practices and Recommendations ### Pre-Migration Planning * Test Environment First: Always test the migration in a lab environment before production * Backup Configuration: Export current Legacy Egress configuration before starting migration * Start with PERMIT: Begin with global catch-all action set to PERMIT, then transition to DENY after validation * Phased Approach: Consider migrating VPCs/VNets in phases rather than all at once * Maintenance Window: Plan appropriate maintenance windows for production migration ### Configuration Optimization * Rule Consolidation: Take advantage of DCF's ability to have multiple ports in a single rule * SmartGroup Reuse: Create reusable SmartGroups that can be referenced across multiple rules * WebGroup Organization: Organize WebGroups by business function or security policy purpose * Logging Strategy: Enable logging on all rules initially, then optimize based on monitoring needs * Rule Ordering: Ensure more specific rules appear before general catch-all rules ### Migration Validation and Testing #### Pre-Production Testing 1. Lab Environment: Deploy the configuration in a test environment first 2. Monitor Mode: Enable logging on all rules with Enforcement disabled 3. Traffic Analysis: Review DCF logs in Security > Distributed Cloud Firewall > Monitor 4. Domain Validation: Verify the Domain field is populated for WebGroup traffic #### Production Deployment 1. Maintenance Window: Schedule appropriate downtime 2. Phased Approach: Enable rules incrementally 3. Monitoring: Monitor traffic and logs continuously 4. Rollback Plan: Prepare to disable DCF rules quickly if needed ### Post-Migration Monitoring * Traffic Validation: Monitor DCF logs to ensure all expected traffic is flowing correctly * Performance Monitoring: Validate that network performance meets expectations * Rule Effectiveness: Review rule hit counts to identify unused or overly broad rules * Security Posture: Confirm that the migrated configuration maintains desired security controls #### Post-Migration Validation 1. Functional Testing: Verify applications work as expected 2. Log Analysis: Check DCF logs for proper rule matching 3. Performance Monitoring: Validate improved performance 4. Security Posture: Confirm that security policies are enforced as intended ## Troubleshooting ### WebGroup Not Matching Traffic * Verify the Domain field is populated in DCF logs * Check if traffic is TLS-encrypted for HTTPS domains * Confirm port/protocol settings match actual traffic ### Performance Issues * Review rule ordering for efficiency * Consolidate rules where possible * Consider SmartGroup optimization ### Non-Web Traffic * Use HostName SmartGroups for non-TLS/non-HTTP protocols. * Configure CIDR-based SmartGroups when HostName SmartGroups are unavailable or not suitable, or wrap an Aviatrix-managed external feed in an ExternalGroup for well-known services (for example, Azure Services). * Leverage DCF's comprehensive protocol support ### Translation Errors * Check input file format and completeness * Verify Controller version compatibility ### DCF Configuration Issues * Check resource naming conflicts * Verify SmartGroup and WebGroup dependencies ## Related Topics * Egress Control Filter Workflow * Distributed Cloud Firewall Overview * Web Groups Overview * Smart Groups Overview * General Guidelines for Migrating from Legacy ThreatIQ and Geoblocking to Distributed Cloud Firewall * Aviatrix Kubernetes Firewall