Who wants to manage their own VPN stack when you can easily provision a fully managed client-to-site VPN?
This post is a follow-up to a post I wrote two years ago called “Access Virtual Servers in a Virtual Private Cloud with OpenVPN.” At that time, I was going through the installation and configuration of OpenVPN to access your VPC resources. Since then, a new, fully managed option is available with Client VPN for VPC that removes the need to install and maintain your own OpenVPN server.
Client VPN for VPC provides client-to-site connectivity, which allows remote devices to securely connect to the VPC network using an OpenVPN software client. This solution is useful for telecommuters who want to connect to the IBM Cloud from a remote location—such as a home office—while still maintaining secure connectivity.
In this post, I will use Terraform to provision and configure and deploy a Client VPN for VPC. Source code and instructions on how to deploy a fully functional example of this architecture can be found in GitHub. I’ll provide a high-level description of the steps, and all steps use Terraform to ease the provisioning and the configuration:
The architecture depicted above involves the following:
IBM Cloud Secrets Manager is used to keep the server and client certificates used by Client VPN for VPC.
Client VPN for VPC pulls the certificates from Secrets Manager during its initialization.
The user establishes a connection to Client VPN for VPC. The computer obtains an IP address in the VPN IP pool.
From there, the user can connect to VSI in VPC or in Classic—provided the right routing configuration has been defined in Client VPN for VPC.
Step 1: Prepare the Client VPN for VPC configuration
The first step is to create the server and client certificates that will be used by Client VPN for VPC. You will find the full instructions in the product documentation. It involves the following:
- Generate server and client certificates.
- Store the certificates as secrets in Secrets Manager.
- Authorize Client VPN for VPC to access these secrets through an IAM authorization.
Step 2: Provision Client VPN for VPC
With the certificates created, we can provision the Client VPN for VPC. It needs, at minimum, one VPC and one subnet. Client VPN for VPC supports a standalone mode (good for testing) and a high availability deployment. We will use the standalone deployment to test the capability:
- The VPC and subnet are created in vpc.tf. They are created with a set of default security group rules to allow SSH, DNS and to reach private endpoints.
- The Client VPN for VPC is created in vpn.tf. It includes a security group to enable SSH connectivity between the hosts connecting to the VPN and the hosts in the cloud. Once provisioned, the VPN is available with a public domain name and uses UDP as transport on port 443.
- An OpenVPN configuration file is generated as part of the Terraform provisioning. It can be used with the OpenVPN client to establish the connection with the Client VPN for VPC server:
Step 3: Test connectivity with other virtual server instances in VPC and Classic
At that stage, you can already test basic connectivity to cloud service endpoints. To take it further, we can provision one virtual server instance in VPC and one in Classic—connected through Transit Gateway—to complete our connectivity tests:
In the above picture, we have the following:
- OpenVPN connected to IBM Cloud through Client VPN for VPC.
- A ping to the Watson Speech to Text cloud service endpoint.
- A secure connection to a VSI in Classic Infrastructure over the private network.
- A secure connection to a VSI in VPC over the private network.
Feedback, questions and suggestions
Go ahead and try the sample on your own from the GitHub source. Although the project creates its own VPC, it can be used as a starting point to deploy OpenVPN in your existing VPCs.
If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@L2FProd).