Egress FQDN Filtering (Legacy)

Egress FQDN Filtering is a security feature available in the Aviatrix Controller prior to Controller version 7.1. This feature is designed to filter Internet-bound egress traffic initiated from workloads in a VPC/VNet by specifying fully qualified domain names (FQDNs) that are allowed or denied.

Aviatrix strongly recommends migrating to the Distributed Cloud Firewall feature in CoPilot to enforce Egress network security policy, as it is the recommended method for configuring and implementing Egress Security from Controller version 7.1 onwards.

Why Egress FQDN Filtering is Needed

For Internet-bound egress traffic, specifying an outbound policy at the IP address level is not sufficient, as the domain names of a site can be translated to many different IP addresses. An NAT gateway does not offer security group functions and relies on security groups from each instance, which do not have enough entries to support large sets of IP address lists. Therefore, egress filtering needs to happen at Layer 7.

Workloads in AWS are mostly applications or programs where it is deterministic which outbound APIs the application program calls. For example, an application may run API queries to http://www.salesforce.com for data retrieval and to http://www.google.com for app authentication. Ensuring that only these sites are allowed for egress traffic is sufficient from a security point of view. This is different from on-prem situations where end-user traffic and application traffic are mingled together, requiring a full-fledged firewall for Internet-bound traffic.

Another use case is for PCI DSS compliance, which specifies that if you handle any payment and sensitive data, there must be firewall policy enforcement at the egress. In the cloud, the logical egress point is per VPC/VNet.

How Egress FQDN Filtering Works

Aviatrix Fully Qualified Domain Name (FQDN) Filtering is a security service specifically designed for workloads or applications in the public cloud. It filters Internet-bound egress traffic initiated from workloads in a VPC/VNet. This service is centrally managed by the Controller and executed by an Aviatrix Gateway instance in the VPC/VNet in the distributed architecture.

The FQDN Filtering feature allows only the destination host names specified in the list to pass and drops all other destinations. Each destination is specified as a fully qualified domain name. For example, if you only allow Internet-bound traffic to http://www.salesforce.com, you can list the domain name http://www.salesforce.com in the whitelist. For HTTP/HTTPS (TCP port 80/443), the FQDN feature also supports wild cards, such as *. For example, you can specify *.salesforce.com to allow traffic to any domain names that end in "salesforce.com".

The function is transparent to individual instances and is carried out inline without requiring any certificates or keys to decrypt the traffic 9. Non-HTTP/HTTPS traffic can also be filtered based on exact domain names. Use cases include secure file transfer (SFTP) to external sites and secure login (SSH) to external sites.

Configuration Workflow

The instructions below assume there is already an Aviatrix Gateway running in the VPC/VNet where you wish to deploy the FQDN filter. If not, follow the Egress FQDN Filter workflow to first launch a gateway.

Adding a New Egress FQDN Filter Tag to a Gateway

  1. In the Controller, go to Security > Egress Control and click New Tag.

  2. Click + New Tag, and enter a name for the tag, for example, prod-whitelist.

This procedure effectively turns the selected gateway into an FQDN Gateway.

Adding More Tags

Repeat the previous steps to create more tags and attach them to the same gateway or different gateways. However, if multiple tags are attached to the same gateway, then the mode (Allow or Deny) must be identical.

Adding a URL List to the New Tag for Egress FQDN Filter

  1. Enable the new tag and click Edit.

  2. Click + Add New to add each URL. A wildcard is allowed for HTTP/HTTPS (TCP 443).

The Update action saves the rules in the tag. If gateways are attached to the tag, "Update" applies to the rules in the gateways.

Base Policy for Egress FQDN Filter

Base Policy is an Action field of a rule and is the only value supported for rules not on ports 80 or 443.

The default Action field is Base Policy which means if the tag is an Allow (which is the majority of the use cases), this specific rule allows the domain name to pass. For the most part you should not edit this field.

  • If you are configuring FQDN Allowlist rules, set the Base Policy to Deny All.

  • If you are configuring FQDN Denylist rules, set the Base Policy to Allow All.

Attaching to Gateways in the Egress FQDN Filter

  1. Click Attach Gateway to attach a gateway to the tag.

  2. When a gateway is attached to a tag, the gateway in the tag will be pushed for enforcement (Whitelist or Blacklist).

  3. Repeat this step if you have more gateways to attach to this tag.

Exception Rule for Egress FQDN Filter

Exception Rule is a system-wide mode that only applies to Allowlist. By default, the Exception Rule is enabled. When enabled, packets passing through the gateway without an SNI field are allowed to pass. When disabled, packets passing through the gateway without an SNI field are dropped unless the specific destination IP address of the packet is listed in the Whitelist.

To disable the Exception Rule:

  1. Under Egress FQDN Filter, click Global Configs.

  2. Clear the Exception Rule checkbox.

  3. Click Close to save the changes.

Exporting and Importing Egress FQDN Filtering Rules

Export allows you to download the configured FQDN rules on a per tag basis, in a human-readable text file format.

Import allows you to upload a text file that contains FQDN rules to a specific tag. The text file can be:

  • The downloaded file from FQDN Discovery.

  • The downloaded file from FQDN Export, from a different tag.

  • A text file in the format compatible to FQDN Export.

Edit Source for Egress FQDN Filter

Edit Source allows you to control which source IP in the VPC/VNet is qualified for a specific tag. The source IP can be a subnet CIDR or host IP addresses.

If Edit Source is not configured (i.e., no source IP address ranges are selected) all packets arriving at the FQDN gateway are applied to the filter tag. However, if there are one or more source IP address ranges selected, any packets with source IP addresses outside those ranges are dropped.

Enabling and Disabling Private Network Filtering for Egress FQDN Filter

This is a global configuration that applies to all FQDN gateways. By checking this option, destination FQDN names that translate to private IP address range (RFC 1918) are subject to the FQDN whitelist filtering function. If this option is not checked, packets with destination IP address of RFC 1918 range are not inspected.

  • Enabling: Destination FQDN names that translate to private IP address range (RFC 1918) are subject to the FQDN whitelist filtering function.

  • Disabling: Packets with destination IP address of RFC 1918 range are not inspected.

To configure this option:

  1. In the Aviatrix Controller go to Security > Egress Control > Global Configs > Enable Private Network Filtering. FQDN names that are resolved to private IP address ranges (RFC 1918) are subject to the FQDN whitelist filtering function.

Customizing Network Filtering for Egress FQDN Filter

This is a global configuration that applies to all FQDN gateways.

When this option is selected, you can customize packet destination address ranges not to be filtered by FQDN.

To configure:

  1. In the Aviatrix Controller, go to Security > Egress Control > Global Configs > Customize Network Filtering.

  2. Select pre-defined RFC 1918 range, or enter your own network range.

The feature is disabled by default.

FQDN Name Caching in Egress FQDN Filter

This is a global configuration that applies to all FQDN gateways. It is enabled by default.

When this option is enabled, the resolved IP address from the FQDN filter is cached. If a subsequent TCP session matches the cached IP address list, the FQDN domain name is not checked, and the session is allowed to pass.

If FQDN Name caching is enabled, the resolved IP address from FQDN filter is cached so that if subsequent TCP session matches the cached IP address list, FQDN domain name is not checked and the session is allowed to pass.

Aviatrix recommends disabling caching to prevent unwanted domain names from bypassing filters if they resolve to the same IP address as a previously allowed domain name.

To configure this option:

In the Aviatrix Controller, go to Security > Egress Control > Global Configs > Caching and set the toggle switch to Disabled.

Exact Match in Egress FQDN Filter

This is a global configuration that applies to all FQDN gateways. It is disabled by default.

If it is not enabled, FQDN rules use regex to match any FQDN names that are a subset of the name. For example, if salesforce.com is a rule and the Exact Match option is enabled, finance.salesforce.com is not allowed. If the Exact Match option is not enabled, finance.salesforce.com is allowed.

If a FQDN rule does not show an asterisk (*) an exact match is expected.

Troubleshooting FQDN Problems

If you have problems with FQDN on a specific gateway, follow the instructions below to troubleshoot:

  1. Make sure the corresponding AWS or Azure route table has the route entry 0.0.0.0/0 which points to the gateway instance.

  2. Disable the FQDN function of the problem gateway by detaching it from the associated tag, and run a ping test to http://www.yahoo.com from an instance in the private subnet to make sure Internet egress works.

  3. Attach the problem gateway to the tag. Make sure the tag is Enabled.

  4. Make sure the Whitelist or Blacklist is selected as intended.

  5. Check the tag to make sure it has the intended URL configured.

  6. Run a wget test from a private instance in the VPC/VNet to a URL configured in the tag.

  7. Go to Security > Egress Control > Egress FQDN Gateway View.

  8. Select the problem gateway and download the log. Review the log file and analyze if the intended URL is in the log entry, why it is being accepted or denied.