In my last post, I provided a detailed explanation of the migration methods available within VMware HCX. Specifically, I discussed when to utilize No-Downtime, Cold Migration, and/or Bulk Replication and how each method operates. In this final post on HCX migration, I explain and walk through the workflow used to migrate to–and from–the IBM Cloud.
The private network within the IBM Cloud is always assigned an address from a 10.X subnet. As a result, accessing the IBM Cloud network from addresses outside the 10.X range may prove to be a challenge since the network will drop packets from an unrecognized address. For example, if you created an IPsec VPN from your on-prem environment that is assigned a 192.X address, you will not be able to reach vCenter or any other VLAN-backed 10.X address resident on the IBM Cloud private network. The same is true for VXLAN-backed virtual machines assigned addresses outside of the IBM Cloud address space. This is why we must use NAT.
I get many questions from our field teams and clients on how to connect to an on-prem environment to a VMware Cloud Foundation (VCF) instance deployed in the IBM Cloud. While there are a few hardware options available within the IBM Cloud catalog (e.g., Fortinet and Vyatta), I typically recommend the use of an NSX Edge Services Gateway (ESG) to terminate VPN connections. There are cases where other devices might be more suitable, but I’ll save that discussion for another post. In this post, I will show you how to terminate a IPsec connection to a VCF instance deployed in IBM Cloud using an NSX ESG. I’ll be using the public internet as my connection medium. This is fine for a proof-of-concept, but you’ll want to use IBM’s direct connection options for production.