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:

In order to establish the tunnel we need to follow the next steps:
- 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

- 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

- 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.

- Create a route table in the IBM Cloud VPC:
Traffic Type: Eggress

- 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.

- 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:

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.

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

On the ‘advanced’ tab:
Perfect Forward Secrecy (PFS): Disabled

- 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.

- 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.

Let’s check this approach work!
I deployed a PostgreSQL instance exposed only on a private service endpoint (no internet connection)

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

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

The same happens with Red Hat Openshift Kubernetes Service:

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

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

Next Steps: Terminate VPN IPsec tunnel on NSX-T instead NSX-V
Hope this helps you guys!!!
***Written in collaboration with Sebastian Chaparro***