Best Practices from Oracle Development's A‑Team

Deploying a Public Load Balancer for an Oracle Analytics Vanity URL

Validated February 26, 2021 with OAC 5.9


A public load balancer provides access to a private Oracle Analytics instances from outside the Oracle cloud infrastructure when a virtual private network and or FastConnect is not available. It acts as a proxy between users and the instances.

Oracle Analytics versions 5.9 and higher provide for an optional custom or vanity fully qualified domain name. This feature allows the use of an HTTPs listener in a load balancer equipped with a vanity FQDN certificate signed by a trusted certificate authority.

This post is a step-by-step guide for connecting to private Oracle Analytics instances with vanity URLs using a public load balancer and an HTTPs listener. It is a companion of this post that describes using a load balancer with a TCP listener for native URLs and is one of the posts listed in the OAC Private Endpoint Series


February 26, 2021 with OAC 5.9


Before You Begin

Deploying Additional Components

Deploying the Public Load Balancer

Connecting to OAC using the Vanity URL

Connection Flows


 Before You Begin and Assumptions  


OAC Oracle Analytics Cloud
CA Certificate Authority
OCI Oracle Cloud Infrastructure
TLS Transport Layer Security
FQDN Fully Qualified Domain Name
SSL Secure Socket Layer
OSN Oracle Services Network
DNS Domain Name System
CNAME Canonical Name
URL Uniform Resource Locator
LB Load Balancer



A user account in an OCI tenancy for managing networking components.
A user account in an instance of OAC.


A private OAC instance version 5.9 or later using a vanity URL. Have the OAC private IP address ready for subsequent use.

TLS Trusted Certificate

You must have: 
   The vanity FQDN X.509 TLS certificate and its private key.
   The root CA certificate from the CA that signed your certificate.

Initial State

The initial state has:

An OAC instance with a private endpoint and a vanity URL, FQDN TLS certificate and certificate private key
An administrator who has the vanity URL, FQDN TLS certificate, certificate private key and the CA root certificate

Throughout this post references are made to vanity names. Here are the uses with example values:
  vanity prefix:    my-prv-analytics
  vanity domain: myorg.com
  vanity FQDN:   my-prv-analytics.myorg.com
  vanity URL:      https://my-prv-analytics.myorg.com/ui


 Deploying Additional Components 

These additional components must exist before deploying a load balancer with an HTTPs listener

SUBNET Hosts the public load balancer Link
ACCESS RULES Facilitates network traffic between the LB, OAC and remote users Link
INTERNET GATEWAY Facilitates network traffic between the LB and remote users Link
ROUTE RULES Facilitates network traffic between the LB and remote users Link
PUBLIC IP The reserved public address of the LB Link
DNS Resolves the vanity FQDN See section below


The following tables show components both needed and previously deployed (greyed out).

Virtual Cloud Network

Use the OAC VCN




Create or use an existing regional public subnet in the OAC VCN to host the LB. This post uses a subnet named PubLB-SN in its examples.



Internet Gateway

Create or use an existing Internet Gateway in the OAC VCN.



Access Control

Define egress and ingress rules in new or existing security lists for network traffic between Clients, OAC, and the LB. Ensure to attach each security list to the appropriate subnet.

VCN1-PubLB-SL INGRESS nnn.nnn.0.0/16 TCP 443 VCN1-PubLB-SN Ingress from External Clients
VCN1-PubLB-SL EGRESS TCP 443 VCN1-PubLB-SN Egress from LB to OAC SN
VCN1-OAC-SL INGRESS TCP 443 VCN1-OAC-SN Ingress from the LB SN


Route Rules

Define a route rule in a new or existing route table for network traffic returning to remote clients. Ensure to attach the route table to the LB subnet.

VCN1-PubLB-RT VCN1 nnn.nnn.0.0/16 Internet Gateway VCN1-PubLB-SN To Remote Clients


Reserved Private IP

Create a reserved public IP address for the LB.

Public OCI Load Balancer nnn.nnn.104.135


Public DNS Zone

Public DNS Zones contain records available via the internet. A method is required by remote clients to resolve the vanity FQDN to the LB's reserved IP address. Many methods are available to choose from. This is a method using the OCI DNS system. The documentation for OCI DNS is here

vanity FQDN 300 A nnn.nnn.104.135
vanity domain 300 SOA ns1.p97.dns.oracloud.net. hostmaster ...


Steps to create the public zone:

In the OCI Console, navigate to Networking > DNS Management > Zones.

Click on Public Zones and then Click on Create Zone

Enter the vanity domain as the Zone Name
Change the Create in Compartment if necessary and accept the default Primary for Zone Type
Click Create

Obtain the public zone nameserver hostname

Click on the new Zone Name.
Under Resources click Records.
Make a note of the first hostname shown in the RDATA column of the record with type SOA e.g. nsx.p97.dns.oracloud.net

Obtain the public zone nameserver IP address

On your client open a terminal or CMD session 
Issue nslookup <public zone nameserver hostname> 
e.g. nslookup nsx.p97.dns.oracloud.net
Make a note of the IP address returned e.g. 162.nn.n.n

Add a public DNS zone record

Create an "A" record to resolve the vanity FQDN to the LB public IP address.

Click on the new Zone Name.
Under Resources click Records
Click Add Record
    Select the A - IPv4 Address Record Type from the dropdown.
    Add the vanity prefix of the vanity FQDN as the Name.
    Click the Lock icon at the right of the Time to Live (TTL) line
      Enter a TTL e.g. 300
    Enter the LB reserved IP address i.e. nnn.nnn.104.135 as the Address and click Submit

Publish the changes

Click Publish Changes, review and click Publish Changes again to confirm

Client DNS Configuration

Update your client DNS settings to resolve the vanity FQDN using the OCI public zone nameserver.

This post describes a method that can be used on a Mac. Many other methods are available for Linux and Windows,

Create a file on the Mac with the same name as your vanity domain and validate the vanity FQDN DNS resolution

Add a line as shown below using the IP address of the DNS nameserver noted in the public zone.


You should see something like:

Now any time your browser uses a FQDN ending in that domain the query is passed to the OCI nameserver.

/etc/resolver/<vanity domain> nameserver 162.nn.n.n


Pre-Deployment State

The pre-deployment state has:

An internet gateway for return traffic to users
A public regional subnet for the LB with:
      An ingress rule allowing client traffic
      An egress rule allowing OAC traffic
      A rule routing client traffic to the internet gateway
An ingress rule in the OAC subnet allowing LB traffic
A reserved public IP address for the LB
A public DNS zone containing a record resolving the vanity FQDN to the reserved public IP address
A client DNS method for routing vanity DNS queries to a public nameserver in the public zone


 Deploying the Public Load Balancer 

Navigate to Load Balancers

In the OCI Console navigate to Network > Load Balancers
Select the appropriate Compartment

Create the Load Balancer

Refer here for load balancer documentation. Click Create Load Balancer.

Complete the Details Dialog

Enter a Name
Click Public for Choose Visibility Type
Click Reserved IP Address for Assign a Public IP Address
Click Select Existing Reserved IP Address
Change your Compartment if necessary and choose your Reserved IP Address from the dropdown
If you have already used your allotted flexible load balancers, Check Dynamic Shapes 
     Click a Total Bandwidth or accept the default
Change your Compartment if necessary and select the OAC VCN
Change your Compartment if necessary and select the Public Load Balancer Subnet
Click Next

Accept the Backends Defaults

Click Next and to accept the defaults. This backend set is not used.

Complete the Listener Dialog

Enter a Listener Name or accept the default
Click HTTP for Type of Traffic (this is changed later)
Click Submit

Configure the Load Balancer

Wait until the LB is in an Active state  then configure the following Resources.


Click Logs to enable logging
   For each Category
      Click the Enable Log button
         Click Enable Log

Backend Sets

           A backend set is a list of backend servers, a load balancing policy, and a health check policy. In this scenario it contains an OAC instance.

Click Backend Sets to create a backend set
   Click Create Backend Set
      Enter the vanity prefix as the Name e.g. <vanity-prefix>
      Leave Use SSL unchecked (for now)
      In the Health Check dialog
          Select TCP as the Protocol
          Enter the OAC port as the Port e.g. 443
      Accept all other defaults
      Click Create Backend Set


           A backend is an instance receiving traffic from the listener via a backend set.

Click on the new Backend Set
   Click Backends 
      Click Add Backends
         Check IP Addresses
             Enter the OAC private IP address into the IP address i.e.
             Change the Port to 443
         Click Add

Return to the load balancer details screen


A hostname can correspond to a backend set that routes traffic to a specific OAC instance.

Click Hostnames to create a hostname
   Click Create Hostname
      Enter the vanity FQDN as the Name i.e. vanity FQDN
      Enter it again as the Hostname
      Click Create

Path Route Sets

Path route rules route traffic to a backend set based on hostname criteria.

Click Path Route Sets to create a path route set
   Click Create Path Route Set
      Enter the vanity domain as the Name
      Select Prefix Match from the Match Style dropdown
      Enter the vanity prefix as the URL String
      Select the vanity backend set from the Backend Set Name dropdown.

Click Create 


A listener is an entity that checks for incoming traffic on the load balancer's IP address. Update the listener to use your hostname, backend set and TLS certificates.

Click Listeners
   Edit the listener by clickingand then Edit
      Select the Hostname from the Hostnames dropdown
      Change the Port to 443
      Click Add a Certificate
         Enter the vanity prefix as the Certificate Name
         Click or accept Choose SSL Certificate File
            Drop or Select your vanity trusted certificate
         Check Specify CA Certificate
            Click or accept Choose SSL Certificate File
               Drop or select your root CA certificate
         Check Specify Private Key
            Click Choose Private Key File
               Drop or select your vanity trusted certificate private key
               Enter the Private Key's Passphrase if there is one
         Click Add Certificate
     Check the Use SSL box
     Select the vanity backend set from the Backend Set dropdown
     Select the vanity path route set from the Path Route Set dropdown
     Click Update Listener

Backend Sets Part II

          Delete the original backend set and update your backend set to use SSL and the certificates uploaded to the listener.

Click Backend Sets
   Click the original backend set and then Delete and Delete again to confirm
   Click your backend set and then Edit
      Click Use SSL
      Click Update Backend Set

Test Network Connectivity to the Load Balancer

Validate that the LB port is accessible.


Test Connectivity through the Load Balancer to OAC

If you have cURL installed, you can test connectivity through to OAC. If your key has no passphrase remove the --pass parameter.


The expected result is a 302 which means it is redirecting to IDCS. If you look at the location response it has IDCS in it.

< location: https://idcs-xyz.identity.oraclecloud.com/oauth2/v1/authorize

<head><title>302 Found</title></head>

Deployed State

The deployed state has:

A public load balancer with:
  an HTTPs listener directing traffic to OAC
  the vanity FQDN certificate, private key, and trusted CA certificate

 Connecting to OAC using the Vanity URL 

Connect to OAC with your browser using the vanity URL.

 Connection Flows 

The connection flow shows:

  1. A browser using the client DNS configuration to query the OCI public DNS nameserver and resolve the vanity FQDN
  2. A connection request passing through the load balancer to OAC
  3. OAC accepting the request and starting a session negotiation via the load balancer



This post described connecting to private Oracle Analytics instances with vanity URLs using a public load balancer and an HTTPs listener.

For other A-Team posts visit A-Team Data Integration and Analytics 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha