Why is Egress Control Filter needed?


For Internet bound egress traffic, specifying outbound policy at IP address level is not sufficient as the domain names of a site can be translated to many different IP addresses.

AWS NAT gateway does not offer security group function; it relies on security groups by each instance. AWS NAT instances’ security group does not have enough entries to support the large set of IP address list. The egress filtering needs to happen at Layer 7.

On the other hand, workloads in AWS are mostly applications or programs where it is deterministic which outbound APIs the application program calls. For example, an application runs API queries to for data retrieving and runs API queries to for app authentication. In these cases, making sure that only these sites are allowed for egress traffic is sufficient from security point of view. Note this is very different from on-prem situations where end user traffic and application traffic are mingled together; you may need a full fledged firewall for Internet bound traffic.

Another use case is for PCI DSS compliance. PCI DSS 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.

What does the Aviatrix FQDN feature do?

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

Aviatrix FQDN filters any TCP and UDP traffic including HTTP, HTTPS and SFTP traffic. The filtering function allows only the destination host names (whitelist) specified in the list to pass and drop all other destinations.

Each destination is specified as fully qualified domain name. For example, if you only allow Internet bound traffic to, you can list the domain name in the whitelist.

For HTTP/HTTPS (TCP port 80/443), FQDN feature also supports wild card, such as *. In this example, you can specify * to allow traffic to any domain names that ends in “”.

How does it work?

The function is transparent to individual instances and is carried out inline without requiring any certificate or keys to decrypt the traffic.

non-HTTP/HTTPS traffic can also be filtered based on exact domain names. Use cases are secure file transfer (SFTP) to external sites, secure login in (SSH) to external sites.

A tag is defined as a list of FQDNs and it is created and managed on the Controller console. One or more gateways may be attached to a tag; each gateway can be attached to more than one tag. Any updates to a tag on the Controller automatically triggers updates to all gateways attached to the tag.

Multiple tags can be defined for the Controller. The domains in the tag are the destinations that are allowed for traffic to pass.

For configuration details, refer to this doc.

How to Enable HA for FQDN gateways?

Go to Gateway page, highlight the gateway, and click Edit.

At “Gateway for High Availability Peering”, select a public subnet in the drop down menu, click create. A backup gateway with the name extension -hagw will be created. Note this takes a few minutes of time.

For FQDN function, the primary gateway and backup gateway load balance the Internet bound traffic from different subnets based on route table.

How does Aviatrix Egress FQDN compare to Squid Solution?

Squid is a popular open source software that can be configured to do transparent HTTP/HTTPS filtering. Squid does not process non HTTP/HTTPS traffic. For example, if you need to filter on a SFTP site that runs on TCP port 22, Squid does not work. Below is a more comprehensive comparison between Aviatrix FQDN and Squid.

Functions Aviatrix FQDN Squid
HTTP and HTTPS FQDN filter Yes Yes
non HTTP/HTTPS FQDN filter Yes No
Multi AZ High Availability Yes (load balanced) No
Centrally Managed Yes No
Egress Discovery Yes No
Rest API support Yes No
Terraform support Yes No
Out-of-box log integration Yes No
Vendor support Yes No

How to Troubleshoot 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 points to the gateway instance.
  2. To verify the above step is setup properly, disable FQDN function of the problem gateway by detaching it from the associated tag, and run a ping test to 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 has Enabled button on. Make sure the Whitelist or Blacklist is selected as intended.
  4. Check the tag to make sure it has the intended URL configured.
  5. Run a “wget” test from a private instance in the VPC to an URL configured in the tag.
  6. Use “Step 4” at Egress FQDN View Log, 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.
  7. Note if a tag has “White list” option selected, all URL in the tag will be accepted. On the other hand, if a tag has a “Black list” option selected, all URL in the tag will be dropped.
  8. If none of the above works, try Disable and Enable the tag again. This will restart the FQDN function on all attached gateways.
  9. If all above steps failed, get help from aviatrix support team and upload tracelog.

How does FQDN and Stateful Firewall work together?

There are some caveats in release 3.4 when configuring Stateful Firewall and FQDN. Note the below caveats have been fixed for release 3.5.

(A non HTTP/HTTPS traffic means any TCP/UDP/ICMP traffic excluding TCP port 80/443.)

When Stateful Firewall and FQDN are both enabled, Stateful Firewall rules are executed before FQDN for non HTTP/HTTPS traffic.

Service Stateful Firewall base rule Deny All Stateful Firewall base rule Allow All
FQDN Whitelist for HTTP/HTTPS Work independently. Work independently.
FQDN Whitelist for non HTTP/HTTPS Do not work independently, see Note 1 Do not Work independently, see Note 2

Note 1:

There are two options to work around the issue:
  • Option 1: For non-HTTP/HTTPS traffic, do not use FQDN Whitelist. Use Stateful Firewall instead.
  • Option 2: On the Stateful Firewall page, change the base rule to “Allow all” (do not change individual rules). This is because the FQDN is executed after Stateful Firewall for non HTTP/HTTPS traffic, therefore even if you specify “Allow all” as base rule, the FQDN whitelist will only permit the rules specified both in Stateful Firewall and FQDN. FQDN Whitelist has an implicit “DROP ALL” as its last rule.

Note 2:

This is an expected behavior. If Stateful Firewall rule base is “Allow all”, the individual rules are “Deny” and FQDN is a whitelist, then FQDN’s last implicit rule “DROP ALL” will effectively make the gateway to be a “Deny all” for any destinations the Stateful Firewall does not specify.

What happens if I enable FQDN and there are route tables that have an existing default route?

When enabling egress filtering on a VPC, each subnet’s route table is reviewed. If there is an existing default route ( in the route table, the following logic is used:

Target Aviatrix action
igw-* Ignore this route table
anything other than igw-* Update the Target to point to the AVX GW ENI and remember the current value of Target. (see note below)


If the Gateway is detached from the VPC (via the egress configuration page), the route table will be updated with the original values.