Extending Security Domains to AWS – part 1 – IPSEC

I started my network education as junior security engineer. Good old times when configuring PIX firewalls. I was dealing with VPNs, ACLs mostly and that was it. On one of the interview these days, I had a question which I failed to answer – that is why I still remember it :). “What is the most robust way of defending yourself against malicious traffic?”. I was young and still learning (hmm that never stopped actually) and my answer was: of course apply ACL. I was not thinking that time about traffic isolation with help of VRFs / Routing / black holing … But surprise surprise it is still being used as a very good and simple way of achieving that.

On Aviatrix ACE Pro (which BTW I encourage everyone to take), one of the module is “Multi-Cloud Network Segmentation”.

To make it short:
we are classifying spokes in security domains and isolate these domains from each other. That can be extended to multi-cloud, on-prem, vpn. (More details)

Let’s focus on AWS TGW today…
There is also feature called “TGW Orchestration” which allows Aviatrix controller to program TGW and manage its RTB and also utilizing these security domains. It is pretty powerful but has one big limitation – we are able to extend segmentation only to EDGE transit domain. So if you peer this Transit to another Aviatrix transit pair in a different CSP you will not see them. That’s why we are going to build it differently – by defining Connections between Aviatrix Transit and AWS TGW. With Connection definition we can extend it further and fully utilize potential given with MCNA (Multi-Cloud Network Architecture) by Aviatrix. Sometimes you just might not be the owner of TGW and you just need to do it that way.

Desired Topology

When defining connection you need to be aware how Aviatrix Gateways are actually building it. Usually both of them are trying to establish connection to whatever remote IP you define. Please take a look on the following examples:

Connection OPTION 1

This is typical configuration where you want full mesh and you can see both Transit GW build x2 tunnels for each one of the Remote Gateway IP.

Connection OPTION 2

Here you can see that we broke the rule of full mesh and we specify that primary Transit GW builds connection to pub_IP1 and HA GW builds second connection to pub_IP2.

Knowing that, lets define our AWS TGW’s peers and specific connections
MULTI-CLOUD TRANSIT -> STEP 3 -> External Device -> BGP/IPSEC
Due to the fact that in AWS we can specify only 1 IP as Peer (CGW – customer gateway) we need to follow option2. Otherwise 2nd Aviatrix Gateway would try to establish another tunnel which will never be up (dummy tunnel). The example should look like this:

Repeating this step for all 4 connections and we have the following (we can list them under SITE2CLOUD -> Setup):

Let’s check BGP … (after all configuration is done Aviatrix and AWS)

AWS TGW configuration

With the concept of individual RTB per DEV and PROD we already achieved the isolation.

Aviatrix segmentation

Let’s define our security policy. The workflow for domain segmentation is very easy.

Enable Segmentation

Create Domains

Define Policy
Our 2 domains (RED, BLUE) should not talk to each other so nothing under Connected.
If we had “Shared Services” VPC we could define such and put as “Connected” under each.

Associate “Attachment” to domain

Complete list of all Attachments per Domain:

Testing connectivity

Investigating the path we can see traffic going through our Tunnel and each one of the Aviatrix Gateway.

Copilot - view

Copilot is really powerful tool for day 2 operations. One of it’s key benefit is Topology MAP which is dynamically generated based on Controller’s data read from individual CSPs.

Here you can see:

Transit Gateways deployed in HA mode
1 spoke for PROD environment
1 spoke for DEV environment
all x4 connections towards TGW with x2 tunnels per each connection
latency on each one of the IPSEC tunnel – that is handy

Additionally we can verify Security policy and confirm which “Security attachment” is allowed to talk with the rest (it even says what type of node it is: Spoke or Site2Cloud). BTW I’m not daltonist – could have named segmenets better though 🙂

Infrastructure as Code

The whole configuration I built with Terraform for many reasons – as exercise 🙂 mainly. But I encourage all to test it out and see how easy automation is especially for Aviatrix part. If you compare the code needed to deploy AWS piece to Aviatrix – you will see the difference is huge.

Summary

For me the key lesson of this exercise was to learn how to define CONNECTION with option of splitting it into 2 separate destinations per Aviatrix GWs. Before knowing that there was a workaround of defining “dummy” tunnels which was ugly and cumbersome. We easily extended Security domain to native TGW in AWS so we can leverage fully that isolation , also if needed we can add more connections and increase the throughput required.