June 22, 2021 By Todd Johnson
Nina Goradia
Neela Shah
7 min read

How to set up a virtual private network connection between an IBM Cloud VPC VPN and a strongSwan VPN running on your home network.

As an increasing number of enterprise workloads are moving to public cloud providers like IBM, and with cyber attacks on the rise, security becomes front and center. With IBM Cloud, you can create Kubernetes clusters in a virtual private cloud (VPC) that let your enterprise establish its own private cloud-like computing environment on public cloud infrastructure. A VPC gives an enterprise the ability to define and control a virtual network that is logically isolated from all other public cloud tenants, creating a private and secure place on the public cloud.

After you have a secure environment for your workloads, performing any operations or checks on your Kubernetes cluster or resources becomes cumbersome because the cluster is on a private network and not accessible from the outside world. As many people continue to work from home, you might wonder how you can access these private resources in the VPC from your home network. We will describe how to set up a virtual private network (VPN) connection between an IBM Cloud VPC VPN and a strongSwan VPN that runs on your home network.

Note that this blog outlines just one way of setting up a site-to-site IPsec VPN to access resources in IBM Cloud VPC infrastructure from your home network. It is not intended to be an exhaustive discussion of how to set up this kind of connection or all of the various configuration options of IPsec and strongSwan.

Overview

We will be setting up a VPN connection from your home network to IBM Cloud VPC infrastructure by using two VPN services: strongSwan VPN for your home network, and the IBM Cloud VPC VPN service for the VPC network that contains your cluster. In our example, we have a single VPC with VPC resources in three different availability zones. For security purposes, the public IP addresses are obfuscated using .x.y.z. Your IP addresses will be different, so adjust the IP address values accordingly:

Note: StrongSwan uses the terms left and right to indicate the two sides of the tunnel. In this document, the left side is the home network and the right side is the IBM Cloud network.

IBM Cloud VPC network (the right side)

Prerequisites

  • IBM Cloud VPC 
  • VPC subnets
  • A Kubernetes or OpenShift cluster in the VPC
  • Your home network CIDR, which you typically find in the configuration settings of your home router

Create a VPC VPN and the VPN connection

To get started, create a VPN gateway for VPC:

  1. Enter a name for your VPN.
  2. Select your resource group.
  3. Select the region that your VPC is in.
  4. Select your VPC.
  5. Select the subnet where the worker nodes in your cluster are. (Note: Currently, these instructions are for a single zone only.)
  6. For mode, select Policy-Based.
  7. Give the connection a name, such as home. 
  8. In the peer gateway address field, enter the public IP address of your home network. You can usually find this in the network settings of your home router.  
  9. In the pre-shared key field, enter any string of the appropriate size. Just remember what you enter here because you will need it later on.
  10. In the local subnets field, enter the IP address range of your VPC subnet and the Cloud Service Endpoint subnet constant value of 166.8.0.0/14, separated by a comma.
    • Example: 10.241.128.0/18,166.8.0.0/14
    • Note that even though you previously selected the subnet on this form, that subnet information is not carried through to the connection, so you have to enter it again in this field.
  11. In the Peer subnets field, enter your home network CIDR. For example, 192.168.1.0/24.
  12. Click the Create VPN Gateway button to create the VPN and the VPN connection. Note that the VPN connection will show as down until the Home network side is configured.
  13. After the VPN Gateway is created, make a note of the public VPN gateway IP address.

Repeat these steps to set up at least one VPN gateway and connection for each zone and associated VPC subnet that your cluster is in. 

Update the VPC security group

Verify your VPC security group allows the traffic that you want. For example, in order to access Kubernetes or OpenShift clusters in IBM Cloud, make sure TCP ports 30000-32767 are open for inbound traffic:

Home network (the left side)

Prerequisites

Before you begin, you will need access to your home router.

  1. Typically, in a home network, machines are assigned IP addresses via DHCP by the router. However, we don’t want the machine running the VPN’s IP address to change because that IP address is part of the configuration. I used the home router settings to give the machine a static IP address of 192.168.1.2.
  2. Obtain the WAN IP address of your home router. This IP address can usually be found in the WAN section of the router settings. This IP address is typically assigned dynamically by your internet service provider. (See Notes section at the end.)

Options

There are two ways to set up your home side

  1. Run the VPN gateway on your laptop or computer.
  2. Set up the VPN gateway on another machine on your home network and route through that machine from your laptop or computer.

These instructions were tested using both a MacBook Pro (Catalina) and a Raspberry Pi Model 4b (Raspbian GNU/Linux 10 (buster)) as the VPN gateway. However, any fairly modern Linux machine should work. 

Setting up the VPN gateway 

  1. On the machine that you want to use for the VPN, install strongSwan. In the command line, you can run the following command.
    • Pi: sudo apt-get install strongswan
    • MacOS: brew install strongswan
  2. Add the VPC connections to the IPsec configuration file, located at /etc/ipsec.conf (MacOS: /usr/local/etc/ipsec.conf). The following example shows a connection to three VPC subnets (each subnet has its own VPC VPN). Depending on your VPC environment, you might have only one VPC subnet or more than three. Remember, left fields mean the home network, and right fields mean the VPC network:
    conn %default
            type=tunnel
    
            auto=route                                      
            esp=aes256-sha256!
            ike=aes128-sha1-modp1024!
            left=192.168.1.2                            <==== Private IP address of your home network VPN machine.
            leftsubnet=192.168.1.0/24          <===== Private subnet of your home network.
            leftauth=psk
            rightauth=psk
            keyexchange=ikev2
            leftid="177.x.y.z"            <======== The WAN IP address of your home network (from step 2 above), in quotes
            lifetime=10800s
            ikelifetime=36000s
            dpddelay=30s
            dpdaction=none
            dpdtimeout=120s
    
    conn ibmcloud-vpc-subnet-1     <====== The name of the connection (can be whatever you want)
            rightsubnet=10.241.0.0/24       <======  the VPC subnet range (should match the VPN connection "local subnets" (#10))
            right=52.116.x.y                <====== Public ip of the VPC VPN gateway
            rightid="52.116.x.y"          <====== Public ip of the VPC VPN gateway, in quotes
                                         
    conn ibmcloud-vpc-subnet-22
            rightsubnet=10.241.64.0/24
            right=169.63.x.y
            rightid="169.63.x.y"
            
    conn ibmcloud-vpc-wdc-subnet3
            rightsubnet=10.241.128.0/18,166.8.0.0/14 <==== the VPC subnet range, cloud service endpoint subnet, comma-separated
            right=52.117.x.y
            rightid="52.117.x.y"
  3. Edit the /etc/ipsec.secrets (MacOS: /usr/local/etc/ipsec.secrets) to add the VPC VPN pre-shared key for each tunnel. The format is leftsideid rightsideid : PSK "your secret key". For example:
          177.x.y.z 52.117.x.y : PSK "averysecurekey1"
          177.x.y.z 52.116.x.y : PSK "averysecurekey2"
          177.x.y.z 169.63.x.y : PSK "averysecurekey3"
  4. Enable IP forwarding on your VPN machine:
    • Edit /etc/sysctl.conf
    • Uncomment or add: net.ipv4.ip_forward=1
    • Run sysctl -p to reload the sysctl settings
    • (MacOS: sudo sysctl -w net.inet.ip.forwarding=1)
  5. Establish the VPN connection:
    • Run sudo ipsec start
    • Check the VPN connection by running sudo ipsec status. The output looks similar to the following:
    • If you don’t see a tunnel for all your connections, check the log files located in /var/log/syslog. On MacOS, follow these instructions to enable logging.
    • If you need to make changes to any config files, run sudo ipsec restart.
    • Important note: Since we are using “auto=route” configuration, the VPN tunnel is not established until traffic flows to resources on the VPN subnet. Therefore, the the VPN connection on the IBM Cloud side continues to show “down” and the ipsec status on the home VPN shows “none” for Security Associations.
  6. Verify the connection:
    • Ping one of your worker node’s private IP address from the VPN machine or the subnet router. For example, 10.241.128.1:
    • If you now run sudo ipsec status again, you see that the Security Association is created for that tunnel, and the IBM Cloud VPN connection shows an “up” status.

Option “b” setup: Routing from your laptop via a VPN Gateway

If you set up your home network VPN gateway on a machine other than your laptop, you can route from your laptop via the VPN. 

Set up the routing table on your laptop or computer to route the network traffic which is destined to the VPC resources through the VPN gateway machine:

  1. Add the following routes to your computer. In our example, the VPN gateway machine has the IP address of 192.168.1.2. For each VPC subnet, add a route:
    sudo route -n add -net 10.241.0.0/24 192.168.1.2
    sudo route -n add -net 10.241.64.0/24 192.168.1.2
    sudo route -n add -net 10.241.128.0/18 192.168.1.2
  2. Add a route to the cloud service’s private endpoint subnet: sudo route -n add -net 166.8.0.0/14 192.168.1.2
  3. Verify you can ping your VPC subnets and cluster from your computer.

You should now be able to access your Kubernetes or OpenShift clusters over their private service endpoints and other VPC resources that you might have from your computer on your home network.

Conclusion

Security does not have to come at the cost of compromising access to your private resources. In this blog, we talked about one of the ways to get access to your private clusters in IBM VPC. The approach described in this blog works with clusters created using IBM Cloud Kubernetes Service as well as the Red Hat OpenShift on IBM Cloud service in VPC.

Related docs/links

Note: Most home networks use dynamic public IP addresses, and, therefore, the public IP address can change over time. If your VPN suddenly stops working, this is likely the cause. You will have to update the IPsec configuration and the VPN connections in your VPC with the new IP address.  

Was this article helpful?
YesNo

More from Cloud

IBM Tech Now: April 8, 2024

< 1 min read - ​Welcome IBM Tech Now, our video web series featuring the latest and greatest news and announcements in the world of technology. Make sure you subscribe to our YouTube channel to be notified every time a new IBM Tech Now video is published. IBM Tech Now: Episode 96 On this episode, we're covering the following topics: IBM Cloud Logs A collaboration with IBM watsonx.ai and Anaconda IBM offerings in the G2 Spring Reports Stay plugged in You can check out the…

The advantages and disadvantages of private cloud 

6 min read - The popularity of private cloud is growing, primarily driven by the need for greater data security. Across industries like education, retail and government, organizations are choosing private cloud settings to conduct business use cases involving workloads with sensitive information and to comply with data privacy and compliance needs. In a report from Technavio (link resides outside ibm.com), the private cloud services market size is estimated to grow at a CAGR of 26.71% between 2023 and 2028, and it is forecast to increase by…

Optimize observability with IBM Cloud Logs to help improve infrastructure and app performance

5 min read - There is a dilemma facing infrastructure and app performance—as workloads generate an expanding amount of observability data, it puts increased pressure on collection tool abilities to process it all. The resulting data stress becomes expensive to manage and makes it harder to obtain actionable insights from the data itself, making it harder to have fast, effective, and cost-efficient performance management. A recent IDC study found that 57% of large enterprises are either collecting too much or too little observability data.…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters