IBM Cloud Docs
Connect to a VPC landing zone by using a client-to-site VPN

Connect to a VPC landing zone by using a client-to-site VPN

This tutorial dives into the fastest option to get up and running with a client VPN for VPC connectivity. Rather than doing manual steps, you set up an automated way to create a client-to-site VPN connection to one or more landing zones in your account by using Terraform.

Objectives

  • Create a client-to-site VPN connection between the private VPC network and clients by using Terraform automation that's packaged as a deployable architectureCloud automation for deploying a common architectural pattern that combines one or more cloud resources that is designed for easy deployment, scalability, and modularity..
  • Add the deployable architecture to a private catalog in IBM Cloud so you can share it with others in your organization.

Problem

Let's say that you deployed the Red Hat OpenShift Container Platform on VPC landing zone deployable architecture. In the IBM Cloud console, you can see that the cluster is created and working correctly. When you try to access the Red Hat OpenShift web console on the management cluster, you see this error:

It is not possible to access the Red Hat OpenShift console because the cluster is accessible only on the management VPC’s private network, which is locked down and not accessible from the internet.

You might also have connectivity issues to the VPC's private networks if you deploy the VPC landing zone, VSI on VPC landing zone, or the Red Hat OpenShift Container Platform on VPC landing zone deployable architecture.

For example, you ping the network but it times out:

ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
ping: sendto: Host is down
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2
ping: sendto: Host is down
Request timeout for icmp_seq 3
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

How can you securely access that private network to complete operations on resources within these VPCs?

Solution

Several methods exist to establish secure connections to a private VPC network:

  • Client-to-site VPN server and VPN Client - Configure a VPN client application on your device to create a secure connection to your VPC network that uses IBM Cloud VPN for VPC. The IBM Cloud VPN server service has high availability mode for production use and is managed by IBM.
  • Site-to-site VPC VPN gateway - Configure your on-premises VPN to connect to an IBM Cloud VPN gateway by using a statically route-based VPN or a policy-based VPN to set up an IPsec site-to-site tunnel between your VPC and your on-premises private network or another VPC.
  • Direct Link - Establish a direct network connection between your on-premises network and IBM Cloud Direct Link.
  • Access from a different VPC by using a transit gateway - Access your IBM Cloud VPC from another IBM Cloud VPC by using IBM Cloud Transit Gateway.

The VPC landing zone deployable architectures don't enable these connectivity options by default because the solution varies with the deployable architecture configuration.

In this tutorial, you enable the simplest method: a client-to-site VPN connection. But even configuring this option manually takes quite a few steps. You need a client-to-site VPC VPN server, IBM Cloud Security Groups, IBM Cloud Secrets Manager, and certificates. Fortunately, IBM provides these offerings in open source modules that are packaged as a deployable architecture to make the setup and configuration as easy as possible.

The Terraform module that you use in this tutorial creates a single zone client-to-site VPN in an existing landing zone management VPC. The default values in this module are designed to work with the default values used in all three variations of the landing zone deployable architectures: VPC, Red Hat OpenShift, and VSI.

The module creates and configures the following infrastructure:

  • Creates an optional Secrets Manager instance. You can pass a reference to an existing Secrets Manager instance through the existing_sm_instance_guid input variable:

    • Configures a private certificate engine in the Secrets Manager instance
    • Creates a secret group
    • Creates a private certificate (the "secret") from the private certificate engine in the secret group

  • Creates a subnet that is named client-to-site-subnet-1 in the landing zone management VPC.

    The network ACL on this subnet grants all access from any source.

  • Creates a security group that is named client-to-site-sg that allows all incoming requests from any source.

  • Creates an IAM access group that allows users to authenticate and connect to the client-to-site VPN gateway.

  • Creates a client-to-site VPN gateway:

    • Uses the private certificate that is generated and stored in the Secrets Manager instance
    • Locates the gateway in the client-to-site-subnet-1 subnet
    • Attaches the client-to-site-sg to the client-to-site VPN gateway
    • Configures routes to allow access to the landing zone VPCs (management and workload)

Architecture

Architecture
Figure 1. Architecture diagram of the tutorial

Before you begin

This tutorial requires the following setup:

  • A VPC landing zone deployable architecture.

    You also need some information from your VPC landing zone in the tutorial:

    • Find the ID and region of your landing zone’s management VPC. The Terraform module uses IDs rather than names.

  • The list of users who will connect over the VPN connection to your IBM Cloud account.

    The module takes a list of email addresses of the users in your IBM Cloud account. For more information about how to add users, see Inviting users to an account.

  • If you have a Secrets Manager instance, you need the following information:

    The Terraform module creates a Secrets Manager instance if you don't already have one.

    • Copy the region of your Secrets Manager instance by using the IBM Cloud console.
    • Copy the GUID of the instance. You can locate the Secrets Manager GUID in your account from the resource list in the IBM Cloud console as shown in the following screenshot.

      1. Enter secret in the product filter. A list of Secrets Manager instances are displayed.

      2. Click the row to display the details in the sidebar for the Secrets Manager instance that you want to use.

      3. Copy the GUID.

        Example of resource list
        Figure 1. Example view of the resource list in IBM Cloud console

    • If you used a certificate template to create a private certificate that is applied to your Secrets Manager instance, copy the name of the certificate template.
      1. In the resource list, click the name of the Secrets Manager instance that you selected earlier.
      2. Click Secrets engines > Private certificates.
      3. In the Certificate authority table, expand the certificate authority and copy the name of the template.

Set up the deployable architecture

A deployable architecture is infrastructure as code (IaC) that's designed for easy deployment, scalability, and modularity. In this case, the deployable architecture represents a repeatable way to create client-to-site VPN connections for more than one landing zone in your org. It also simplifies how others in your company can set up more VPN connections for their landing zones.

A deployable architecture is a simple and repeatable way to create VPN connections for more than one landing zone in your org. However, you can set up the infrastructure by running Terraform on your computer. Skip to Set up by using Terraform.

A private catalog hosts your deployable architectures for users in your organization.

Follow these steps to use the IBM Cloud console to set up a deployable architecture with the IBM Cloud console and add it to a private catalog.

  1. Create a private catalog to hold your organization’s custom deployable architectures.

    1. Go to Manage > Catalogs > Private Catalogs in the IBM Cloud console.

    2. Click Create.

      If your organization has a private catalog for deployable architectures, select the catalog and click Add.

    3. Give the catalog a name. For example, "My deployable architectures".

    4. Click Create.

  2. Select the catalog and click Add to add the client-to-site VPN to the new private catalog with the following settings.

    Alternatively, you can use the IBM Cloud CLI. See Onboard a deployable architecture to a private catalog by using the CLI.

    Update the information for Source URL and Software Version to match the latest release of the client-to-site VPN GitHub module.

  3. Click Add product.

  4. Skip to Validate the deployable architecture.

Onboard a deployable architecture to a private catalog by using the CLI

If you already added your deployable architecture to your private catalog in the previous section, skip to Validate the deployable architecture.

Follow these steps to use the IBM Cloud console to onboard a deployable architecture to a private catalog with the IBM Cloud CLI.

  1. Make sure that you have a recent version of the IBM Cloud CLI installed.

  2. Run the following command:

    • Edit the --catalog option to match the name of your private catalog.
    • Update the --target-version and --zipurl to match the latest release of the client-to-site VPN GitHub module.
    ibmcloud catalog offering create --catalog "My deployable architectures" --name "deploy-arch-ibm-slz-c2s-vpn" --target-version 1.7.0 --zipurl https://github.com/terraform-ibm-modules/terraform-ibm-client-to-site-vpn/archive/refs/tags/v1.7.0.tar.gz --include-config  --variation "standard"  --format-kind terraform  --product-kind solution --install-type extension`

  3. When the command finishes successfully, go to your private catalog in the IBM Cloud console and verify that the new version is listed in Draft state.

  4. Skip to Validate the deployable architecture.

Set up by using Terraform

This section includes steps to use Terraform on your computer to set up the infrastructure. If you set up a deployable architecture in the previous section, skip to the next section, Validate the deployable architecture.

To set up the VPN server cloud resources by using Terraform on your workstation, follow these steps.

Before you begin with the Terraform setup

Make sure you have your development environment configured:

Clone the repo and configure the module

  1. Clone the relevant modules to your computer. Update the --branch to match the latest release of the client-to-site VPN GitHub module.

    git clone --branch v1.7.0 https://github.com/terraform-ibm-modules/terraform-ibm-client-to-site-vpn

  2. Change to the directory that contains the Terraform module to deploy the client-to-site VPN in a landing zone VPC:

    cd terraform-ibm-client-to-site-vpn/extensions/landing-zone

  3. Create a file called terraform.tfvars with a text editor.

    vi terraform.tfvars

  4. Add the following lines to the terraform.tfvars file.

    ibmcloud_api_key              = "<IBM Cloud API key>"

prefix                        = "<prefix for the new resources>"

/*
ID, not VPC name.  You can find the information in the Optional inputs
section of the console or from the "ibmcloud is vpcs" CLI command
*/
vpc_id                         = "<ID>"

/*
Set to the region referred to by the `vpc_id`
input variable, where the VPC is located.
*/
region                         = "<region where the existing VPC is located>"
resource_group                 = "<landingzone_prefix>-management-rg"
existing_sm_instance_guid      = "<secretmgr_guid>"
existing_sm_instance_region    = "<secretmgr_region>"

/*
The following list identifies users who are authorized to access
the network that uses the new VPN connection. Make sure that
they are members of your IBM Cloud account.
*/
vpn_client_access_group_users  = ["user1@example.com","user2@example.com"]

/*
Certificate common name, a fully qualified domain name or host domain
name for the certificate to be created
*/
cert_common_name               = "<example.com>"

/*
CIDR range to use from the first and second zone in the region to
enable HA. If vpn_subnet_cidr_zone_2 not specified, VPN will only be
deployed to a single zone (standalone deployment).
*/
vpn_subnet_cidr_zone_1         = "<cidr_zone_1>"
vpn_subnet_cidr_zone_2         = "<cidr_zone_2>"

/*
Optionally pass a list of existing subnet names
(supports a maximum of 2) to use for the client-to-site VPN. If
no subnets passed, new subnets will be created using the CIDR
ranges specified in the vpn_subnet_cidr_zone_1 and
vpn_subnet_cidr_zone_2 variables.

existing_subnet_names = [
    "<landingzone_prefix>-management-vsi-zone-1",
    "<landingzone_prefix>-management-vsi-zone-2"
]
*/

    • Replace the values with the ones that you looked up in Before you begin.

    • If you don’t already have a Secrets Manager instance, remove the lines that start with existing_sm. The Terraform module creates a Secrets Manager instance if you don’t already have one.

    • If you do have a Secrets Manager instance that you specified in the variables that start with existing_sm, and the value for the certificate_template_name input variable that you looked up in Before you begin is different than the default name my-template, add an entry to the terraform.tfvars file with the name that matches the input variable, as in the following example.

      existing_sm_instance_guid      = "<secretmgr_guid>"
existing_sm_instance_region    = "<secretmgr_region>"
certificate_template_name      = "<template_name>"

    Don't check in this file to version control because it contains the API key secret. If you don't want to save the information in the file, you can pass the variable to Terraform through command-line arguments.

    To support HA (high availability), you need to set the value for vpn_subnet_cidr_zone_2 variable.

  5. Save the terraform.tfvars file, and then run the following commands. Enter yes to apply the plan when prompted:

    terraform init
terraform plan -out myplan
terraform apply "myplan"

    The script takes approximately 15 minutes to complete.

    The last few lines of the output of the script should look something like the following example:

    Outputs:

resource_group_id = "737bb1c6828346a5a961638973cafd31"
resource_group_name = "ccm-management-rg"
server_cert_id = "dc0e30d0-d16c-6d91-6e17-ae241b68b955"
vpn_id = "r014-fb0de1e3-2ea4-4f00-b557-75b91c24d2ca"
vpn_server_certificate_secret_crn = "crn:v1:bluemix:public:secrets-manager:us-east:a/f8ce6d5aa4cf4f45bf77ff019b6d9463:66b08f1d-d3ac-4583-b35e-da08145e5820:secret:dc0e30d0-d16c-6d91-6e17-ae241b68b955"

    If the script runs successfully, the cloud VPN resources now exist and are configured.

  6. Skip to Configure the OpenVPN client.

Validate the deployable architecture

The deployable architecture isn't visible to others until you validate it and make sure that users can provision it with your default input variables. To validate a deployable architecture in a private catalog, you specify input values that are passed to Schematics, which then runs the Terraform plan and apply commands in IBM Cloud to make sure that the deployable architecture runs successfully.

Validate the latest version of the deployable architecture in your private catalog.

  1. Select Validate from the … menu on the version.

  2. Follow the steps to read the license file.

  3. Select a Schematics instance to run the DA.

  4. Specify the input values that are specific to your landing zone:

    • API key: Select an API key from your Secrets Manager instance.

    • vpc_id = "<VPC ID>"

    • region = "<Where the existing VPC is located>"

      Replace the ID and region values with the ones that you looked up in Before you begin.

    • resource_group = "<landingzone_prefix>-management-rg"

    • existing_sm_instance_guid = "<secretmgr_guid>"

    • existing_sm_instance_region = "<secretmgr_region>"

    • vpn_client_access_group_users = ["user1@example.com","user2@example.com"]

      This list identifies users who are authorized to access the network that uses the new VPN connection. Make sure that they are members of your IBM Cloud account.

  5. Click Validate.

    After a few minutes, if the inputs are correct and the validation completes successfully, the client-to-site VPN-related cloud resources are deployed in your account.

  6. Share the deployable architecture:

    Now that the client-to-site VPN deployable architecture is imported and validated in your private catalog, you can share the deployable architecture with other developers in your organization. By sharing the deployable architecture, you save them the time of finding and testing the automation for the VPN connectivity each time that they stand up a new landing zone.

    1. Add configurations of the client-to-site VPN deployable architecture to the project:

      From your private catalog, you can add configurations to the same project that contains your landing zone VPC deployments. Each configuration can support a different set of users with access by using VPN profiles that are specific to each configuration.

    If you have other Terraform automation that you want to package as a deployable architecture for your teams to reuse, check out Turn your Terraform templates into deployable architectures.

Configure the OpenVPN client

After the VPN server cloud resources are deployed, set up the OpenVPN client on devices that will access your landing zone.

  1. Download the OpenVPN profile from the VPN server

    • By using the IBM Cloud console:

      1. Click the Navigation menu icon Navigation menu icon, and then click VPC Infrastructure > VPNs in the Network section to open the VPNs for VPC page.
      2. Click the Client-to-site servers tab and select the client-to-site VPN server that you created.
      3. Click the Clients tab. Then, click Download client profile.

      Or

    • By using the IBM Cloud CLI:

      ibmcloud is vpn-server-client-configuration VPN_SERVER --file client2site-vpn.ovpn

      Look for the VPN_SERVER ID in the output of the Terraform apply from the validation step. If you don't find it there, follow the previous steps to download the profile and look in the <vpn_server>.ovpn file.

  2. Set up the client:

    You can follow the steps in Setting up a VPN client.

    1. Download and install the OpenVPN client application from https://openvpn.net.
    2. Open the OpenVPN client application, and import the client2site-vpn.ovpn file.
    3. Enter one of the IBM Cloud email addresses that was configured to access the VPN as the user ID.

  3. Go to https://iam.cloud.ibm.com/identity/passcode in your browser to generate a passcode. Copy the passcode.

  4. Return to the OpenVPN client application and paste the one-time passcode. Then, import the client2site-vpn.ovpn certificate file.

Using client certificates rather than one-time passcodes

If you want to configure client certs on the VPN rather than using a one-time-passcode, follow the instructions in the Managing VPN server and client certifications section of the client-to-site documentation.

Test access to the Red Hat OpenShift web console

If your landing zone includes a Red Hat OpenShift cluster, you can now test that you have access to the web console.

  1. Open https://{DomainName}/kubernetes/clusters in your browser.
  2. Select the cluster details for the management cluster in your landing zone.
  3. Click OpenShift Web Console in the upper right to access your Red Hat OpenShift web console.
  4. Repeat steps (2) and (3) to test connectivity to the landing zone’s workload cluster.

Test your VPN connection

On the device that has the OpenVPN client, ping the 10.* network (which is in your management VPC).

ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=19.920 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=19.301 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=14.490 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=20.896 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=13.938 ms
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.938/17.709/20.896/2.904 ms

If you see no timeouts or other errors, your local workstation has connectivity to the VPC’s private network.

Solving connectivity issues

In the following error, OpenVPN has an active connection, but can't reach a server on your private VPN subnet. Check the local network that your device connects through. Some newer routers allocate IP addresses in 10.* range rather than 192.168.*.

error: dial tcp: lookup YOUR_SERVER_URL on 10.0.0.1:53:
read udp 10.0.0.2:0->10.0.0.1:53:
i/o timeout- verify you have provided the correct host and port and that the server is currently running.

Summary

Automating the creation of client-to-site VPN connections to your secure landing zones is straightforward when you use the capabilities of deployable architectures on IBM Cloud.