Provisioning a new SDDC on VMware Cloud on AWS (VMC) is not an operation that I perform on a regular basis. Usually, one of the first tasks after a new SDDC deployment is setting up a VPN connection between your on-premises datacenter and your VMC environment. Given this is not a frequent activity, I always forget the specific configurations required for my particular VPN solution and figure I would document this for myself in the future as well as anyone else who might also have a simliar setup.
Since the VMC Gateways are just NSX-v Edges, any VPN solution that supports the NSX-v configurations will also work with VMC. In my environment, I am using pfSense which is a popular and free security Virtual Appliance that many folks run in their VMware home lab. Before getting started, it is also important to note that there are two gateway endpoints that you can setup separate VPN connections to. The first is the Management Gateway which provides access to the management infrastructure such vCenter Server, NSX and ESXi hosts and the second is the Compute Gateway which provide access to the VM workloads running within VMC. Since the instructions are exactly the same for setting up the VPN for either gateways, I am just going over the Management Gateway configuration and where applicable, I will note the minor differences.
Step 1 - Login to the VMC Portal (vmc.vmware.com) and select one of your deployed SDDCs. Click on the Network tab and you should be taken to a page like the one shown in the screenshot below. Here is where you will be applying your VPN configuration from the VMC side. Start off by making a note of the public IP Address for the Management Gateway (highlighted in yellow), this will needed when configuring the VPN configuration on the on-prem side. It is probably a good idea to also note down the Compute Gateway IP Address if you plan on configuring that as well.
Step 2 - Login to the pfSense admin interface and create a new VPN connection by going to top menu under VPN->IPsec. We will start off by configuring our Phase 1 settings by simply clicking on the "+" button. VMC supports a number of IPsec VPN parameters, some of which are configurable while others are now.
Here is a table of the Phase 1 settings for your reference:
Parameter | Value | Configurable |
---|---|---|
Protocol | IKEv1 | No |
ISAKMP mode | Main mode | No |
Encryption Algorithm | AES-256 | Yes |
Hashing Algorithm | SHA1 | No |
Diffie Hellman | DH2 | Yes |
IKE Authentication | Pre-Shared Key | Yes |
ISAKMP/IKE SA lifetime | 28800 seconds | no |
In Phase 1 settings, you will need to edit the following:
- Remote Gateway - Public IP Address of your Management Gateway (Compute Gateway will have a different IP Address)
- Description - Friendly name to distinguish this particular VPN connection
- Pre-Shared Key - Create some string which will be needed later when applying the VPN settings on the VMC side
- Encryption Algorithm - AES and 256 bits (configurable, but make sure to match it on VMC side)
- Hasing Algorithm - SHA1
- DH key group - 2 (configurable, but make sure to match it on VMC side)
- Lifetime - 28800 (default)
Once you are done entering all the information, go ahead and click save to finish.
Step 3 - Next, we need to configure our Phase 2 settings. Expand the box under the Phase 1 configuration and click on the "+" icon as shown in the screenshot below to create the Phase 2 entry.
Here is a table of the Phase 2 settings for your reference:
Parameter | Value | Configurable |
---|---|---|
Encryption Algorithm | AES-256 | Yes |
Diffie Hellman | DH2 | Yes |
Hashing Algorithm | SHA1 | No |
SA lifetime | 3600 seconds | No |
Perfect forward secrecy (PFS) | Enabled | Yes |
In Phase 2 settings, you will need to edit the following:
- Remote Network - 10.0.0.0/16 which is the VMC management network (same for all SDDCs)
- Encryption Algorithm - AES and 256 bits (configurable, but make sure to match it on the VMC side)
- Has Algorithm - SHA1
- PFS key group - 2 (configurable, but make sure to match it on the VMC side)
- Lifetime - 3600 (default)
Once you are done entering all the information, go ahead and click save to finish. At this point, we are now done configuring the on-prem side of the VPN connection.
Step 4 - Now, we head back to the VMC portal to finish the VPN configuration. Select the VPN dropdown and then click on the Add button to create a new VPN connection.
You will need to edit the following:
- Remote Gateway Public IP - This is the public IP Address of your pfSense
- Remote Networks - This is your on-prem network that you wish allow to connect over the VPN
- Diffie Hellman - Default is 2 on pfSense, so you will need to adjust this on VMC (configurable, but make sure to match it on the on-prem side)
- Pre-shared key - This is the shared key that you had created in Step 2
Once you are done entering your information, click on the Save button. If everything was configured correctly and VMC Gateway can communicate with your on-prem VPN solution, then you should see a green Connected status both in the diagram as well as under the VPN view. If there are errors, they should be propagated on the UI whether it is an issue with your Phase 1 or Phase 2 settings.
Step 5 - Finally, the last step is to update the DNS settings in the VMC portal so that it knows which on-prem DNS Server to contact when resolving systems running on you on-prem. Simply click on the DNS drop down and click on the Edit button. It is important to note that BOTH DNS entries must be updated when you have a VPN configured. If you only have a single on-prem DNS server, go head and update the first entry and then delete the second entry. This is important as it may try to use the default Google DNS to query an on-prem system which will fail of course. If you have two on-prem DNS Server, then make sure both entries are updated.
Today, there is not an easy way in VMC to verify DNS resolution between VMC and on-prem, especially from the VMC side as you do not have direct access on the Management Network which would be needed to properly validate that you can resolve on-prem systems. Something that I have been doing to ensure things can fully resolve is to setup a vSphere Content Library on both ends and perform bi-directional publish/subscribing using the FQDN of the vCenter Servers. If I am able to successfully subscribe to the respective Content Library, then I know DNS resolution is working. I know this is something the VMC folks are looking to improve in the future, so for now, this is a quick way to validate things are working 🙂
Thank you very much