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 GW | Landing Spoke GW | Transit GW | Prod Spoke GW | Azure Client | |
| SIP | 172.31.0.10 | 100.65.0.10 | 100.65.0.10 | 100.65.0.10 | 100.65.0.10 |
| DIP | 100.97.64.36 | 10.100.64.36 | 10.100.64.36 | 10.100.64.36 | 10.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 Client | Prod Spoke GW | Transit GW | Landing Spoke GW | Aviatrix Standalone GW / AWS Client | |
| SIP | 10.100.64.36 | 10.100.64.36 | 10.100.64.36 | 10.100.64.36 | 100.97.64.36 |
| DIP | 100.65.0.10 | 100.65.0.10 | 100.65.0.10 | 100.65.0.10 | 172.31.0.10 |
Launch Aviatrix Standalone GW in AWS Default VPC
- Follow https://docs.aviatrix.com/HowTos/aviatrix_account.html to onboard your AWS account that contains the default VPC
- 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
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
- Aviatrix understood and dynamically updates route tables on multiple clouds
- Aviatrix provides day 2 operation visibility and troubleshooting tools.
- Aviatrix removes the skill gap to manage multi-clouds
- No longer need to pay expensive appliance licensing
- Aviatrix manages the failover of tunnels