As enterprises start adopting cloud, the most prevalent approach is to use cloud as an extension of their on-premises infrastructure. OCI facilitates this hybrid approach by providing various networking constructs such as IPSec, FastConnect, DRG, etc. Once connectivity between on-premises datacenter and OCI is established, resources such as compute hosts or instances can be deployed on OCI and accessed from on-premises. Since in this scenario OCI has been used as an extension of the enterprise's data center, it is a best practice to deploy the instances on private subnets. For higher availability, redundancy, etc., these instances can be load balanced. And a private load balancer can be used for that purpose. This will ensure that the instances can never be accessed from the internet while providing service to on-premises clients. The following figure illustrates this scenario:

In the above figure, Fast Connect private peering is used. An alternative could be IPSec VPN.

The Problem

Although the above scenario depicts the primary use case of hybrid cloud, there can be some wrinkles along the way. There may be requirements to access these private OCI computes from the internet. For example, customers can deploy Oracle ESSbase servers on private subnets. They may also use Oracle ERP Cloud and there can be a requirement where ERP Cloud needs to access ESSbase. Since ERP Cloud is outside OCI, ERP requests would be required to enter the VCN through an Internet Gateway. However, the route to the ESSbase servers traverses through the private load balancer which is inaccessible from outside OCI. The following figure depicts this challenge.

A Solution

So, what to do now? Any solution will generally require three steps (see next section though) - i) the ERP requests will enter the VCN via the Internet Gateway, ii) the requests need to be handled in a public subnet ( a consequence of step i above), and iii) forwarded to the private load balancer for onward journey to the ESSbase servers. How to achieve this? Use a public load balancer!

With the public load balancer in the mix, ERP requests can be sent to the public load balancer endpoint (its public IP address). The public load balancer can be configured to have the private load balancer in its backend set. This will result in the public load balancer forwarding the traffic to the private load balancer, which in turn forwards the traffic to one of the backend ESSBase servers. The role of the public load balancer is interesting: it does not do any "load balancing" per se. It merely acts as a conduit between the internet and the internal load balancer, that is, it acts as a traffic forwarder! However, it serves our purpose here.

To prevent general access to the public load balancer, the security list of the public load balancer's (public) subnet can be tightened to allow ingress traffic only from the ERP Cloud.

Any Alternatives?

Well, any alternative solution will still require to satisfy the 3 steps outlined in the previous section. There is no native Oracle product or resource which can fit the bill. However, with a public load balancer, you may devise a plausible solution:

In this solution, only a public load balancer is required. The backend ESSBase servers are still in private subnets hence inaccessible from the internet. The ERP Cloud has access to ESSbase as earlier via the public load balancer. However, access from the customer data center is now directed to the public load balancer using FastConnect public peering. This solution works, however, it requires additional configuration for FastConnect public peering and the customer has to bear expenses for that:  port usage, provider charges, etc. I say "additional" configuration since the public peering will be in addition to the private peering or IPSec connectivity which the customer will require to access other private resources in the VCN.  For example, in the above figure, the customer has deployed a database system in a private subnet which can be accessed only using either IPSec or private peering.

Another possibility could be to route the ERP traffic via the customer's data center. However, that may require quite a few touch points within the customer's infrastructure.

This blog post will focus on the public-private load balancer combo solution.

Configuration

Now, let us test the proposed solution.  For demonstration, the following setup will be used:

In the above setup, the two Apache HTTP servers are configured on different private subnets.  SSL is configured on both of them.  The index page on each Apache has the following:  "This is Private Apache#n SSL running on Oracle Cloud Infrastructure". These two Apache servers comprise the backend set of the private load balancer.

The SSL configuration between the private load balancer and the backend set (comprising of two Apache HTTP servers) is configured as "End To End SSL". There are other types of SSL configuration, however, we will use End To End SSL in this example. Refer to Load Balancing SSL Traffic in OCI for a comprehensive coverage of SSL support in OCI load balancers including End To End SSL. The private load balancer uses a self signed certificate with the Common Name "LB-SSL".

The SSL configuration between the public and the private load balancer is "SSL Tunneling".  Again, it could have been any other type of SSL configuration such as End To End SSL, however, the intent here is to demonstrate how to transport user traffic from the internet to the private load balancer. That is, how to tunnel this traffic!  Although setting up SSL Tunneling between the public and the private load balancer is trivial, and Load Balancing SSL Traffic in OCI gives a detailed description about the configuration, I would like to highlight a key point pertaining to our setup here: the backend set of the public load balancer has just 1 backend, namely the private load balancer.  To configure this, go to the "Add Backends" UI of the public load balancer, select "IP addresses" and fill in the IP address of the private load balancer as shown below.

In the above figure, 10.0.5.4 is the IP address of the private load balancer.  Port is 443 since that is the default SSL port.  You can get the IP address of the private load balancer from the load balancer's main UI as shown below:

Accessing the IP address of the public load balancer results in:

The result is from Apache#1. Reloading the page gives us the following:

This time the response is from Apache#2.  Notice that in both requests, the certificate of the server is "LB-SSL" which is the certificate loaded into the private load balancer. The takeaways from this section are:

• requests to the backend servers are getting load balanced
• End To End SSL between the private load balancer and the backend Apache servers is working
• the public load balancer is tunneling traffic to the private load balancer thus proving that the solution works

Summary

Enterprises are rapidly leveraging OCI as part of their hybrid cloud strategy. This strategy brings new challenges such as accessing resources in private subnets.  In this blog post, we looked into a solution to access such private resources from the internet using a public load balancer.