Connecting to private VPC networks using IBM Cloud Secrets Manager authenticated VPN on IBM Cloud

As security becomes ever tighter, with businesses provisioning more of their infrastructure on private networks, flexible access requires a VPN solution. In this post, we examine how to leverage the IBM Cloud VPN as a Service (VPNaaS) offering for VPC, while managing authentication through IBM Cloud Secrets Manager.

IBM Cloud Secrets Manager provides a centralised resource to manage various secrets. It provides for the grouping of secrets to simplify the management process while tightening access.

We will utilise Secrets Manager as a certificate-signing authority to store and manage the TLS certificates required for the VPN connectivity. This is an obvious approach as Secrets Manager is integrated into the VPNaaS offering to handle the client/server certificates.

IBM Cloud Virtual Private Cloud (VPC) is a highly scalable and secure cloud networking service, allowing businesses to create complex network topologies to mirror their on-premises setups, utilising the IBM Cloud infrastructure.

With VPC, users can deploy and manage cloud resources like virtual servers, storage and networking components in a logically isolated environment, ensuring enhanced security and control over their cloud-based assets. Additionally, VPC allows seamless integration with other IBM Cloud services, creating a unified ecosystem to host various applications and workloads.

• VPC exists with configured subnet
• Secrets Manager instance previously created

IBM Cloud Secrets Manager provides a number of ways to handle VPN certificates. We will use the internal signing mechanism to generate a client and server pair of certificates for use by the VPN. Alternatives are to use an external signing authority or to import externally generated self-signed certificates into Secrets Manager.

For the following steps, open the Secrets Manager instance, which will produce a screen similar to that in Figure 1:

• Select Secret groups from the menu.
• Click Create.
• Enter a meaningful group name and optional description.
• Click Create at the bottom of the screen.

• Select Secrets engines from the menu.
• Select Private certificates from the drop-down list.

• Click the Create certificate authority button.
• This starts a wizard to collect entries. On the next page, enter a meaningful name (e.g., myRootCA).
• Very important: Toggle the encode URL switch as shown in Figure 2:

• Click Next and complete the displayed form. The only required field is the Common Name, which can be used along with Subject Alternative Names later to accept/reject certificates.
• Leave alternative names empty and set the common name as an arbitrary domain name ‘example.net’.
• Click Next.
• The next wizard screen requests Key algorithm.
• Select the algorithm from the drop-down list. To increase our chances of success, we use the same algorithm throughout the entire certificate chain.
• Click Next.
• The next wizard screen is Certificate revocation list.
• Toggle the CRL building switch to avoid issues with CRL handling.
• Click Next.
• The review page will display.
• Click Create and the following screen will be displayed:

Having created the root CA, we now create an intermediate CA by clicking on the link Create certificate authority shown in Figure 3.

• On the next screen, enter a meaningful name (e.g., myInterCA).
• Very important: Toggle the encode URL switch.
• Click Next.
• Complete the next three forms in the same manner as for the root CA above. When the certificate is created, the screen shown in Figure 4 will be displayed:

From the screen shown in Figure 4, you are guided to the next step—create a certificate template. Click the Create template link, and complete the form using a meaningful name and the guidance below:

• TTL: Validity of the certificate. For testing, 30 days is reasonable.
• Key type: This is the same as key algorithm from the certificate authority. We chose the same setting for simplicity.
• Allowed secret groups: Choose the secrets group created above.
• Add domains, subdomains or wildcards: Add the common name used in the CA certificates created above (remember to push the ‘+’ button after typing the entry).
• Toggle switches: For testing, select Allow any common name (CN) and Allow subdomains.
• Certificate roles: Select Use certificates for server and Use certificates for client.
• Subject Name: Because we are allowing any CN, leave this blank.

• Select Secrets from the left-hand menu.
• Click the Add button on the secrets display screen.
• Select the Private certificates tile.
• Click Next.
• Give the certificate a meaningful name and optional description.
• Click Next and complete the form:
  • Select the certificate authority and template created in the previous steps.
  • Use the same CN as used throughout this exercise.
  • Set validity to the same as the template.
  • Leave the SAN field empty.
  • Click Next to see a review of the certificate, then click Add to create the certificate.

Repeat Step 6, creating a second private certificate for the client end of the connection.

For the VPN service to retrieve the keys from IBM Secrets Manager, we must enable communication between the two services. From the Cloud portal top bar, select Manage > Access (IAM). This will display the following screen:

• Select Authorizations from the left-hand menu.
• On the displayed page, click Create.
• Complete the Grant a service authorization form as per the following, then click Authorize:

Having created the certificate authority, you’ll now create the IBM Cloud VPN as a Service (VPNaaS) instance. From the Cloud portal, select Create resource and choose Client VPN for VPC. The provisioning menu will be displayed:

• Ensure the Geography and Region are correct.
• Choose a meaningful VPN server name.
• Select a resource group to match your resource grouping strategy.
• Select the VPC to which this VPN is being attached.
• Set the client address pool CIDR (for testing we chose 192.168.8.0/22).
• For testing, choose Stand-alone mode, which only requires a single subnet to be utilised.
• For authentication, the default action is to use Secrets Manager and the instance name and key name can be selected from the drop-down lists provided.
• Select the correct key for the server.
• Select the correct key for the client end.
• Use the default security group which will be pre-checked.
• Change the Transport protocol to TCP.
• Set Tunnel mode to Split tunnel.
• Click the Create VPN server button.

To complete the process, we need to ensure traffic is permitted and routed correctly. First, ensure that the attached security group permits inbound traffic. As configured above, we require an inbound rule allowing TCP from 0.0.0.0/0 on port 443.

Second, return to the VPN for VPC overview page and open the VPN server routes page. Create an entry containing the CIDR for the VPC subnet with an action of translate. Doing this will enable the VPN server to publish the private IP address range back to the client.

Having configured the server, it is now necessary to install and configure a client such that a communication path can be established. The VPNaaS offering is based around OpenVPN, so an OpenVPN-compatible client is required. After installing the client, the configuration file can be downloaded by clicking the Download client profile link from the Clients page of the created VPN.

The client certificate can be downloaded from the Secrets Manager portal. Select Secrets from the left-hand menu and the download option under the three vertical dots in the right-most column of the Secrets screen,as shown in Figure 9:

The downloaded zip file contains both the client certificate and private key. Extract these and embed the contents into the client configuration file (ovpn) as follows:

The ovpn file has the following structure:

Edit the configuration (ovpn) file and add the following four lines after the line starting#key :

<cert>
</cert>
<key>
</key>

Using a text editor, copy the block of text beginning with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE----- from the client certificate file and paste it between the <cert> and </cert> lines.

Next, using a text editor, copy the block of text beginning with-----BEGIN PRIVATE KEY----- and ending with-----END PRIVATE KEY----- from the client key file and paste it between the <key> and</key> lines.

Lastly, save the ovpn file, which is now in a form suitable for import into an OpenVpn client.

Having completed the configuration from OpenVPN Client to private VPC network using Secrets Manager authenticated VPN, it should be possible to access your server instances by their Private IP addresses, assuming the attached Security Groups permit the connection. Note that the source IP for the connection is the CIDR from the VPN tunnel, not the originating client as routing is set to translate.

The following resources provide additional guidance on provisioning this environment:

• Getting started with Virtual Private Cloud (VPC)
• Getting started with Secrets Manager
• About client-to-site VPN servers