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.
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.
Let’s define our security policy. The workflow for domain segmentation is very easy.
Complete list of all Attachments per Domain:
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.
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.