Connect to a VMware Cloud Foundation instance on the IBM Cloud via NSX

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.

Before we get to the details, it’s worth mentioning that VCF on IBM Cloud comes standard with an NSX Edge (named “mgmt-edge”). This ESG used for outbound communication only by one of the automation components resident within the instance. You may use this ESG for an IPsec VPN, however, I highly recommended deploying another edge (large or above) dedicated for the VPN connection.


Setup Process

Within the vSphere Web Client, navigate to the ESG you plan to use to terminate the IPsec connection. From within the “Manage” tab, select the “VPN” heading from the menu ribbon and click on “IPsec VPN”.

If you wish to utilize certificate-based authentication and a pre-shared key with any remote peer, modify the global configuration. Note, you must have imported server certificates, CA certificates, or CRLs before you can proceed with global configuration with certificates. Additionally, all the sites whose peer endpoint is set to “any” will share the global pre-shared key. I’m skipping this part since I’m creating a simple IP-to-IP tunnel.

Add an IPsec VPN connection

Next, setup a remote connection by clicking the on the green “+” and fill in the required values on the “Add IPsec VPN” popup.

IPsec Local Id, Endpoint, and Subnets

Place a check in the “Enabled” and “Enable perfect forward secrecy” (PFS) checkbox. For those curious why we enable PFS, see information about it here. For the “Local Id” and “Local Endpoint” fields, enter the public IP address assigned to the NSX ESG. Remember this is the uplink connected to the SDDC-DPortGroup-External port group.

 

In the “Local Subnets” field, enter the IBM Cloud private address space of 10.0.0.0/8 and any other subnets the NSX ESG routes. Note that if your on-prem subnets are already on a 10.x address space, you may want to limit the ranges to simply have access to the vCenter appliance residing on the cloud network. It’s also important to note that you may also enter a subnet assigned to a logical (i.e., VXLAN) network that overlaps with your on-prem subnet. If you decide to do this, you’ll need to modify the extension field discussed later in the post.

IPsec Peer Id, Endpoint, and Subnets

Next enter the Peer Id to identify the on-prem site. If you’re using certificate-based authentication, you’ll need to enter the common name found in the peer certificate. Then, enter the public IP address or FQDN of the peer as the ID. When done, enter the same IP address or FQDN in the “Peer Endpoint” field. When done, add the on-prem subsets you plan to access via the IPsec tunnel.

Encryption, Authentication, PSK, D-H, and Extensions

After you’re done with the peer information, select the encryption algorithm. Make sure the peer supports this algorithm. Otherwise, you will not be able to complete the VPN connection. Next, select the authentication type. If you configured a certificate at the global level, select “Certificate”. Otherwise, select PSK and type in a pre-shared key. Make note of this key as you will use it to configure the on-prem device. Then, select the Diffie-Hellman Group you wish to use. This is the cryptography scheme used by the peer site and the NSX Edge to establish a shared secret over the public internet (or any insecure medium). You’ll need to make sure the on-prem device supports the the cryptography scheme you choose.

The next field you’ll notice is the “Extension” field. As a mentioned previously, you’ll want to use the passthroughSubnets argument to support overlapping subnets that exist between the VCF instance and on-prem. Note that this will not work for IBM Cloud 10.x networks (i.e., virtual machines assigned to VLAN-backed networks on the IBM Cloud 10.x address space). This function should only be used for communication between on-prem and VXLAN-backed virtual machines in the cloud. Click “OK” when you’re done.

Enable IPsec VPN Service

After you’re done configuring the connection, enable the IPsec VPN Service by clicking on the “Enable” button. Subsequently, click the “publish changes” button. At this point, you’ll need to setup your on-prem (peer) connection. If you’re fortunate to own a Cisco ASA, you can generate the configuration. To do this, click on the “Generate ASA Configure” icon next to the “Show IPsec Statistics” Link.

When you’re done setting up the peer endpoint, click on the “Show IPsec Statistics” to view that status of the connection and tunnel. You’ll notice in my example that the channel status is “UP” along with the tunnel for my single subnet.

At this point, you should have a working IPsec VPN to a VMware Cloud Foundation instance in IBM Cloud.

NSX Firewall and NAT

As part of this configuration, the NSX ESG generates firewall rules that accept the IPsec VPN connection. These rules are based on the local and peer IP addresses specified during VPN configuration. Additionally, the ESG generates both SNAT and DNAT rules for udp (port 500 and 4500) and esp (any port) to enable the IPsec connection.

One NAT rule the NSX edge does not generate, however, is a SNAT rule to access the IBM Cloud address space.  As mentioned earlier, the private address space is 10.X. If you wish to access this address, you must SNAT your on-prem address to a private address to ensure proper communication. Otherwise, the IBM Cloud will drop your packets. For a quick how-to guide, head over to my post on configuring an NAT rule using an NSX edge in IBM Cloud.

 

Leave a Reply

Your email address will not be published. Required fields are marked *