{"id":77,"date":"2022-05-15T20:27:19","date_gmt":"2022-05-16T01:27:19","guid":{"rendered":"https:\/\/cloudlearning365.com\/?p=77"},"modified":"2022-10-14T09:37:49","modified_gmt":"2022-10-14T14:37:49","slug":"enable-private-connectivity-to-workloads-deployed-in-multiple-default-vpcs-part-2","status":"publish","type":"post","link":"https:\/\/cloudlearning365.com\/?p=77","title":{"rendered":"Enable private connectivity to workloads deployed in multiple default VPCs – Part 2"},"content":{"rendered":"\n

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<\/p>\n\n\n\n

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.<\/p>\n\n\n\n\n\n\n\n

Here below is the proposed solution: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In above diagram, Azure workloads are deployed in spoke vNets, these spoke vNets are attached to hub Transit FireNet and are fully routable.<\/p>\n\n\n\n

USEProdApp1Priv is deployed in private subnet.<\/p>\n\n\n\n

USEShared1Pub have an EIP that we can SSH to.<\/p>\n\n\n\n

Azure side have a summarized real CIDR of 10.100.0.0\/16<\/p>\n\n\n\n

AWS side top right corner, account1, we would use a Cisco CSR 1000<\/p>\n\n\n\n

AWS bottom right corner, account2, we would use a standalone Aviatrix Gateway<\/p>\n\n\n\n

Let’s take a look at the differences between Cisco CSR and Aviatrix Gateway<\/p>\n\n\n\n

\n\n\n\n

Part 2 – Aviatrix Standalone GW to Aviatrix Spoke GW mapped NAT configuration<\/h3>\n\n\n\n

Testing environment:<\/p>\n\n\n\n

Aviatrix Controller: 6.6.5545
Aviatrix Gateways: 6.6.5545<\/p>\n\n\n\n

Since bi-directional traffic is needed, in this configuration, IPs have one to one mapping.<\/p>\n\n\n\n

Azure side real CIDR: 10.100<\/strong>.0.0\/16, we will use 100.97<\/strong>.0.0\/16 for it’s virtual CIDR. <\/p>\n\n\n\n

AWS side will use virtual IP: 100.97.64.36<\/strong>, when tries to reach Azure side real IP: 10.100.64.36<\/strong><\/p>\n\n\n\n

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

<\/td>AWS Client \/ Aviatrix Standalone GW<\/td>Landing Spoke GW<\/td>Transit GW<\/td>Prod Spoke GW<\/td>Azure Client<\/td><\/tr>
SIP<\/td>172.31.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td><\/tr>
DIP<\/td>100.97.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

AWS side real CIDR: 172.31<\/strong>.0.0\/16, we will use 100.65<\/strong>.0.0\/16 for it’s virtual CIDR.<\/p>\n\n\n\n

Azure side will use virtual IP: 100.65.0.10<\/strong>, when tries to reach AWS side real IP: 172.31.0.10<\/strong><\/p>\n\n\n\n

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

<\/td>Azure Client<\/td>Prod Spoke GW<\/td>Transit GW<\/td>Landing Spoke GW<\/td>Aviatrix Standalone GW \/ AWS Client<\/td><\/tr>
SIP<\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>10.100.64.36<\/strong><\/td>100.97.64.36<\/strong><\/td><\/tr>
DIP<\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>100.65.0.10<\/strong><\/td>172.31.0.10<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Launch Aviatrix Standalone GW in AWS Default VPC<\/h4>\n\n\n\n
  1. Follow https:\/\/docs.aviatrix.com\/HowTos\/aviatrix_account.html to onboard your AWS account that contains the default VPC<\/li>
  2. Create standalone gateway in this AWS account, select the region, default vpc and a public subnet<\/li><\/ol>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    3. Once the GW created, select it, and click on EDIT<\/strong><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    4. Select 2nd public subnet in default VPC, then Create HA gateway<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    5. Confirm both stand alone gateways are up, and record down their public IPs<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Create Site to Cloud connection using Mapped NAT in Aviatrix Controller<\/h4>\n\n\n\n

    Goes to Aviatrix controller web page, SITE2CLOUD -> Setup -> 2 Create a New Site2CloudConnection -> ADD NEW<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    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<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    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<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    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<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Click OK to create the Site2Cloud connection<\/p>\n\n\n\n

    Configure S2C for Stand Alone Gateways<\/h4>\n\n\n\n

    Select the newly created Site2Cloud connection, and click on Edit button <\/p>\n\n\n\n

    \"This<\/figure>\n\n\n\n

    Under Connection Detail<\/strong>:<\/p>\n\n\n\n

    Vendor: Aviatrix
    Platform: UCC
    Software: 1.0<\/p>\n\n\n\n

    Click on DOWNLOAD CONFIGURATION<\/strong><\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Record default VPC ID from AWS<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Site2Cloud -> Setup -> Add new -> Select Default VPC by VPC ID<\/p>\n\n\n\n

    Import -> Select the configuration file<\/p>\n\n\n\n

    ! ! ! Make sure to change Connection Type <\/strong>from Mapped <\/strong>-> to Unmapped<\/strong> ! ! !<\/p>\n\n\n\n

    Reverse connection name, eg: From LandingAWSDefaultVPC1 to AWSDefaultVPC1Landing<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Make sure to pick the correct gateway for primary and HA<\/p>\n\n\n\n

    ! ! ! Make sure enter Azure side virtual CIDR 100.97.0.0\/16 as Remote Subnet ! ! !<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Click OK to create unmapped S2C connection from stand alone gateways back to Landing spoke gateways<\/p>\n\n\n\n

    Validate the connections are up<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    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 <\/p>\n\n\n\n

    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<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
    \"\"<\/figure>\n\n\n\n

    Observe route tables in Azure vNets<\/h4>\n\n\n\n

    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.<\/p>\n\n\n\n

    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<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    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:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Allow Site2cloud connection to be accessible across transit<\/h4>\n\n\n\n