Security: Egress FQDN Control and Firewall

Why should base policies be same?

When you are using multiple Egress Filters and/or Security Policies on the same gateway, we program the rules into the gateway with a default setting for packets which don’t meet your specific rules. When there are different base policies being configured, the interpretation from the admin and what has been programmed into the system might vary. To avoid this misinterpretation, we do request the users to not mix the base rules and stick with all “white lists/deny all” or all “black lists/allow all” policies/base rules

Should I use Black lists or White lists for Egress FQDN Control?

White lists should specifically be used for access to applications or access to servers. If you are browsing the WEB/internet, then you should be using black lists since a lot of webpages refer or load content from other websites, or use the Discovery feature to discover the websites you are surfing and use that to configure your white lists

Which policies are executed first - egress or firewall?

The policies for 80/443 are executed first followed by the other policies. FQDN takes precedence over Stateful Firewall.

What is the egress FQDN rules limit?

  1. From 6.2.1914 onwards, one egress FQDN tag can have up to 1500 NFQ rules.
  2. NFQ rules are the rules containing TCP port 80/443 and the limit is reached if the total number of rules containing TCP port 80/443 is 1500. Other ports like 21,22 are not counted under NFQ rules
  3. You can have multiple tags in an egress FQDN filter. However, the limit of 1500 is applicable to total number of NFQ rules across multiple tags per gateway

What is the DNS dependency for Egress Control?

By default, the DNS server on the Gateways are set to, except when you have manually edited the Gateway (Controller UI > Gateway > Edit) to “Enable VPC DNS” to pick up VPC’S DNS settings (ether through DHCP Option or the default AWS VPC DNS Server)

When the egress control is enabled:

  • If you set rules only for 80/443 ports: when you enable the egress fqdn list, the gateway will check if it has access to the DNS before it will turn on the FQDN filter. If it cannot access the DNS server, it will fail this enable operation.
  • If you set rules for non-80/443: the controller will replace the gateway default DNS ( - with the Server from DHCP Options or DNS VPC Server. If the gateway cannot reach this new DNS, the enable operation on the FQDN Egress Control will fail.

If you run into these issues, please try:

  • Run diagnostics on the gateway and look for “DNS Resolution” tag.
  • Go to “Controller Web Interface > Troublshoot > Diagnostics > Network > Gateway Utility” and pick the gateway and try to ping to an FQDN and see if the name to IP resolution happens.

How can I create an Egress Control Aviatrix Gateway in Azure?

Azure’s subnets by default have an internet gateway associated. So the process is slightly different from AWS. Here are the steps:

  1. Create a subnet for your VNET. Do NOT associate any route table to this subnet. This will be your public subnet. This subnet will be used when creating the Aviatrix gateway.
  2. Create a second subnet for user instances. Create a route table and associate it with this second subnet. This will act as a private subnet like in AWS.
  3. Launch an Aviatrix Gateway in the first public subnet created in Step 1. If you need an HA, you can create it in the same subnet.

Where can I find the traffic logs for my Egress FQDN Control on my Aviatrix Gateway?

All traffic through your Aviatrix Egress Control Gateways will be logged. You can check out the logs from the Controller at “Controller/Security/EgressControl/EgressFQDNViewLog”. We recommend that you turn on external logging to send the syslogs from Aviatrix to your logging systems. Please look at the right tag for FQDN relevant logs.

What is the Egress FQDN Filter behavior on Controller 6.0+?

For Egress FQDN Filter on controller version 6.0, there is a mechanism that will sort all the FQDN rules on the same egress gateway in order by the following factors:

  1. Edit/Action: For White List, “Deny” rules comes first, followed by “Allow” rules and lastly the “Base-policy” rules.
  2. Edit/Action: For Black List, “Allow” rules comes first, followed by “Deny” rules and lastly the “Base-policy” rules.
  3. Edit/Domain: More specific domain and no wildcard(‘*’) comes first. ex: -> -> *

In 6.0, every domain access will go through this list that be sorted by these factors to see if there is a domain-match. Once the domain-match happens, it will stop checking the rest of the list, and comes out a result of “MATCH” or “NO-MATCH”.

This design certainly has some limitation when there are multiple specific rules with source filter enabled. Here is an example: the first rule is allow from and the second rule is * from Packet is from the source is not matched with first rule and the packet dropped .

Here’s improvement in latest 6.1 (R6.1.1280). When doing above FQDN rule checking for domain-match with source, it will continue to check the rest of the rules to see if there is domain-match but with different sources.

Hence, the result will be different before and after 6.1.1280 version, for example:

  • Source host is making a connection to
  • FQDN Filter Tag A: attach egress gw1 with rule A1:, Source, Base policy
  • FQDN Filter Tag B: attach egress gw1 with rule B1: *, Source, Base policy

The order of FQDN filter list for gw1 will be A1 -> B1 (Refer to above factor 3. More specific domain comes first)

Version 6.0 ~ before 6.1.1280:

Source host CAN’T access The domain “” first match rule A1 and Source is not in rule A1. => NO-MATCH

Version after 6.1.1280:

Source host CAN access The domain “” first match rule A1 and Source is not in rule A1, instead of stopping checking, in 6.1 it will continue to check other rules and find the better match rule B1 with Source => MATCH