Connecting Your Home Lab to VMware Cloud on AWS

Discover ‘how’ and ‘why’ you should take advantage of a hybrid cloud environment, in this example of connecting a home lab to VMware Cloud on AWS. Test your architecture and configuration skills, as well as your cloud knowledge, and learn how to move workloads seamlessly through private and public clouds.

 

Having a home lab is great. There is no doubt that you learn a lot from the process of designing, building and configuring a lab. Especially when it’s yours and you can crash and burn it repeatedly every time you get something wrong. This was my experience of setting up my home lab.

This experience is enhanced further when you need to connect your home lab to something else. Why? Because it tests your configuration and architecture knowledge. In my case, I wanted to experiment with hybrid cloud, and there is no better hybrid cloud experience than connecting your home lab with VMware Cloud on AWS.

But how and why would I want to do this? 

Let me address ‘why’ first: 

The value proposition of a hybrid cloud is being able to move workloads running on my private cloud to the public cloud without the workloads knowing, or noticing, there has been a change of the underlying infrastructure. Another benefit is being able to use public cloud services in my private cloud. 

And the ‘how’: 

There are various options available to help you connect to VMware Cloud on AWS. These take the form of IPSec VPN (Layer 3 Virtual Private Network), Layer 2  VPN, and Hybrid Cloud Extension (HCX), across the internet or a direct connect (DX).

L3 VPN – Traditional IPSec VPN Tunnel over Internet. Compatible with any on-premises router. Interconnects two distinct network ranges.

L2 VPN – Stretch networks (L2 address space) between private and public cloud. Requires installation of NSX Standalone Edge Client on-prem (does not require NSX licensing on-prem). Easy to configure.

HCX – L2VPN (or L3VPN if no requirement to stretch network), combined with WAN Optimization engine and vSphere compatibility back to vSphere 5.0. Best option for bulk migration. Highly Secure (IPSec with AES 256 Suite-B encryption).

A high-level illustration is shown in the diagram below.

 

In the context of a home lab, the easiest way is to connect the two clouds (assuming you consider your home lab a cloud – as long as it is virtualized it counts) is via IPSec VPN. Then, you can take advantage of the really cool traffic steering, network extension and migration tooling in VMware Cloud on AWS, in the form of Hybrid Cloud Extension (HCX).

As a non-networking guy, setting up VPN for my home lab proved to be one of the more challenging tasks of the hybrid cloud setup.

The following diagram illustrates the end result, the place I wanted to get to when connecting my home lab to VMware Cloud on AWS, using a route-based IPSec VPN, with BGP.

 

The first thing to understand is that the network design for your home lab is important to consider.

To setup a VPN, you have to install a VPN terminator/gateway in your home lab. This can be a physical device or a virtual one. In my case, I chose the pfSense virtual device – using the AMD 64-bit architecture. The device is free.

Instructions on how to install the pfSense device as a VM on ESXi can be found here.

Once the pfSense is installed, you then need to use it as a router in your network, where one leg of the router is connected to your external broadband router, and the other leg is connected to your lab network. It will look something like the diagram below. The “WAN” and “LAN” references are the default network legs provided by the pfSense device.

 

This infers that the home lab network must be on a different subnet from any other network that is being supplied by your home network hub. It also means that all traffic from your home lab must be routed through the pfSense router. In other words, it becomes the default gateway for your home lab network. Therefore, give this some thought before you begin. Drawing a diagram helps you organize your thoughts. If you can’t draw it, maybe you can’t build it.

Once you have installed the pfSense router, anything that is on the home lab network should be able to reach the internet, using the pfSense device as the default gateway. Check this before you proceed any further.

Geek alert! Your laptop is probably going to be running on your home network during your setup. To ensure that you don’t lose connectivity to the devices in your new home lab network, create a virtual interface on your laptop on that network, assigning it a static IP address. It helps if you have an ethernet cable connection to the network, for example, plugged into a physical switch that is shared by your physical lab servers.

Now, there are two types of VPNs available for me to use when connecting to VMware Cloud on AWS – a dynamic type or static type.

 

In VMware Cloud on AWS, the VPN options are called –

  • Route-Based (dynamic)
    • Network subnets are automatically broadcast across the VPN via BGP
  • Policy-Based (static)
    • Network subnets that you want broadcast across the VPN have to be added manually

There is also Layer 2 – but that is really for NSX on-prem users, so we ignore that option in this article.

My choice is to use a route-based VPN. It’s easier to use, and easy is good.

This means that I have to install BGP on the pfSense router, because it is not configured by default. This link provides details of how you install and configure the BGP package.

You are now ready to connect your pfSense VPN gateway to the VMware Cloud on AWS VPN gateway.

A few things to check when doing the configuration:

  1. Check the public IP address of the VMware Cloud on AWS VPN server, and enter this in the “Local IP address” field
  2. Check the public IP address of your home hub device, and enter this in the “Remote Public IP” field
  3. Enable port forwarding on your home hub to the IP address of the WAN network interface of the pfSense device
  4. Allow UDP 4500 and 500 to be forwarded to the pfSense device
  5. Choose a BGP Local IP address within the recommended/reserved range*, assigning .2/30 (or the higher address in the pair) to the “Local IP” and .1 (or the lower address in the pair) to the “Remote IP”. This is assigning the IP addresses to the VPN endpoints on either side of the tunnel.
  6. Change the ASN of the VMware Cloud on AWS VPN server, using the “Edit Local ASN” link
  7. Assign an ASN to your VPN client, within the allowed public range
  8. The pfSense device can generate a secure “Preshared key” for you. Use this in the appropriate field
  9. Enter the IP address of the WAN interface of the pfSense device in the “Remote Private IP” field

 

*BGP Local IP/Prefix Length
Enter /30 CIDR from 169.254.0.0/16 subnet excluding following reserved addresses
– 169.254.0.0-169.254.31.255, 169.254.101.0-169.254.101.3

When everything is configured, connect the VPNs and the tunnel should be up in a few seconds. The VMConAWS console should look like the illustration above, with green lights on the VPN tunnel status and the BGP.

With the VPN up, you can now –

  • connect your vCenters with Hybrid Linked Mode or with vCenter Cloud Gateway, and have that single view of both environments from a single vCenter.
  • cold migrate VMs
  • play around with data center extension type use cases, even extending your lab into native AWS.
  • hmm … I wonder what we can explore next?

 

To learn more visit VMware Cloud on AWS