VMware Transit ConnectTM has been around now for more than a year and I must admit that it has been widely adopted by our customers and considered as a key feature.
Over the time we have added multiple new capabilities to this feature like support for connectivity to a Transit VPC, custom real-time Metering to get more visibility on usage and billing, connectivity to an external TGW (inter region), and more recently Intra-Region Peering with AWS TGW which has been announced at AWS re:Invent 2021, also referred to as intra-region peering.
Let’s focus in this post on the specific use case of allowing connectivity from workloads running on an SDDC to a VPC sitting behind a native Transit Gateway – TGW.
Intra-Region VTGW to TGW Peering lab Topology
In this lab, I have deployed an SDDC and attached it to an SDDC Group with a vTGW (Transit Connect) that I have peered to a native TGW in the same region.
On the AWS native side, I have deployed 2 EC2 instances (172.20.2.148 and 172.20.2.185) in a native VPC (172.20.2.0/24) and on the SDDC I have deployed a Debian10 Virtual Machine named Deb10-App001 running with IP 172.18.12.100.
Building the lab Topology
Let’s see how to put all things together and build the Lab!
Attaching the native TGW to the SDDC Group
To start configuring this lab it’s very easy!
I have first created an SDDC Group called “Multi T1” and attach my SDDC to it. SDDC Groups are a way to group SDDCs together for ease of management.
Transit Connect offers high bandwidth, resilient connectivity for SDDCs into an SDDC Group.
Then I have edited my SDDC Group and selected the External TGW tab.
I have Clicked on ADD TGW. The information needed are the AWS Account ID (ID of the AWS Account where the TGW resides), and the TGW ID that I have grabbed from my AWS Account.
The TGW Location is the region where the native TGW being peered with resides. The VMC on AWS Region stands for Region where the vTGW resides.
I have entered the information needed including the VPC CIDR (172.20.2.0/24) that stands behind the peered TGW and confirmed both regions are identical.
The process of establishing the peering connection starts. Keep in mind that the whole process may take up to 10′ to complete.
After a couple of seconds the status changes to PENDING ACCEPTANCE.
Accepting the peering attachment in AWS Account
Now it’s time to switch to the target AWS Account and Accept the peering from the AWS console. This is possible by going to the Transit Gateway attachments option in the VPC Menu.
I have selected Attach in the Actions drop down Menu.
And then to Click Accept.
After a few minutes the attachment is established.
Observe the change on vTGW console
In order to validate the connection is established, I have checked the route table of the vTGW and we can see that the new destination prefix of the native VPC have been added.
We can also see from the Transit Connect menu of the SDDC that the CIDR block of the native VPC has been added to the Transit Connect routing tables in the Learned Routes.
Adding a Route in the AWS native TGW route Table
To make sure the routing will work I have checked if a routing table is attached to the peering attachment and that there are routes to the SDDC subnets.
The TGW would need the following route table:
As seen in the following screen, I can confirm there is a route table attached to the peering attachment.
If I look at the routing table content, I can find both the VPC and Peering attachement in the Associations tab.
If I look at the Route Table of the native Transit Gateway, I can see there are only one route entry:
As the Transit Connect does not propagate its routes to the native TGW, we need to add the route back to the CIDRs of the SDDC.
Be careful because if you forget this step it won’t be able to route the packets back to the SDDC!
After a couple of seconds, the route table is updated.
All subnets should be added if connectivity is needed to them.
Add a route back to SDDC CIDRs into the native VPC route table
By default the native VPC will not have a route back to the SDDC CIDRs, so it needs to be added manually in order to make communication between both ends possible.
Add one or all SDDC CIDRs, depending on whether you want to make all or some of the segments in the SDDC accessible from the native VPC.
I have only added one segment called App01.
NB: Virtual Machines on Layer-2 extended networks (including those with HCX MON enabled) are not able to use this path to talk with the native VPC.
Keep in mind that as you add prefixes to either the VMware Cloud on AWS or the AWS TGW topologies the various routing tables on both sides will have to be updated.
Configure Security and Test Connectivity.
Now that network connectivity has been established let’s have a look at the additional steps that need to be completed before workloads can communicate across the expanded network.
Configure Compute Gateway FW rules in SDDC
First, the Compute Gateway (CGW) Firewall in the SDDC must be configured to allow traffic between the two destinations.
You have the choice to define IP prefix ranges in the CGW to be very granular in your security policy. Another option is to use the system defined CGW Groups called ‘Transit Connect External TGW Prefixes‘ as sources and destinations in the rules.
The system defined Group is created and updated automatically and it includes all CIDRs added and removed from the VTGW. Either choice works equally well depending on your requirements.
I have created a Group will all prefixes from my SDDC called SDDC Subnets where I could find the IP address of my test VM.
I decided to configure a Compute Gateway Firewall rule (2130) to allow traffic from the App01 compute segment to the native VPC and have enforced it at the INTRANET LEVEL. The second rule (2131) will allow for connectivity from the native VPC to the SDDC subnets.
Configure Security Groups in VPC
For the access to the EC2 instance running in the native VPC, make sure you have updated the security group to make sure the right protocol is permitted.
My EC2 instance is deployed has an IP Address of 172.20.2.148
and has a security group attached to it with the following rules:
Test connectivity
It’s time to test a ping from App001 VM in my SDDC which has ip address 172.18.12.100 to the IP Address of the EC2 instance.
We can also validate that a connectivity is possible from the EC2 instance to the VM running in the SDDC.
Conclusion
Win this post blog post we have established an intra-region VTGW to TGW peering, updated route tables on both the TGW and the native VPC, prepared all security policies appropriately in both the SDDC and on the AWS side, and verified connectivity end to end.
This intra-region peering is opening a lot of new use case and connectivity capabilities in addition to the existing Inter-region peering.
In my next post, I will show you how to peer vTGW with multiple TGW, stay tune!