Skip to main content
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:

​
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:

​
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 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 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: 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