FQDN Egress Filtering in the Cloud using Aviatrix

I hesitated before writing this blog post, as there are a lot of serious security players out there who perform this function more specifically than Aviatrix – Palo Alto, or any of the major NGFW players.

But then I realized during the recent Aviatrix / AWS Cloud Networking Immersion Day that I was looking at the context wrong.

This functionality on the Aviatrix gateway has its place in a coherent network architecture for specific design cases.

Caveat: I am only addressing a Distributed Gateway design in this post. There is a Centralized Design model which is also very powerful where egress traffic is routed to an egress VPC for filtering.

Let’s look at an example:

As you can see, we have a simple VPC with a Private and Public subnet. The Private subnet needs to get Linux patch updates or some data feeds from the internet, and therefore we require a NAT Gateway.

The NAT gateway allows all outbound traffic to the internet by default.

So, what if you want to control which sites, or more specifically, which FQDN (Fully Qualified Domain Names) you allow (or block).

In that case, you may need to build out a centralized egress VPC building block using one of the NG-FW vendors mentioned before.

However, this will be expensive and maybe over architected for your needs.

The Solution

Once again, in the context of the example we cited above, a more cost-effective solution could be to deploy an Aviatrix gateway in the VPCs that require egress filtering.

What are the advantages?

So how to we do it?

Let’s review our test environment again:

As we can see, the route-table for the subnet is pointing to the NAT-GW:

Our host is currently able to access any site on the internet.

As you can see here, we perform a number of CURL commands to verify this connectivity:

Configure FQDN Egress Filtering

Let’s hop onto the Aviatrix controller and begin by deploying a new gateway in the VPC in question:

As you see, the gateway is deployed in the Public subnet, in the same way that the NAT-GW is deployed.

At this stage, nothing else has been modified, only the deployment of the gateway.

Now we move to the Egress Control section, on the controller, to create a policy.

A useful, optional, process is to perform test filtering to see which internet sites are currently being accessed. Simply select the gateway in question and click start:

When we press start, an amazing thing happens behind the scenes. The Private Subnet Route Table is automatically updated to send traffic through the Aviatrix gateway (rather than the NAT-GW):

We end up with a design like this:

As we run a few CURLs from the Linux host in the Private Subnet, we can see the results of the discovery:

As soon as we stop the discovery, the Private Subnet Route Table is automatically reconfigured with the NAT gateway setting. Everything is as it was before.

Defining the Policy

Now we can define a security policy (called a Tag, for some reason):

Above, we explicitly allow traffic to amazon.com and implicitly deny all other traffic.

We must then click on ENABLE to activate the policy. This will once again configure the Private Subnet Route Table to use the Aviatrix gateway instead of the NAT GW.

Let’s test with some CURLs on the Linux box:

Facebook is timing out.

Twitter also

But Amazon is fine.

The policy can be disabled at any time by simply clicking on the STATUS slider next to the Tag.

FQDN Stats

One of the most fantastic parts of this is the statistics, however, since I am running this in a lab, I don’t have very interesting results. But, after running for a while in production, you will get some nice charts on allowed and denied traffic.

Here is what it could look like:

Powerful stuff for a relatively cost-effective design.

Let me know if you need any support on this.