Native AWS VPC Connecting to VMware Cloud on AWS (Part 2) – Route Tables and Transit Gateway Attachments

Welcome to Part 2 of VPN connectivity to VMC via AWS VPN. For this post, I will walk through how to attach an AWS VPC to an AWS Transit Gateway in order for route tables to be learned by the VMC SDDC and AWS VPC that will ultimately allow communication from workloads in AWS and workloads in VMC. If you immediately try to ping across the VPN from an EC2 instance to a VMC VM, it will fail as there is more work to do in order to create communication pathways in the form of adding a VPC to the Transit Gateway as well as configure some NSX rules.

In the diagram above I created two EC2 instances with an AWS VPC. For the sake of testing and validation, I first had to create a jump VM with access to the internet in order to remote into the workload VM. This is because, in order for the workload VM to ping across the VPN, 0.0.0.0/0 must be routed through the Transit Gateway and not an Internet Gateway. The goal here is to have a VM on the 10.0.10.32/27 subnet ping a VM on the 10.250.10.0/24 subnet.

To start, the first thing to check is the routing table for the Transit Gateway. This is done by selecting “Transit Gateway Route Tables” on the sidebar with the VPC.

You will then see a list of learned routes from the VMC SDDC. For the sake of this blog, I have deployed AWS EC2 Instances on a subnet that I plan on attaching to the Transit Gateway (10.0.10.0/24). However, notice below that only the learned routes for the VPN to VMC are listed below. While the 10.250.10/0/24 subnet is learned, in order to open communication via the AWS VPC, we first need to attach the VPC to the Transit Gateway so the 10.0.10.0/27 subnet is included. Here are the steps to create the VPC attachment to the Transit Gateway.

Step 1: Select “Transit Gateway Attachments” then “Create Transit Gateway Attachment”. Find correct Transit Gateway ID.

Step 2: Add tag for attachment name.

Step 3: Select the correct VPC and ensure you have the correct subnet selected. Select “Create Attachment”

As you can see, now that the VPC is attached to the TGW, the 10.0.10.0/24 subnet is now listed. This will now allow for the routing of traffic from my EC2 instance to my VM on VMC.

The final step is to create groups and add inbound and outbound firewall rules within the Network & Security section of the SDDC console. Make sure to apply the rule to the VPN Tunnel Interface and NOT “All Uplinks“. The reason for this is that a firewall rule applied to All Uplinks does not apply to the VPN Tunnel Interface (VTI), which is a virtual interface and not a physical uplink. The VPN Tunnel Interface must be specified explicitly in the Applied To parameter of any firewall rule that manages workload VM communications over a route-based VPN. In addition, you can see how groups are created on an earlier blog here.

Now that the routing table is complete and Compute Gateway Firewall rules are in place, you can test!

EC2 Windows VM

Ping results from EC2 VM to VMC VM

Advertisement

Native AWS VPC Connecting to VMware Cloud on AWS (Part 1) – Native VPC Connectivity via VPN

With the release of VMware Cloud on AWS 1.12, we delivered additional connectivity options with the addition of transit connect (VMware managed AWS Transit Gateway). Over the past few weeks, I have been working on a project that has specific success criteria as well as challenges that prevent certain connectivity options so I thought what better way to show how we got around the issue than to show how we did it as Transit Connect and AWS Direct Connect were out of scope. The plan is to have this be a multiple part blog series that details how to setup and test a route based VPN, attach to native AWS EC2 workloads via ENI in the VMC VPC as well as leverage a Transit connect that makes connectivity easier to configure, manage and maintain. The diagram below is the overall architecture for those already leveraging AWS native services via a Direct Connect and Transit Gateway but can only connect to VMC via IPSEC VPN for certain reasons (shout out to fellow VMC Architect Will Lin for the assist!). While Direct Connect provides much better speeds and feeds, you may still be able to accomplish what you need depending on your application requirements.

STEP 1: To get things started, we need to either identify or create a VPC that we want to communicate with the VMware Cloud on AWS SDDC. If you already have a VPC configured you can skip to Step 2. To create a new VPC, log into your AWS account go to Services > VPC> Create VPC. Similar to creating your VMC SDDCm it is paramount that plan your CIDR range appropriately so can assign subnetting correctly based on what you are trying to accomplish. ** Make sure you are selecting the correct AWS Region based on your requirements! **

Next, create a subnet that you will assign to the VPC. This is why understanding the CIDR ranges is important as you cannot have any overlap between your VPC CIDR and VPC subnets so keep that in mind as you build things out.

Creating a subnet assigned to the AWS VPC

Step 2: Deploy a AWS Transit Gateway (TGW). For reference, an AWS Transit Gateway connects VPCs and on-premises networks through a central hub. Keep in mind the default ASN number for the AWS TGW is 64512. If you are going to use an existing TGW, get the correct number from your team. For the sake of this blog, I setup the TGW with all the default settings.

Step 3: Create a Customer Gateway (CGW). A CGW is a resource that you create in AWS that represents the customer gateway device in your on-premises network, or VMC in this situation. 

In order to configure the CGW, you need to enter the VPN Public IP listed in the Networking & Security section of the SDDC console.

Step 4: With your transit and customer gateways configured, it’s time to create the VPN connection from the AWS side. Go to Services > VPC > Site-to-Site VPN Connections > Create VPN Connection. Name the VPN connection and select “Transit Gateway” as the gateway type and add your CGW. Take note that you can also add a new CGW didn’t as a part of the previous steps. We want to set the routing options to dynamic so we take advantage of BGP. My personal preference is to define the CIDR and per AWS documentation, this needs to be a /30 within a certain range. I also created a basic preshared key rather than have AWS create the key randomly.

AWS VPN Configuration

Step 5: Download the VPN configuration as a generic file. This is where you can validate the configuration and use it for configuring the VPN from the VMware Cloud SDDC Console.

Step 6: Configure the VPN on the SDDC. Go to the VMC SDDC Console > Networking & Security > VPN > Route Based > Add VPN. Here you want to take the Virtual Private Gateway Outside IP and enter that into the Remote Public IP Field. Take the Customer Gateway Inside IP Address and enter that number as the BGP Local IP. Next, take the Virtual Private Gateway Inside IP and enter that into the BGP Remote IP field. All that’s left is to enter the BGP ASN number that your configured earlier as a part of the TGW creation. It should also be listed in the config file you downloaded. If all numbers are correct, you should see the VPN Tunnel and BGP come up in a matter of minutes! If the VPN comes up and BGP does not, check your IPs and ASN numbers. Additional help can also be found here!!!!

You now have a working VPN from AWS to VMC!!! While the tunnel is up, there is more work to do so you can fully test traffic. In Part 2 I will cover routing tables and SDDC Gateway rules to enable two way communication. Stay tuned!!!!

VMware Cloud on AWS – SDDC to SDDC VPN and MS AD Replication

This is part two of my blog on how to leverage Microsoft Active Directory as an Identity Source and have AD replicate between two VMware Cloud on AWS SDDCs. Now that I have Active Directory running in US East, I will setup a route based VPN between my US East SDDC and US West SDDC. For my lab, I am using a Route Based VPN to replicate Active Directory Traffic. To add Route Based VPNs to both SDDCs, take note of your SDDC Public IPs on your Management Networks, determine what you want your Autonomous System Numbers (ASN) to be, and determine your IPs for both BGP local IPs. To keep the BGP IP scheme simple, I chose 169.254.x.x/30 to only allow for two available IP addresses. FYI, There are two different number ranges for Public and Private ASN numbers. Public is 1-64,511 and Private is 64,512-65,535. Route based VPN makes things simple in this scenario since we are leveraging Border Gateway Protocol (BGP) where both SDDCs are able to exchange routes and leverage BGP peering. For a deeper dive into BGP peering specifically around AWS Direct Connect and VMware Cloud on AWS, check out Nico Vibert’s Blog. It will not disappoint!

SDDC Public IP Info

Once you have the ASN and SDDC Public IP information, you can add your route based VPN by going to Networking & Security tab -> Network -> VPN -> Route Based -> “Add VPN”. For my lab, I have kept all the defaults for the tunnel and IKE settings. You may need to make changes here based on your security requirements. You must, however, select a pre shared key that will be used for both VPN connections to establish a secure connection. I have also left the Remote Private IP field blank. Once you click “Save”, you will see the status of the VPN and BGP Remote IP go to a yellow status as the negotiations take place. If successful, you should see both Remote BGP IP and VPN status turn green.

SDDC to SDDC VPN once completed

The next step in the process is to deploy a second Domain controller inside the second SDDC. Before you can promote the second DC, you need to first deploy a Windows Server VM in SDDC #2. Once the VM is deployed, you will then need to establish two-way communication across the VPN tunnel to be able to add the Windows Server to the domain and promote it. Although the VPN is up, you still need to configure additional Gateway Firewall rules in order for Domain Controllers to talk to each other across networks. Go back to Networking & Security -> Security -> Gateway Firewall -> Compute Gateway -> Add New Rule. For two-way communication, add two rules that allow traffic to and from the Domain Controller. Make sure that you have this traffic go over the VPN Tunnel Interface and NOT the Internet Interface. Make these rules for both SDDCs.

Gateway Firewall Rules for VPN Tunnel Interface

Before promoting your soon-to-be Domain Controller, make sure you can ping across the VPN via IP and DNS FQDN. The next step in the process is to deploy a second Domain Controller inside SDDC #2. I will not go through the process in this blog but the steps are similar to setting up the first DC in that you need to promote the server to a Domain Controller. There are several blogs out there on how to do this but here’s one just in case. Once added, you can verify Active Directory is syncing across SDDCs and Domain Controllers by running “repadmin /replsummary” via the Command Prompt. You can now add users, GPOs, etc to either side and both SDDCs will have the same info. To take things even further, add your new Domain Controller as an identity source to the new SDDC. This will allow users to login to either vCenter as long as they have an account on the domain. If you missed my blog on setting up AD as an identity source with VMWonAWS, click here.

VMware Cloud on AWS Connection Options

Happy New Year!!! This is going to be an exciting year for VMware Cloud on AWS and I wanted to kick off 2018 by highlighting the way in which you are going to connect into and out of VMware Cloud on AWS.

First of all, VMware Cloud on AWS is optimized (VMware Cloud Foundation) to run on dedicated, elastic bare metal infrastructure at a very high level inside Amazon’s data centers. For security purposes, the VMware Cloud on AWS SDCC is bifurcated to the components that manage the SDDC itself such as ESXi, VSAN, NSX, and vCenter.

Here’s a simple explanation of how you can setup the connectivity framework.

The first thing you need to setup is a connection to the management components of the SDDC.  You will first need to create a Management VPN and choose a set range of IP addresses that will be used by management components such as the ESXi hosts and vCenter. This range will be in the form of a simple CIDR block. We recommend using a /20 CIDR block for management purposes. After you connect the management portion of the SDDC, you will then need to setup an IPSec VPN between your on-prem data center and management components. This VPN can be setup over the Internet or AWS Direct Connect (DirectX). After this connection is established, you can then build firewall rules on the VMware Cloud on AWS Console. With these rules you can control access to the  vCenter from your on-prem data center.

There is an optional connection you can setup if you need access to your vCenter Server directly from the Internet. A public IP is automatically provided during the provisioning process. It is important to note that all access to this IP is restricted. To provide access, you will need to configure firewall rules in the VMware Cloud on AWS console to allow this direct type of Internet access.

The second VPN you will need to setup is between your compute workloads and your on-premise data center. Several logical networks are required to provide the IP addresses for the workloads you plan on migrating or build in VMware Cloud on AWS. This VPN secures these workloads and allows them to connect back to your on-prem data center. This can be an IPSec VPN or L2VPN. The L2VPN advantage is that you can stretch a single L3 IP space from on-prem to the cloud and is also required for live migrations. This VPN can go over the Internet or AWS DirectX. You can again create firewall rules as needed to access on-prem workloads.

The next connection is between your SDDC workloads and your Amazon VPC. This is automatically configured and built during the SDDC provisioning process. Once you select the Amazon VPC subnet that will be associated with your VMware Cloud on AWS SDDC an elastic network interface (ENI) will be created allowing traffic to flow between both environments.  In order to control security, you will need to configure AWS IAM policies as well as firewall rules on the VMware Cloud on AWS side to allow access between both. Lastly, you will likely need to give direct public internet access to some of your SDDC workloads. To make these accessible to the Internet, you will need to leverage AWS elastic IPs along with NAT and firewall configurations to allow this type of access.

That’s it! Now you are ready to leverage your SDDC on VMware Cloud on AWS!

Also, here’s a video that covers the content discussed above.

-SL