By: Todd Johnson (toddjohn@us.ibm.com)

      Neela Shah (neela@us.ibm.com)

Overview

Do you need access to your resources that reside on the IBM Cloud private network from your enterprise intranet, from home, or while traveling?

In this blog, we will walkthrough creating a Client to Site VPN Service that you can use to connect client machines such as Macs and PCs to your IBM Cloud VPC network, IKS and ROKS clusters, Cloud Service Endpoints (CSE),  IaaS services, and to your private classic subnets. In addition, we discuss how to use the IBM Cloud Secrets Manager service to manage your VPN service certificates. Our intention is for this to serve as a quick start to get you familiar with the service and create a working VPN connection from a Mac to your VPC and other IBM Cloud private networks. This blog is not intended to serve as a comprehensive guide or best practices. Prior to putting the Client VPN service into production you should read the official documentation. A good place to start is: https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-to-site-overview&interface=ui

These are the major steps to successfully create a working VPN connection:

1. Create a Secrets Manager service instance.

2. Decide which authentication method to use. We’ll use certificate authentication and Secrets Manager to issue certificates.

3. Configure Secrets Manager to issue certificates.

4. Create VPN server and client certificates using Secrets Manger.

5. Use IAM Authorizations to grant the Client VPN service access to your Secrets Manager instance where you created the certificates.

6. Create the Client VPN Service.

7. Setup the security groups and VPN routes.

8. Setup and use a supported VPN client on your client machine.  For the blog we'll use the Tunnelblick application on a Macbook.  See the documentation for other supported VPN clients.

In addition we briefly discuss accessing your classic infrastructure private subnets.

We know this looks like a lot of steps, but each one doesn’t take long and in the end will be worth the time spent. If you are already using Secrets Manager and have other ways to issue certifcates you can skip those steps.

Let us get started by looking at each step in detail. 

Create Secret Manager instance

For this blog we used the UI so you must specify both private and public endpoints.  Optionally you can use your existing Secret Manager instance.  To create a new instance:

1. Select Catalog -> Search for Secret Manager

2. Select Secrets Manager

Choose a location:

Select your pricing plan:

•  Under Configure your resource:

• - Enter a service name.

• - Select public and private endpoints.

• - The rest of the fields can be left at their default values.

Read and agree to the license terms and press Create.

Authentication

The Client-to-site VPN service allows you to specify client certificate authentication, userid and passcode or both. The userid and passcode method is more secure since it requires the user to get a timed passcode from IBM Cloud IAM when the connection is established. Using this option places an additional burden on the end user in that the user MUST manually get a new passcode each time the connection is established even if the VPN server initiates a re-connection. Using the client certificate authentication, requires a one-time setup of the client configuration file to provide that user’s client certificate. On subsequent connections there is no input required from the user and the connection is established automatically using the provided client certificate. The VPN service allows you to upload a certificate revocation list (CRL) or if your certificates are generated and managed by Secrets Manager the VPN service will use that CRL and there is no need to upload a CRL. For the purpose of this blog we will use client certificate authorization with the certificates created and managed in Secrets Manager.

Create Certificates

There are many methods to create certificates, you can use tools, such as easyRSA, openssl or other certificate generating software that you are used to. In our case, as mentioned before, we will use the certificate functions of Secrets Manager to sign, issue and revoke both the server certificate and the client authentication certificates. If you choose to manage the certificates outside of Secrets Manager you will need to upload them to Secrets Manager so the VPN Service can access them. The VPN service does not store certificates and only uses certificates stored in Secrets Manager.

Even if you use Userid and Passcode authentication you will still need a server certificate. This can be signed by public CA. However client certificates must be signed by a private CA. Therefore we will use the Private Certificate Egnine in Secrets Manager to manage both the server and client certificates.

For this blog we assume you have not created any CAs or certificates so we will create a private root CA and 2 intermediate CAs one that will sign the server certificate and one that will sign the client certificates. Again, the examples we show here are just quick getting started scenarios, we highly encourage you to read the documentation and adjust for your corporate policies before putting any of this into a production environment.

For more information regarding creating Secret Manager private certificates see: https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-private-certificates&interface=ui

Open your Secrets Manager instance and select Secrets engines → Private certificates.

First let’s create a root certificate authority. Press the Create certificate Authority button.

Enter a name, such as my-root-ca.

Enable the Encode URL option.

Press Next

Enter the Subject Information. The Common name (CN) is required the rest are optional.

Press Next

Select the key algorithm you want to use. We used the default of RSA 2048.

Press Next

Ensure the CRL distribution points option is enabled. We left the default of valid for 3 days.

Press Next

Review the settings and press the Create button.

Now we will create an intermediate CA that will sign the VPN Server certificate.

Press the Create certificate authority button.

• Enter a name

• Select the Internal Signing.

• Select the root ca from above. This will sign this intermediate certificate with root ca you created above.

• Ensure the Encode URL parameter is enabled

Press Next

Enter the subject name, the common name is required.

Press Next

Choose the key algorithm you want to use.

Press Next

Ensure the CRL distribution points option is enabled.

Press Next

Review the options and press the Create button.

The intermediate certificate should be created and signed by your root ca.

Now you’ll want to create a template for this CA.

Give the template a name

Specify how long a certificate created with this template should be valid for. We choose 2 years.

In the Domain settings, enable Allow any common name

Check the Use certifcates for server option.

You can leave the Subject name options blank.

Press Add button to add this template to the CA.

Now you’ll want to create an intermediate CA for the VPN clients.

This is exactly the same as vpn server CA.

When you create the template you’ll want to specify Use certificates for client option and not the Use certificates for server option. Also you may want to reduce the length of time the certificate is valid for. In our case we selected 1 year.

When you are done, you should have 3 CAs, similar to the following:

We are now ready to generate server and client certificates.

Server certificate

In the left nav bar of Secrets Manager, select Secrets and press Add button.

For secret type, select Private Certificate

Press Next

Give the certificate a name, the other values can be left at their default values.

Press Next

Select the vpn server CA you created above

Select the vpn server template you created above

Give the certificate a Common name (CN), we called ours vpn-server-cert.

Press Next

Review the settings and press Add button.

Client certificate

Now create a client certificate. First we’ll create one for toddjohn.

Using the same flow as above, press Add button from the secrets list.

Select a Private certificate tile and press Next

Give the cert a name. We left everything else at default values.

Press Next

Select the vpn-client-ca

Select the vpn-client-cert-template

Give the certificate a common name. Once the vpn client i attached to the VPN this name will be shown on the VPN connection panels.

Press Next

Review and press Add

You should now have 2 private certificates:

Grant the Client VPN for VPC service SecretReader access to your Secrets Manager Instance

Do the following:

• Manage -> Access (IAM) -> Authorizations

• Press Create

• Select Resources based on selected attributes

• Check Resource type

• Use the pulldown to select Client VPN for VPC

• For Target service use the pull down to select Secrets Manager

• Select all resources (or optionally you can select an individual Secret Manager instance)

• Check SecretReader access

Press the 'Authorize' button.  You now have granted the Client VPN service SecertReader access to your Secret Manager instance.

Client-to-Site VPN Service

Now that the certificates are imported and we have given the Client VPN service access to our certificate manager instance,  we can create the Client VPN service instance.

Do the following:

• VPC Infrastructure -> VPNs

• Click on the Client-to-site servers "tab" at the top

• Press the Create button on the left.

• Ensure the Client-to-Site VPN server is selected

Next is a set of documentation links that help you understand if environment is setup correctly. We highly encourage you to take the time to read this information. We’ll cover some of it below, but only from a simple getting started perspective.

Click the box to open the check list.

Scroll down and enter the location of the VPN server, for this example we’ve selected Washington DC

For the Details section do the following:

• Give the VPN server a name.  This can be anything you want that conforms to the name specifications.

• Select the VPC you want to use.

• Specify the client address pool.  When a client connection is created, this is the address pool from which the client IP address is chosen.  It's important that this address range does not overlap with any ranges in your network and that it does not overlap with any destination address ranges including the VPC subnets, other VPN client address pools, and any classic subnets you need access to.   Also, it must have a minimum size of 1024 addresses (/22). For more information about this field, please refer to the documentation.  We chose a range from the private address space, 172.21.0.0/22

For the Subnets section, do the following:

• Select either Stand-alone mode or High Availability mode.  For our purposes, Stand-alone mode is fine.

• Verify the VPN will be attached to the subnet you want.  The choice here doesn't really matter in that you can easily add routes to other subnets in your VPC and have your client communicate with resources on those subnets.  See below for route configurations.

For the Authentication section, do the following:

• Select the Secret Manager instance that you created your certificates from above.

• Select the your server certificate in the Server section and your client authentication certificate in the Client Authentication section.

• Ensure the Userid and passcode field is unchecked.

• Note: We are using client certificate authentication and not userid/password authentication.  If you want userid/passcode authentication please see the documentation.

• Note: Do not upload a CRL. We’ll be using the CRL from Secrets Manager

In the Security groups section, do the following:

• Select at least 1 security group that the VPN's network interfaces are attached to.  In our case, we are using the VPC's default security group.

In the Additional configuration section, do the following:

• If you have any DNS servers that the VPN connection will need on the client side you can enter those here.  These DNS servers are propagated to the client.  For example, if you need to access private IBM Cloud DNS entries from your client, you can add the private DNS servers of 161.26.0.10 and 161.26.0.11.  These values are optional.

• Adjust the Idle timeout session.  The VPN server will terminate the connection when there is no traffic flowing from the client to the VPN server for this amount of time.  We found that default of 600s is too short to be practical, so changing to 3600s.  This value can be changed after the VPN is created so you can adjust it later to meet your needs.

• Select UDP as the Transport protocol.  See the documentation for a discussion of the advantages and disadvantages of each protocol type.

• Set the tunnel mode.  The tunnel mode determines if your client sends all network traffic through the VPN connection (Full tunnel) or if only network traffic destined for the private subnets handled by this VPN server are sent through the VPN and other client network traffic destined for other networks are sent via their normal routes (Split tunnel).  In our case we want Split tunnel. 

Finally, press the 'Create VPN Server' button to create the VPN server.

Security Group Setup
The security group that is attached to the VPN server instance interfaces needs to allow both inbound and outbound UDP traffic, since that is how we setup the transport protocol for our VPN server instance.  

Do the following:

• From the VPN servers list select the VPN service you just created.

• Select Attached Security Groups from the the "tab" at the top.

In the inbound section create a rule to allow inbound UDP traffic for the VPN.

Press the Create button

Your inbound rules should look like this now.

Note: Our security group allows all outbound traffic, however if yours does not, you will need to create another rule to allow outbound UDP traffic.

Routes to private network resources

When the VPN client establishes a connection to the VPN server, the VPN server will send the client a list of routes that are then propagated to the client's routing table.  When a client makes a network request to an IP address on one of those subnets, the client knows to send the request over the VPN connection and not to the client's normal network interface.  Therefore, you must update the VPN server's routes so that the client can connect to those resources on the private VPC network or other IBM Cloud private networks.  In this example, we will create routes for each of the 3 VPC subnets, the private IBM Cloud service endpoint subnet (cse), and the private IBM Cloud IAAS services endpoint subnet (DNS servers, etc).

Do the following:

• Get the list of subnets for the VPC:

From the VPN server, select the VPN server routes tab and do the following:

• Create a route for each subnet with the Deliver action

• Create a route for the CSE subnet, 166.8.0.0/14 with the Deliver action. Note

• Note: For ROKS 4.13 or later, the Openshift dashboard now uses a VPE address. A VPE is an address within the subnet’s address range and therefore that address must be part of the routes. For more information please see https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster#vpc_vpe.

• Create a route for the IAAS services subnet, 161.26.0.0/16  with the Translate action

Note: In order for the VPN server to forward traffic to the destination service, your outbound security group must allow that traffic to those destinations.  For example: Since our default security group outbound rule allows all traffic, there is nothing we need to do, however your security group might be different so verify the security group will allow the correct outbound traffic to those destinations for example you will need to allow TCP traffic to 166.8.0.0/14 and the other subnet routes you added. 

Client Setup

For this blog we will use the TunnelBlick VPN Client app (3.8.8d) on Mac Sonoma. OpenVPN clients work for the Mac and other platforms as well.  See the documentation for a complete list and versions of supported VPN clients.

From your VPN Client Server instance select the Clients tab at the top.

Click the Download client profile template button which will download the open vpn configuration file to your workstation.   

Download the client certificate you want to use from Secrets Manager. This will download a zip file with both the private key and public certificate.

Unzip the zip file to a convienent location.

Update the openvpn configuration file with the path to the certificates.

vi vpn-for-the-blog.ovpn

At the bottom of the file you can uncomment the cert and key parms and add the path to the certificates:

# Uncomment the next two lines if certificate-based client authentication is enabled.
#  Ask your VPN administrator provides your client certificate and replace client_public_key
#  with your client certificate filename.
cert /Users/tej/toddjohn-vpn-cert/toddjohn-vpn-cert.pem
key /Users/tej/toddjohn-vpn-cert/toddjohn-vpn-cert.key

Once you've saved the changes to the file, you can drag and drop this file into Tunnelblick configurations and connect to the VPN. 

Once Tunnelblick connects to the VPN server, you can now connect to your private IKS or ROKS clusters.

Besides verifying from the client side, you can check your VPN Server instance on the Clients tab and see if the client is connecting:

A note about client authentication certificates.

When using client certificate authentication, the UI displays the common name from the certificate, and therefore, having each client using their own certificate will make tracking clients easier. In Secrets Manager just issue additional client certificates with a unique common names and use that certificate and private key in the user’s open vpn configuration file.  As long as the those certificates are signed with the same CA then there is no need to add that certificate to the VPN server.

For example, we created a certificate for Neela as well, and when she connects to the VPN server her common name appears in the connected clients list.

Connecting to your classic private networks

There are 2 ways to connect your VPN to classic private networks:

• Enable classic access when you create the VPC or

• Creating and using the transit gateway service which is the preferred method.

Once you've established connection with either of the above the methods, you can simply add VPN routes to those subnets. For example, if we need to access classic resources on the classic subnet 10.189.27.128/26 create the route with the translate action and restart the vpn client.  Note: The action must be Translate for classic routes.

Conclusion

You have successfully created a Client to Site VPN service and connected your Mac to it using Secrets Manager to manage the certificates. You can now access your resources like IKS and ROKS clusters that are on the IBM Cloud private network from almost anywhere you happen to be. Enjoy that beverage at the coffee shop while keeping your business running smoothly. If you have questions, please feel free to contact us.

Contact Us

Neela Shah - neela@us.ibm.com

Todd Johnson - toddjohn@us.ibm.com

References

https://cloud.ibm.com/docs/vpc?topic=vpc-client-to-site-vpn-planning

https://cloud.ibm.com/docs/vpc?topic=vpc-client-to-site-authentication

https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started