Extending on-premise Vmware environment with an IPsec tunnel to consume securely IBM Cloud services through the VPC.

Looking at Virtual Private Cloud (VPC) documentation in IBM Cloud we see VMware does not appear as a supported platform to establish an IPsec tunnel (https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-onprem-example). This doesn’t mean you can not use VMware NSX-V Edge to connect to the VPC VPN Gateway to extend your datacenter with IBM Cloud services, and consuming them securely through the tunnel.

The final picture after the IPsec tunnel creation looks like this:

Target Architecture

In order to establish the tunnel we need to follow the next steps:

  1. In the ‘VPC/VPN Gateways’ menu, go to the ‘IKE Policies’ tab and create an IKE policy, with these values:

IKE version -> 1

Authentication -> SHA256

Encryption -> aes256

Diffie-Hellman Group -> 5

Key Lifetime -> 28800

IKE Policy
  • In the ‘VPC/VPN Gateways’ menu, go to the ‘IPsec Policies’ tab and create an IPsec policy, with these values:

Authentication -> sha256

Encryption -> aes256

Perfect Forward Secrecy -> Disable

Key Lifetime -> 36000

IPsec Policy
  • Create a VPN Gateways, the  key parameters to set are:

Mode: Route-based

Peer Gateway Address: The IP of the on-premise NSX-V Edge VPN termination.

Pre-Shared Key: The same key should be set on both ends.

IKE policy: The  IKE policy created with the parameters stated before.

IPsec policy: The IPsec policy created with the parameters stated before.

VPN Gateway
  • Create a route table in the IBM Cloud VPC:

Traffic Type: Eggress

Route Table Traffic Type
  • Once that the ‘route table’ is created, select it and create a route to the networks exposed in the VMware environment:

Destination Source: The network exposed on the VMware environment.

Location: It is needed to create one per zone where there are resources that need to reach the VMware environment.

Action: Deliver

routingTableView.routes.tableHeader.type: VPN connection

VPN gateway: The VPN gateway to be applied on.

VPN connection: The IPsec tunnel to apply the route to.

Route
  • On the VMware side go to the ‘Networking & Security’ menu, later to the ‘NSX-V Edge’ select the edge exposed to the Internet, go to the VPN tab and add an IPsec VPN site:
New IPsec VPN site

Local ID: Same as the local endpoint.

Local Endpoint: The IP exposed on the Internet.

Local Subnets: The subnets on the VMware environment to be exposed to the IBM Cloud VPC environment.

Peer ID: Same as the peer endpoint.

Peer Endpoint: The IP of the VPC VPN public GW endpoint.

Peer Subnets: The subnets exposed on the IBM Cloud VPC environment. It includes also the IP of the private service endpoint for the services we want to consume in IBM Cloud, it could be a single IP or a network range.

New IPsec VPN

On the ‘Tunnel Configuration’ tab, fill with the same parameters that we created the IPsec and IKE policies in IBM Cloud:

IKE version: IKEv1

Digest Algorithm: SHA_256

Encryption Algorithm: AES256

Authentication: PSK

Pre-Shared key: ***** (same pre-shared key that was set in IBM Cloud)

Hellman Group: DH5

Tunnel Configuration Tab

On the ‘advanced’ tab:

Perfect Forward Secrecy (PFS): Disabled

Advanced Tab
  • On the tab SSL VPN-Plus, on the ‘Private Networks’ section add the routes to the VPC. This enables the users connected to the NSX-V Edge via the NSX-V VPN, to reach IBM Cloud services via the IBM Cloud private endpoints.

Networks: Network range in CIDR notation of the networks exposed in IBM Cloud VPC and private service endpoints.

Add Private Network
  • Create a SNAT rule to mask the traffic from the NSX-V VPN users to reach IBM VPN VPC and service endpoints networks, via the IPsec tunnel stablished.

Original Source IP/Range: The network range used by the NSX-V VPN to assign IPs to the VPN NSX-V users.

Destination IP/Range: The network range of the network exposed in the IBM Cloud VPN VPC and private service endpoints.

Translated Source IP/Range: the gateway of the local network exposed to the IBM Cloud VPN VPC via the IPsec tunnel.

SNAT rule

Let’s check this approach work!

I deployed a PostgreSQL instance exposed only on a private service endpoint (no internet connection)

PostgreSQL Private Service Endpoint

I also deployed a Red Hat Openshift Kubernetes Service (ROKS) instance exposed only on a private service endpoint (no internet connection):

ROKS Private Service Endpoin

If we are NOT connected to the VMware VPN we can NOT reach the PostgreSQL service as we can see in the screenshot below:

PostgreSQL without VPN connection

The same happens with Red Hat Openshift Kubernetes Service:

ROKS without VPN connectio

If we are connected to the VMware VPN we can reach the PostgreSQL service as we can see in the screenshot below:

PostgreSQL with VPN connection

If we are connected to the VMware VPN we can reach the ROKS instance as we can see in the screenshot below:

ROKS with VPN connection

Next Steps: Terminate VPN IPsec tunnel on NSX-T instead NSX-V

Hope this helps you guys!!!

***Written in collaboration with Sebastian Chaparro***

Leave a Reply

Your email address will not be published. Required fields are marked *