Extending Security Domains to AWS – IPSEC

  • 27 April 2023
  • 0 replies
  • 11 views

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

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 

 

 

 

 

 


0 replies

Be the first to reply!

Reply