Aviatrix-Episode2: Aviatrix & AWS Cloud WAN compatibility & segmentation

The idea of that post came from an Aviatrix announcement..  I must admit I did not know till this official announcement.. 😅

When I read it, it looks pretty very promising, meaning: Aviatrix + AWS Cloud WAN =

The compatibility includes:

• Aviatrix integrates with AWS Cloud WAN using GRE encapsulation (AWS Cloud WAN Connect Attachment) and/or  IPSEC encryption (AWS Cloud WAN S2S VPN attachment)

• Network Segmentation between Aviatrix & AWS Cloud WAN is possible with each AWS Cloud WAN attachment being part of an Aviatrix Network Domain (aka segment)

• Use Cases

• High Performance Encryption between AWS Cloud WAN & another Public Cloud

• AWS Cloud WAN Segments can be extended to other Public Clouds using Aviatrix MCNS (Multi Cloud Network Segmentation). Each AWS Cloud WAN attachment being part of a specific segment. (micro segmentation is also possible)

• IPSEC encryption to On Prem with Secure Edge

• Overcoming IP overlapping challenges (with MAPPED NAT) 

• Cyber Threat Protection of workloads being behind AWS Cloud WAN  

AWS Cloud WAN - Aviatrix Architecture

NOTE: I cannot test every single use case. And I must tell you the truth: I am super excited about testing one (and only) specific use case listed above: SEGMENTATION!    

The rationale behind is fairly simple.. AWS Cloud WAN is the AWS feature about Regions communication but most of all segmentation across AWS Cloud infrastructure. 

NOTE: for precise explanation about AWS Cloud WAN, please read my blog.

So, let's configure AWS Cloud WAN connected to Aviatrix via the 2 techniques (GRE & IPSEC) with 2 specific segments (DEV & PRD). 

• DEV segment via GRE

• PRD segment via IPSEC

The final goal is that these 2 segments in AWS Cloud WAN can communicate to 2 same segments in Azure via Aviatrix infrastructure.

VM DEV must communicate with EC2 DEV & VM PRD must communicate with EC2 PRD - Nothing else - The rest of communication between Azure & AWS or within the same Public Cloud is prohibited.

Pre requisites

• Aviatrix Controller & Copilot are already installed (see Episode1)

• All VPCs & VNETs are already configured

• All Aviatrix GWs are already configured + attached + Transit Peering + Connected Transit (see Episode1)

• All VMs & EC2 are already configured

NOTE: Oh! BTW, I create all VPCs & VNETs from Aviatrix Controller - easier & configures everything for me (like AWS IGW needed for accessing EC2 instances from Internet).

Preliminary AWS Cloud WAN configuration

Step1: Create Global Network

Step2: Create Core Network & Primary Segment (DEV)

Step3: Create Attachments for DEV & PRD VPCs

NOTE: Don't forget the TAG, it is very important for the Attachment policies further in the configuration.

Step4: Add Static routes in VPC RTs to 10/8 towards the CNE

Step5: Create New Segment (PRD)

Step6: Create Attachment policies for DEV & PRD

We can see in the attachment policy rules that key/value pairs are used as attachment condition. It retakes the Tag configured when attachments have been created in Step3.

Step7: Ensure that the policy is configured as below

• CNE must have its ASN

• Inside CIDR block must be configured. It is mandatory to configure Connect (GRE) Attachment later. This CIDR contains the outer IPs of the GRE Tunnels. (minimum /16)

AWS Cloud WAN Configuration for GRE & IPSEC attachments 

GRE connection for DEV Segment

GRE can only be done over Private IP@. (as we have to specify the Inside CIDR block).

1. Transit VPC Attachment creation

This step is needed in order that the CNE can communicate with Transit VPC to form the underlay of GRE tunnels. (10.0.0/23 [Transit VPC] must communicate with 10.10.0.0/16 [Inside CIDR block of the CNE])

2. Connect Attachment creation

• Connect Attachment = GRE

• The Transport Attachment must be a VPC attachment (in our case, this is the Transit VPC attachment)

3. Connect Peer creation

This step is needed to setup BGP over GRE between Transit GW & CNE.

• Peer GRE address is the Private IP address of the Aviatrix Transit Gateway (eth0)

• Configure a CIDR for BGP neighborship (it must be 169.254.X.Y/29 but X must be different than 1, 2, 3, 4, 5 and X.Y must be different than 169.248)

• Peer ASN (Aviatrix Transit GW ASN)

4. Adding Static route

The CNE Inside Block must be reachable from the Transit VPC. Therefore the following route must be added towards the Core Network.

IPSEC connection for PRD Segment

The S2SVPN must be created on top Public IPs part of the AWS Backbone.

1. S2SVPN Creation

• Target GW must be set to 'Not associated' for Cloud WAN

• CGW creation with Public IP@ of Aviatrix Transit GW in AWS Transit VPC

• Pre Shared Key also manually configured (not shown in screenshot)

2. IPSEC Attachment Creation

• Attachment type must be VPN

• VPN id must be the S2SVPN previously created

AVIATRIX Configuration

GRE

• Remote GW IP must be the CNE GRE @ (Private IP created during Connect Peer creation). If HA is selected here, a second Connect Peer must be created @AWS side. [for the purpose of my test only one has been created)

Again there is a different implementation regarding the GRE tunnels. Aviatrix mapping is 1to1 whereas AWS mapping is 2to1, meaning that the 2 GRE tunnels of the same Connect Peer are initiated from the same 169.254.X.Y IP@ (Aviatrix side) to 2 different 169.254.X.Y IP@ (AWS side). Therefore always 1 of the 2 GRE Tunnels of a Connect Peer will remain DOWN. [because of it, the second Local IP@ above is a fake one]

IPSEC

• Remote GW IP must be the 2 Public IPs created with S2SVPN. (only one depicted above)

• Local Tunnel IP / Remote Tunnel IP must be Inside IPv4 CIDR created with the S2SVPN for the first Local & first remote. The second Local/Remote is a fake one because Aviatrix and AWS are not configured the same way. [because both AWS S2SVPN tunnels end to Customer GW, which is a single Public IP, ie Public IP of primary Aviatrix Transit GW]. If I wanted to have the 4 IPSEC Tunnels from Aviatrix working, I should configure a second AWS S2SVPN with Customer GW = Public IP of HA Aviatrix Transit GW.

AWS shows VPN tunnels are UP. 

Aviatrix shows VPN Tunnels are UP.

We can see above that only the IPSEC tunnels from Aviatrix Primary Transit GW are up as explained previously.

AWS Cloud WAN Dashboard Visualization after all configuration above

• The 2 IPSEC Tunnels are up to Primary Aviatrix Transit GW (as explained, they both end to same CGW, ie a single Aviatrix GW. There is no IPSEC then configured to Aviatrix HA Transit GW).

• A single GRE tunnel is operational as explained above. 
• during Connect Peer configuration, a single Remote Peer IP was allowed to be configured). It means that the 2 GRE tunnels above end to Aviatrix Primary GW also.
• GRE mapping between AWS and Aviatrix being different, always a single GRE of the Connect Peer can be UP.

Aviatrix Copilot View - Topology Network Map

As explained previously, no GRE or IPSEC tunnels from/to Aviatrix HA Transit Gw because additional configuration would be needed in AWS side.

Aviatrix Segmentation configuration

The Aviatrix Segmentation configuration is a 4-step process.

1. Enable AWS & Azure Aviatrix GWs for Segmentation

2. Create DEV & PRD Segments (aka Network Domains)

3. Step3 should have been Connection Policy to allow communication between DEV & PRD Segments but this is not foreseen for the purpose of our test. We skip that step.

4. Associate Spoke or S2C to Network Domain

4 associations needed:

• Azure respective VNETs to DEV & PRD

• AWS to S2C DEVGRE to DEV & PRDIPSEC to PRD

Aviatrix Copilot Visualization of the Segmentation

We can see the 2 Network Domains (DEV & PRD), as well as what is part of each segment: 1 VNET per segment (in Azure) & 1 S2C per segment (DEVGRE in DEV & PRDIPSEC in PRD).

AWS Cloud WAN visualization - Logical

We can see that the Transport VPC Attachment for GRE as part of the DEV segment.

Routes visualization on Cloud WAN

We can see in PRD Route Table that PRD segment in Azure has been propagated via BGP.

TESTING!!

Ping from PRD EC2: ping to PRD VM OK & ping to DEV VM NOK

Ping from DEV EC2: ping to PRD VM NOK & ping to DEV VM OK

BOTTOM Line

• First of all, the integration between AWS Cloud WAN & Aviatrix works perfectly. Even the segmentation towards AWS Cloud WAN & Aviatrix (located onto another Public Cloud: Azure) is perfectly operational.

• Second thing, I have spent almost 2 days trying to configure GRE on AWS Cloud WAN: that was tough! The good thing is that now you have the screen shots to make it easily.👍

• GRE attachment
• difficult setup (inside CIDR block, VPC Attachment for Transport é Connect Attachment for GRE, Connect Peer for BGP, Static routes to CNE)
• Higher Bandwidth per attachment than IPSEC
• Relies only on Private IPs for the underlay

• IPSEC attachment
• Easy setup but still needs CGW & S2SVPN constructs
• Lower Bandwidth than GRE
• Relies only on Public IPs for the underlay
• Use it if you also need encryption for your data in-transit

Next episodes foreseen in August:

Episode3: Connecting OnPrem Remote site to Aviatrix Cloud infrastructure via BGPoIPSEC   (incl. BGP route approval)

Episode4: Embedded L4 Stateful FWs on Aviatrix GWs

Episode5: All you need to know about Aviatrix FQDN Filtering - Design Patterns

Episode6: Aviatrix Copilot Tour (including Cyber Threat Protection with ThreatIQ/ThreatGuard)

Episode7: How to spin up a fully resilient multicloud environment in minutes with Terraform