Migrating from Legacy Egress to Distributed Cloud Firewall

​

Considerations Before Migration

• Existing High Availability setups are compatible and encouraged.
• Protocol Migration: DCF WebGroups support HTTP and TLS traffic only (ports 80, 443, 8080, 8443). For Legacy Egress filters using other protocols (SSH, SMTP, FTP, etc.), migrate using SmartGroups:
  • Use hostname SmartGroups for FQDN-based filtering of non-HTTP/TLS protocols (Controller 7.2 or greater)
  • 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:
  • Spoke Gateways and Public Subnet Filtering (PSF) Gateways
  • Standalone Gateways must be redeployed as Spoke Gateways
  • Alternative Approach: FireNet Egress gateways should consider migrating to Distributed Egress per VPC.

​

Combined Comparison: Legacy Egress vs. Distributed Cloud Firewall

​

Manual Migration Process

​

Step 1: Inventory Current Configuration

​

Step 2: Create WebGroups

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
   • Type: Select based on content (e.g., Social Networking, Streaming Media)

​

Step 3: Create SmartGroups

​

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)

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

​

Step 4: Create 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: Specify the ports (80, 443, 8080, 8443)
   • Action: Allow or Deny (matching legacy configuration)
   • Logging: Enable for monitoring
   • Enforcement: Start with disabled for testing

​

Step 5: Handle Non-WebGroup Protocols

​

For Protocols Requiring FQDN filtering (Controller 7.2 or greater)

1. Navigate to Groups > Settings > DNS Server for Hostname Resolution.
2. Configure either Gateway’s Management DNS Server or custom DNS servers.
3. Create SmartGroups with Resource Type “Hostname”:
   1. Navigate to Security > Distributed Cloud Firewall > SmartGroups.
   2. Click + SmartGroup.
   3. Select “Hostname” 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-based SmartGroup
   3. Protocol: Specify the protocol (e.g., TCP, UDP)
   4. Port: Specify the ports (e.g., 22 for SSH, 25 for SMTP)

​

For Protocols with Known Static IP Destinations

1. Research the current IP addresses for the FQDNs.
2. Create CIDR-based SmartGroups for the static IPs:
   • Resource Type: IP/CIDR
   • IP/CIDRs: Enter the IP ranges
   • Name: Provide a descriptive name

​

Step 6: Create Catch-All Rules

• For VPCs with Stateful Firewall Default Deny: Create deny rules for those VPCs
• For VPCs with Stateful Firewall Default Allow: Create allow rules (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 (review manually)
• Global Catch-All: Create a final rule with source/destination “Any”; set to ALLOW initially, change to DENY after testing

​

Post-Migration DCF Ruleset Example

​

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 (Controller 7.2 or greater)
• Configure CIDR-based alternatives for older versions
• 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