Pages

Thursday, 31 August 2023

VMware Cloud on AWS and native AWS route tables

During my time working with customers who use VMware Cloud on AWS and wish to integrate with native AWS services, I frequently see issues with network connectivity when multiple route tables are in use. Some customers have an automated way of deploying VPCs that use multiple route tables, perhaps for public and private subnet architectures. A prerequisite of deploying a VMware Cloud on AWS SDDC is to connect it to a customer-owned VPC, sometimes referred to as the connected VPC:

https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws-operations/GUID-BC0EC6C5-9283-4679-91F8-87AADFB9E116.html

Wednesday, 3 May 2023

VMware Cloud on AWS Cluster Rename

Just a quick blog to let you know that a new feature customers have been requesting for a long time, the ability to rename clusters, is now available with clusters that have two or more hosts.

If you navigate to the SDDC within the Cloud Services Portal you can see that I have an SDDC with a 2-node cluster with the default name of Cluster-1:


Within vCenter you can also see the default

Wednesday, 5 October 2022

VPN termination on a NAT'ed Tier-1 within VMware Cloud on AWS for DMZ traffic segregation

A colleague's customer recently had a requirement to host both DMZ and Production workloads in VMware Cloud on AWS while ensuring that traffic is segregated during transit. Currently, if the customer was to deploy DMZ and Production networks attached to the default Compute Gateway (CGW) Tier-1 then that traffic would be routed by the Tier-1 and thus violate the segregation required as per below:

In SDDC version 1.18 we introduced the ability to deploy multiple compute gateways (Routed, NAT'ed or Isolated) More information

Friday, 11 February 2022

Registering VMware Cloud Disaster Recovery to vCenter with a restricted user account

A customer who is currently looking to deploy VMware Cloud Disaster Recovery (VCDR) globally recently asked about using a single active directory account with the minimum required permissions within vCenter as the account used to register their VCDR connectors to vCenter. For those who are new to VCDR, this is VMware's Disaster Recovery as a Service solution that offers on-demand disaster recovery with a very compelling total cost of ownership in comparison to on-premises.

The customer in question wanted to use a single active directory account across all their vCenters globally and didn't want to add the active directory

Wednesday, 9 February 2022

Routing to a connected VPC when attached to VMware Transit Connect

Recently there was an internal discussion around a customer request to access an Amazon FSx for Windows File Servers that was currently running in a connected VPC from another SDDC. The topology that the customer was looking at was as follows:

The customer had two SDDC's with one of the SDDC's (SDDC 01) being connected to a VPC that was running Amazon FSx for Windows File Servers. They also wanted

Wednesday, 26 January 2022

VMware Transit Connect default route and the impact on VPN and HCX Connectivity

I recently had a query from a customer who was implementing intra-region peering between a VMware Transit Gateway and a native AWS Transit Gateway which would then be attached to a security VPC. Their requirement was to ensure that all VM connectivity from the SDDC would traverse the security VPC before egressing out to the internet or back to on-premises. This would require them to add a static route into the vTGW to point all traffic (0.0.0.0/0) to the peering attachment which connected the vTGW to the TGW. From there they

Tuesday, 27 April 2021

HCX Service Mesh and Route Based VPN with default route advertised

I've been asked a few times around whether or not HCX can be used if the customer has a route-based VPN into VMware Cloud on AWS and is advertising the default route 0.0.0.0/0 into the SDDC. The short answer is Yes, this is supported and works.

The long answer as to why this question comes up is that when we advertise the default route of 0.0.0.0/0 into the SDDC then all traffic from the SDDC will flow via on-premises, this includes traffic destined for the internet. Some customers prefer to do this to ensure all outbound internet traffic routes via their perimeter firewall so they can ensure that all security and logging policies are applied. The confusion comes around HCX. Since HCX is unable to use an existing IPSEC VPN tunnel to send traffic from on-premises into the SDDC as per the KB article it needs to establish its own. The HCX-IX Interconnect and HCX Network Extension Appliances both establish an IPSEC VPN tunnel from on-premises to their peer appliances in the SDDC using UDP/4500. So the question is, if we are advertising 0.0.0.0/0 into the SDDC so all traffic traverses the IPSEC VPN tunnel back to on-premises, then how can the HCX-IX Interconnect and HCX Network Extension Appliances communicate?