Enable private connectivity to workloads deployed in multiple default VPCs – Part 2


Scenario: One of our customers are primary in Azure, after merger and acquisitions, them acquired hundreds of AWS accounts, where workloads are deployed to default VPCs, which all have this address space: 172.31.0.0/16

They are looking for a solution to provide bi-directional private connectivity to these workloads in AWS from Azure without overhead of route management, also provide visibility to the traffic.

Here below is the proposed solution:

In above diagram, Azure workloads are deployed in spoke vNets, these spoke vNets are attached to hub Transit FireNet and are fully routable.

USEProdApp1Priv is deployed in private subnet.

USEShared1Pub have an EIP that we can SSH to.

Azure side have a summarized real CIDR of 10.100.0.0/16

AWS side top right corner, account1, we would use a Cisco CSR 1000

AWS bottom right corner, account2, we would use a standalone Aviatrix Gateway

Let’s take a look at the differences between Cisco CSR and Aviatrix Gateway


Part 2 – Aviatrix Standalone GW to Aviatrix Spoke GW mapped NAT configuration

Testing environment:

Aviatrix Controller: 6.6.5545
Aviatrix Gateways: 6.6.5545

Since bi-directional traffic is needed, in this configuration, IPs have one to one mapping.

Azure side real CIDR: 10.100.0.0/16, we will use 100.97.0.0/16 for it’s virtual CIDR.

AWS side will use virtual IP: 100.97.64.36, when tries to reach Azure side real IP: 10.100.64.36

Traffic flow from AWS side to Azure side, note NAT happens on Landing Spoke Gateway. (SIP = Source IP, DIP = Destination IP)

AWS Client / Aviatrix Standalone GWLanding Spoke GWTransit GWProd Spoke GWAzure Client
SIP172.31.0.10100.65.0.10100.65.0.10100.65.0.10100.65.0.10
DIP100.97.64.3610.100.64.3610.100.64.3610.100.64.3610.100.64.36

AWS side real CIDR: 172.31.0.0/16, we will use 100.65.0.0/16 for it’s virtual CIDR.

Azure side will use virtual IP: 100.65.0.10, when tries to reach AWS side real IP: 172.31.0.10

Traffic flow from Azure side to AWS side, note NAT happens on Landing Spoke Gateway. (SIP = Source IP, DIP = Destination IP)

Azure ClientProd Spoke GWTransit GWLanding Spoke GWAviatrix Standalone GW / AWS Client
SIP10.100.64.3610.100.64.3610.100.64.3610.100.64.36100.97.64.36
DIP100.65.0.10100.65.0.10100.65.0.10100.65.0.10172.31.0.10

Launch Aviatrix Standalone GW in AWS Default VPC

  1. Follow https://docs.aviatrix.com/HowTos/aviatrix_account.html to onboard your AWS account that contains the default VPC
  2. Create standalone gateway in this AWS account, select the region, default vpc and a public subnet

3. Once the GW created, select it, and click on EDIT

4. Select 2nd public subnet in default VPC, then Create HA gateway

5. Confirm both stand alone gateways are up, and record down their public IPs

Create Site to Cloud connection using Mapped NAT in Aviatrix Controller

Goes to Aviatrix controller web page, SITE2CLOUD -> Setup -> 2 Create a New Site2CloudConnection -> ADD NEW

VPC ID/VNet Name : Select Landing vNet
Connection Type: Mapped
Connection Name: This is the name used for Aviatrix to track the Site2Cloud connection
Remote Gateway Type: Aviatrix
Tunnel Type: Route Based
IKEv2: Enabled by default
Enable HA: Checked as we do have two gateways deployed for HA

Primary Cloud Gateway: Select Aviatrix Landing GW
Remote Gateway IP address: Enter standalone GW public IP
Backup Gateway: Select HA Aviatrix Landing GW
Remote Gateway IP Address (Backup): Enter standalone HA GW public IP

Remote Subnet (Real): 172.31.0.0/16
Remote Subnet (Virtual): 100.65.0.0/16
Local Subnet (Real): 10.100.0.0/16
Local Subnet (Virtual): 100.97.0.0/16

Click OK to create the Site2Cloud connection

Configure S2C for Stand Alone Gateways

Select the newly created Site2Cloud connection, and click on Edit button

This image has an empty alt attribute; its file name is image-9-1024x109.png

Under Connection Detail:

Vendor: Aviatrix
Platform: UCC
Software: 1.0

Click on DOWNLOAD CONFIGURATION

Record default VPC ID from AWS

Site2Cloud -> Setup -> Add new -> Select Default VPC by VPC ID

Import -> Select the configuration file

! ! ! Make sure to change Connection Type from Mapped -> to Unmapped ! ! !

Reverse connection name, eg: From LandingAWSDefaultVPC1 to AWSDefaultVPC1Landing

Make sure to pick the correct gateway for primary and HA

! ! ! Make sure enter Azure side virtual CIDR 100.97.0.0/16 as Remote Subnet ! ! !

Click OK to create unmapped S2C connection from stand alone gateways back to Landing spoke gateways

Validate the connections are up

If the connections don’t come up in a few minutes, you can go to SITE2CLOUD -> Diagnostics -> Select the connection -> Action: Run analytics or Show Logs

If you have CoPilot deployed, then you can observe the Site2Cloud Connections are active/standby, and Aviatrix Controller monitor and take care of fall over

Observe route tables in Azure vNets

It’s worth to note that Aviatrix inject RFC1918 routes into spoke subnets route tables pointing to Aviatrix Spoke Gateways, this steers all traffic towards transit.

In the Landing vNet, since we just created a Site2Cloud connection with static route, Aviatrix controller is aware of this intention and programed AWS virtual CIDR 100.65.0.0/16 point to Aviatrix Spoke Gateway in Landing vNet

Then how do we get traffic to other connected spoke vNet or even across transits? Note below, Prod spoke vNet only have RFC1918 routes added, and 100.65.0.0/16 is missing:

Allow Site2cloud connection to be accessible across transit

  • Select newly created Site2Cloud connection, and click on Edit button:

Scroll and Enable Forward Traffic to Transit Gateway

  • Aviatrix Controller -> MULTI-CLOUD TRANSIT -> List -> Spoke -> Select primary Landing Gateway -> ACTIONS -> Auto Advertise Spoke Site2Coud CIDRs

When you click on Enable, you should see 100.65.0.0/16 is been advertised now, since it’s part of landing spoke Site2Cloud CIDRs

Check Prod vNet route table again, and you can see that 100.65.0.0/16 gets added by Aviatrix controller pointing to Prod Spoke Gateway

Let’s pause for a sec, think how many routes you have in your cloud environment? For changes like this, how many entries you will have to update either manually or by script? How do you ensure future vNets/subnets won’t missing route? What if you need to quickly resolve M/A onboarded 100+ AWS accounts using default VPC?

Observe route table on AWS side

Search route table by Default VPC ID, and we noticed that Aviatrix Controller inserted 100.970.0/16 pointing to ENI of the Standalone Gateway.

Test Connectivity

From a test VM in AWS 172.31.3.115

ping Azure VM USEShared1Pub 10.100.100.4 using virtual IP: 100.97.100.4
ping Azure VM USEProdApp1Priv 10.100.64.36 using virtual IP: 100.97.64.36

From Azure VM USEShared1Pub 10.100.100.4 ping test VM in AWS 172.31.3.115 using virtual IP: 100.65.3.115

From Azure VM USEProdApp1Priv 10.100.64.36 ping test VM in AWS 172.31.3.115 using virtual IP: 100.65.3.115

Day 2 operations and visibility

From any gateway, you can perform ping and traceroute

Gateway /VPC routes are easily searchable for any cloud

Have netflow across clouds for evidential data

Comparison with CSR

  1. Aviatrix understood and dynamically updates route tables on multiple clouds
  2. Aviatrix provides day 2 operation visibility and troubleshooting tools.
  3. Aviatrix removes the skill gap to manage multi-clouds
  4. No longer need to pay expensive appliance licensing
  5. Aviatrix manages the failover of tunnels

Leave a Reply

Your email address will not be published.