Multi Cloud Network Architecture

Building Networking Skills in the age of the Cloud

Multi Cloud Network Architecture

FQDN Egress Filtering in the Cloud using Aviatrix

Share on linkedin
Share on twitter
Share on email

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?

  • Cost-effective footprint – the Aviatrix gateways can be deployed on T2-Micro devices for example. This is not an issue as it is only serving outbound internet access for, let’s face it, non-time-sensitive updates or processes.
  • Fully HA – Aviatrix gateways can be deployed across AZs resulting in a highly resilient design
  • Automated insertion – no route tables to modify on the CSP
  • Centralized management – the Aviatrix controller allows you to define an apply policies
  • Granular policy management – define separate policies for PROD / DEV environments.
  • Multiprotocol – Policies are not only for HTTPS / HTTP traffic. Filter options are very granular
  • Detailed reporting – The level of reporting is very impressive

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 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:

LAB4 – GCP FQDN Based Egress Security | netJoints

Powerful stuff for a relatively cost-effective design.

Let me know if you need any support on this.

Share if you liked it
Share on linkedin
Share on twitter
Share on email
0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments

20 year veteran of the networking industry currently specialising in Cloud Networking and Security.

CCIE #16661 (R&S, SP)


I am currently an employee of Aviatrix. All opinions, views and statements are my own and do not reflect that of my employer. Any errors are mine and mine alone. Any ignorance is mine, though I do believe my parents and the public school system should shoulder some of that blame. 

Recent Posts