A-Team Chronicles

Network connectivity patterns for Oracle Cloud HCM and ERP applications on OCI.

Mani Krishnan | September 26, 2021
Text Size 100%:

Some frequent questions that A-team encounters from customers are about connectivity to Oracle SaaS. With the flexibility and options that Oracle Cloud Infrastructure (OCI) brings to customers, there are several alternatives for network connectivity. In this post, I'll address the most common of these alternatives, in the context of Oracle Cloud Applications, aka. Fusion cloud applications, HCM, ERP, SCM, and Sales to be specific. The patterns explained here can generally be applied to other Oracle SaaS applications. 

This post will address the connectivity architecture at a high level. I'll delegate to other Oracle blogs and documentation for detailed instructions for tasks such as setting up VPN Connect or  FastConnect connections. The suitable audience for this post is cloud architects and engineers with a foundational understanding of networking with OCI.

Connectivity patterns

Here are the four alternatives in my view to connect with Oracle Applications Cloud, starting with the most common ones.

  • Connect over public internet from all clients with CDN enabled (The default, most common scenario) 
  • Connect over VPN or FastConnect, with CDN disabled (Typical for VPN and FastConnect customers)
  • Connect over public internet from customer premises, but CDN by-passed for connections originating in OCI (For customers with very high API performance needs)
  • Connect over FastConnect or VPN, with CDN by-passed for connections from customer premises and OCI (Least common)

The CDN for Fusion cloud applications is Akamai, which also provides edge-protection services. 

Let's take a closer look at each pattern.

Pattern #1: Connect over public internet from all clients with CDN enabled

NOTE:  CDN will be automatically bypassed for all traffic originating from OCI in near future.  When in effect, pattern #3 will be default for all customers.  When this is in effect, this blog will be updated to reflect the latest. Meanwhile, continue to reach out to Fusion cloud support for any questions about bypassing CDN. 

This is the connectivity pattern for Fusion SaaS customers who do not choose to customize connectivity. All connections originating from customer premises and the Internet are made over the public internet, through the CDN.  There are a couple of key points to note.

  • All connections to or from Fusion SaaS applications (HTTPS, SFTP) are encrypted with TLS 1.2 or higher cryptographic protocol.
  • All traffic, including API, web services, and browser, all through the CDN, which is Akamai for Fusion SaaS applications. 

A high-level visual of this pattern is shown below.

All Fusion SaaS clients, including the clients inside the customer's OCI tenancy, connect through the CDN.  This pattern works well for most customers. 

Pattern #2: Connect over VPN or FastConnect, with CDN disabled

Many Fusion SaaS customers want to connect over encrypted tunnels, or over dedicated circuits to the application from the customer's premises. OCI VPN connect or OCI FastConnect provides this capability. Before I discuss this pattern, let me provide a quick introduction to OCI VPN Connect and FastConnect. 

VPN connects is IPSec VPN from customer's premises (including customer's other 3rd party cloud provider accounts) to OCI. VPN provides an encrypted tunnel for all connections. However, note that all connections to and from Fusion SaaS are encrypted already. VPN can provide an additional measure of protection, for customers who see the benefit in it. VPN connections typically have a ceiling to the bandwidth, estimated to be around 250 Mbits. OCI VPN Connect is a fully self-service option for customers.  VPN allows customers to extend their on-premises networks into OCI, for seamless connectivity between on-premises services and cloud services over private IP networks.

FastConnect provides a quick way to enable dedicated connections from customer's premises (again, including customer's other 3rd party cloud provider accounts) to OCI. FastConnect is easier enabled through one of Oracle's partners, such as Equinix or Megaport, among others. It is possible to enable direct circuits from customer premises to OCI where a partner is not available, but this is done as a last resort, with consultation from OCI networking support. 

Fastconnect provides two types of peering. Private peering allows customers to extend their on-premises networks into OCI. This enables the customer to connect over private IP addresses. Public peering permits accessing Oracle public IP addresses advertised over FastConnect, which includes Fusion SaaS applications. Customers can choose to enable both private and public peering over the same FastConnect. FastConnect is also mostly self-service configuration, through OCI-console and Partner's console. There are, however, a few last steps that need to be performed by OCI network support before FastConnect becomes active. Consult OCI documentation or OCI networking support for more information.

Here is a visual of this pattern.

To ensure that all connections are only between customer premises and Oracle cloud services, and no 3rd parties are in-between, the CDN is disabled in this pattern. To ensure that connections can only originate from customer premises, the customer configures Location-Based Access control (LBAC) in the Fusion SaaS instances. Any clients outside the customer's premises, such as users on Mobile devices will have to be routed through the customer's premises using technologies such as VPN. If the mobile device's IP addresses can reliably fit into a few trusted-CIDR ranges that can be specified with LBAC, then the mobile clients might be able to connect directly. A solution for this is something within the customer's control, and the customer's network engineers must determine an appropriate design.  Blocking all clients originating from outside customer premises is also a possibility.

NOTE: PaaS services hosted by Oracle Cloud, such as OIC, are located in Oracle Service Network (OSN), even though they are created by customers and administratively located inside a compartment. As a result, these products can not take the same connectivity route as other components such as services deployed on OKE or Compute. 

Pattern #3: Connect over public internet from customer premises, but CDN by-passed for connections originating in OCI (For customers with high API-performance needs)

NOTE: This pattern will soon be default for all Fusion applications cloud customers. Pattern #1 will become obsolete. When this change is in effect, this blog will be updated to reflect the latest. Meanwhile, continue to reach out to Fusion cloud support for any questions about bypassing CDN. 

This is a variation of the first pattern. In pattern #1, clients located within customer's OCI tenancy, such as Oracle Integration Cloud (OIC) or Oracle Kubernetes Engine (and, many other PaaS or IaaS services) connect over the CDN. 

While pattern #1 works for most customers, it might not, for some customers have very high-volume integration needs who look to shave off milliseconds to improve the overall user experience. Those customers can request a by-pass of CDN, for services in their OCI tenancy, by working with Oracle field engineers engaged with customers or by submitting a request to Oracle Fusion SaaS support. Note that at the time of publishing this post, this procedure is approved on a per-customer basis, so the requests are not processed immediately. I'll not dive into details of how this is achieved by Oracle cloud support. The result would that any requests originating from the customer's OCI tenancy to Fusion SaaS API or web services will directly connect to Fusion SaaS, by-passing CDN, thus eliminating an additional network hop. This change will be transparent to customers and no code or configuration changes are required by customers.

Please remember that this might not be a preferred approach for every customer. 

NOTE: PaaS services hosted by Oracle Cloud, such as OIC, are located in Oracle Service Network (OSN). The CDN bypass applies to those services as well, if they are hosted in OCI. All PaaS services are hosted in OCI unless a customer is still using OCI-Classic, in which case their services are on classic infrastructure.  

Pattern #4: Connect over FastConnect or VPN, with CDN by-passed only for connections from customer premises and OCI (Least common)

This is a combination of all 3 patterns discussed thus far. Some changes required in this pattern are not transparent to the customer. Customers will have to maintain a custom configuration on their end and they will be solely responsible for that configuration. We have come across some customers with a heightened perception of security or driven by CISO-mandates that might necessitate such a design. These customers have the expertise to implement and maintain it as a solution. I prescribe careful evaluation of it before proceeding with the pattern. 

In this pattern, the customer connects over FastConnect or VPN Connect from the customer's premises. CDN is not disabled.  SaaS clients originating from customer premises essentially bypass CDN, by configuring a CNAME record in their DNS server. Clients connecting from customers' OCI tenancy are configured to bypass CDN by Fusion SaaS support. Other clients, such as mobile devices continue to connect via the CDN. 

Canonical Name (CNAME) records are a type of DNS records that, in effect, allow specifying aliases to existing domain names. CNAME records will be the basis for the feasibility of this pattern. For Fusion SaaS applications enabled with CDN, typically there are two hostnames, one that points to the CDN's IP address and another for the Fusion SaaS application's IP address. For example, a fusion SaaS instance 'abcd' would be associated with these two hostnames.

abcd.fa.<region-code>.oraclecloud.com - Hostname to CDN's (Akamai) IP address. 
abcd.origin-fa.<region-code>.oraclecloud.com - Hostname to IP of Fusion SaaS instance.

Any attempts to connect with the origin Fusion SaaS hostname will result in an SSL handshake failure because of hostname mismatch. Customers can add a CNAME record in their internal DNS such as the one below.

NAME                                                              TYPE      VALUE
--------------------------------------------------------------------------------------------------------------------------------------
abcd.fa.<region-code>.oraclecloud.com.       CNAME  abcd.origin-fa.<region-code>.oraclecloud.com. 

When in effect for a Fusion SaaS client, the CNAME record causes the client to connect directly to the IP of the Fusion SaaS instance. As stated before, the customer is responsible for this record in their DNS and Oracle support would not have any knowledge of such a record. We do not encourage customers from building direct dependencies on IP addresses behind these hostnames.  


What about Fusion SaaS instances in Gen-1 Infrastructure?

At the time of this post, many customers still have their Fusion SaaS instances hosted in Gen1 infrastructure. Let's address the applicability of these patterns for those customers.

  • Patterns #1 and #3 apply to Gen-1 infrastructure as they are explained above. 
  • The Gen-1 instances are accessible over FastConnect public peering through any OCI data center within a region and realm such as the Commercial OCI North America region.
  • The OCI Service Gateway concept does not apply to Gen-1 instances. As a result, OCI Fastconnect public peering is the only way to connect with Gen-1 instances via OCI. 
  • Pattern #2 and #4 apply to Gen-1 instances, but only for Fastconnect public peering. 
  • It is possible to have direct VPN connections to Gen-1 Fusion SaaS instances, which has been an option for the customers for a while. 

References

Interconnectivity within OCI regions: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectpublicpeeringaddressranges.htm
OCI FastConnect: https://www.oracle.com/cloud/networking/fastconnect/
OCI VPN Connect: https://www.oracle.com/cloud/networking/vpn-connect.html
 

Mani Krishnan


Previous Post

A Unified Approach to Database Security

Chad Russell | 6 min read

Next Post


Using Mac Touch ID for Second Factor Authentication to IDCS

KC Flynn | 6 min read