Co-authored by:
Hua Ning, Software Developer, IBM Cloud VPN for VPC
Pei Pei Xiao, Software Developer, IBM Cloud VPN for VPC
Yi Jing Zhu, Software Developer, IBM Cloud VPN for VPC
While IBM Cloud Virtual Private Cloud (VPC) provides a logically isolated environment for cloud workloads, accessing these workloads over the Internet is not secure enough, especially for enterprise clients in their sites on-premises. Besides, after the pandemic there has been an unprecedented challenge for enterprises: employees may be working from home or traveling while they still need the access to public cloud resources.
In line with the expectation for a secure and reliable way of accessing IBM Cloud resources, VPN for VPC and Client VPN for VPC have been two options for private connectivity to IBM Cloud VPC.
-
VPN for VPC provides the ability to configure site-to-site VPN tunnels from on-premises sites to a VPN Gateway on IBM Cloud.
-
Client VPN for VPC provides the ability to have individual users securely access their IBM Cloud resources through a secure and encrypted client-to-site connection from anywhere to a VPN Server on IBM Cloud.
Introduction to PowerVS workloads and architecture
Customers choose IBM Power as a most reliable mainstream server, and typically use IBM Power Virtual Server (PowerVS) on IBM Cloud as well for the full enterprise stack with consistent architecture as on-premises. It is very common for Power customers to have a need to securely interact with PoweVS resources from on-premises or any remote location. Dependent on customers’ use cases, VPN for VPC and Client VPN for VPC can be the two cost-effective solutions for site-to-site or client-to-site private connectivity.
For resource isolation and cost optimization, Power customers adopt the transit VPC (hub & spoke) network architecture: shared services are deployed in the central VPC transit (aka hub VPC) and other workloads are spread in spoke VPCs. VPNs, as fundamental components of VPC and a shared solution for users, are often deployed in the VPC transit and can be integrated with Transit Gateway to provide secure access to spoke VPCs.
Use Cases
In the topology illustrated below, the customer deploys their resources in a typical transit VPC architecture: resources reside in the PoweVS workspace as the spoke VPC; a policy-based VPN Gateway is adopted in VPC Transit to establish a site-to-site IPsec VPN connection between VPC Transit and a customer peer gateway on-premises; a Transit Gateway connects the two VPCs.
Before May 3, 2024, there were several limitations with this typical configuration:
-
To establish a VPN connection with the VPN Gateway, the customer peer gateway on-premises must be reachable on the Internet through a static public IP.
-
To advertise prefix and routes on-premises to the PowerVS workspace, customers had to work around a limitation by adding the on-prem CIDR as a dummy prefix as if it were part of VPC Transit.
With these known limitations Power customers felt a pressure: the peer gateway may be hidden behind a firewall without a public IP, but existing infrastructure on-premises like firewalls and gateway appliances were set up a long time ago and couldn’t be easily replaced or updated; using the transit VPC structure, they already had to deal with multiple VPC components, subnets, address prefixes, routing tables and the dummy prefix workaround added to the complexity.
In another similar use case Power customers use the Client VPN for VPC as the client-to-site connectivity solution in a transit VPC architecture to enable individual users to securely access their PoweVS workspace (as the spoke VPC). There’s also a known limitation that customers had to let VPN Server in VPC Transit to translate end user IPs for route propagation and all connected clients when monitored from the PoweVS workspace were “invisible” - hidden as the private IP of the VPN Server, which was not secure enough in a highly regulated workload.
A couple of feature enhancements were recently introduced to VPN and VPC to address these limitations and make things easier for customers especially those on PowerVS workloads.
-
When establishing a VPN connection between on-premises and IBM Cloud, customers can specify the peer gateway using its Fully Qualified Domain Name (FQDN) if it does have a fixed public IP address. Alternatively, customers can choose to initiate negotiations from on-premises making IBM Cloud VPN Gateway the responder, and optionally set up advanced IKE identities to authenticate the connection. This avoids the need of replacing customers’ peer gateway, modifying the existing configuration on-premises, or the complexity of working around the limitation.
-
In the Transit VPC architecture customers can choose to advertise custom prefixes by configuring the ingress routing table to accept routes from VPN Gateway or Server enabling interconnectivity across all VPCs using Transit Gateway.
The following section describes the simplified configuration steps after these enhancements. To know more about the configuration process, see this video.
Configuration Steps
Site-to-site scenario
The site-to-site VPN connectivity topology below using transit VPC has the following assumptions:
-
The on-premises site has a firewall to protect the private network (10.240.0.0/24 in the diagram) , including the peer gateway.
-
The on-premises firewall has a FQDN powervs.slcdnservice.net without a public IP.
-
VPN Gateway is in 172.18.2.0/24 subnet in VPC Transit and uses policy mode.
Step 1 : Create a policy-based VPN Gateway in VPC Transit. Read more instructions here.
Step 2: Create a VPN connection. Use the FQDN of the peer firewall as the peer gateway address, and choose the Peer only establish mode for the connection. Read more instructions here.
Step 3: Use IKE advanced configurations to validate the connection.
Step 4: Configure the on-premises gateway accordingly so that the connection can be successfully established. Read more instructions here.
Step 5: Configure Transit Gateway to connect two VPCs. Read more instructions here.
Step 6. Navigate to the routing table in VPC Transit to turn on route advertisement.
Customers should be able to access the Virtual Server in PowerVS workspace from on-premises.
Client-to-site scenario
The client-to-site VPN connectivity topology below using transit VPC has the following assumptions:
Step 1: Create a VPN Server in Transit VPC. Read more instructions here.
Step 2: Set the routing table to accept routes from VPN server.
Step 3: Add the VPN Server Routes to PowerVS workspace and set the action to Deliver. Read more instructions here.
Customers using an OpenVPN client should be able to access the Virtual Server in PowerVS workspace (192.168.8.0/24).
Technical Considerations
Route quota and advertisement considerations
While enabling route advertisement to TGW/DL for ingress routing table integration, there is a known limitation that the maximum routes advertised is 15 per VPC. To minimize the number of VPN based routes advertised to give customers enough quota for their own configurations, we thought of many solutions to reduce the number of advertised routes:
-
Only create advertised route in the ingress routing table,
-
Only create advertised route after the site-to-site VPN connection is up,
-
Only create advertised route in specific zone for VPN server,
-
Disable route advertisement if the routing table becomes egress.
There is also an extra benefit with creating advertised route only after site-to-site VPN connection is up: The VPN gateway’s connection status could be easily extracted from the backend DB instead of the VPN gateway instance itself. This helps resolve a long-existing performance issue and improve the performance of VPN gateways.
Seamless DNS Configuration Management with dhclient
Our latest enhancement empowers customers to specify the peer VPN device using FQDNs, providing greater flexibility and ease of management. This feature also offers customers the choice between utilizing the VPC default DNS server or a private DNS service for their VPC network, catering to their specific configuration needs.
To seamlessly integrate these DNS configurations with the VPN gateway, we've implemented a sophisticated solution. We've deployed a dedicated dhclient service within a separate network namespace, known as the data network namespace. This separation ensures that any DNS changes initiated by the customer remain isolated within this namespace, safeguarding the integrity of the management network namespace reserved for administrative tasks.
By leveraging a separate dhclient instance and monitoring DNS server changes via the DHCP protocol, we've automated the process of updating DNS configurations for the VPN gateway. This automation guarantees that changes made by the customer are promptly reflected in data namespace without impacting the management network namespace. As a result, customers can effortlessly manage their DNS configurations while administrators can maintain operational efficiency and security.
Summary
VPN for VPC and Client VPN for VPC are recommended as two of the private connectivity solutions for secure management and data transfer from on-premises site or remote to IBM Cloud including VPC, Power workspaces and Classic for their advantages in cost saving and provisioning efficiency. The newly added features further extends the VPN capability to better support PowerVS workload.