Centralized Egress

Overview of Egress Control Filter

egress_overview

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; it relies on security groups by each instance. An NAT instance’s security group does not have enough entries to support the large set of IP address lists. 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 www.salesforce.com for data retrieving and runs API queries to www.google.com for app authentication. In these cases, making sure that only these sites are allowed for egress traffic is sufficient from a security point of view. Note that 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/VNet.

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 document.

How does Aviatrix Egress FQDN compare to Squid and other solutions?

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.

The table below also compares with other solutions such as AWS NAT Gateway, AWS Network Firewall, and Azure Firewall.

Functions Aviatrix FQDN AWS NAT Gateway AWS Network Firewall Azure Firewall Squid

Requires instance configuration

No

No

No

No

No

HTTP and HTTPS FQDN filter

Yes (support wildcard)

No

Yes

Yes

Yes

non-HTTP/HTTPS FQDN filter

Yes

No

No

No

No

Requires dedicated subnet

No

No

Yes

Yes

No

Multi AZ High Availability

Yes (load balanced)

Yes

Yes

Yes

No

Centrally Managed

Yes

Yes

Yes

Yes

No

Egress Discovery

Yes

No

No

No

No

API support

Yes

Yes

Yes

Yes

No

Terraform support

Yes

Yes

Yes

No

No

Out-of-box log integration

Yes

No

Yes

Yes

No

Allow specified destination to bypass filter

Yes

No

No

No

No

Allow specified source CIDR to apply to rule

Yes

No

No

No

No

Allow specified source CIDR to bypass filter

Yes

No

No

No

No

Out of box visibility on sessions

Yes

No

No

No

No

Search a specified rule match history

Yes

No

No

No

No

Vendor product support

Yes

Yes

Yes

Yes

No