Understanding Connection Technologies
When integrating between an Oracle Utilities Cloud services application and an application hosted externally, either in your data center or in a third party data center, you can select between three different connectivity technologies, depending on your topology and integration requirements,
Understanding Akamai Networking Usage for Oracle Utilities Cloud Services
Akamai is a content delivery network provider with geographically distributed servers that speed up the delivery of web content by bringing it closer to where users are. It currently handles 15-30% of the world's web traffic. Access to Oracle Utilities Cloud Services through Akamai networking adds a layer of security that thwarts malicious attacks such as Distributed Denial-of-Service (DDoS), at the edge, before they reach infrastructure. All communication coming into Oracle Utilities Cloud Services is automatically directed through Akamai network. The DNS of Oracle Utilities Cloud Services automatically resolve to the respective Akamai network end points through which the communication is routed.
Understanding Oracle VPN Connect
You can use Oracle VPN Connect to connect your corporate/private network to Oracle Cloud Infrastructure (OCI) through public internet. It provides secure communication through a virtual private tunnel via the public internet between the Oracle Utilities Cloud services on OCI and the external application with which it integrates.
Separate VPNs should be setup for each of your data center and each third party data center that you may need to connect to OCI, for integrating external applications. Customers need to setup and configure VPN Connect. VPN Connect is a free service, with no port hour charges. Data transfer cost is covered under networking cloud pricing.
When to Use VPN Connect
You should consider using VPN Connect when the following conditions exist:
• When an external application that needs to be integrated with Oracle Utilities Cloud services is within your corporate private network and you do not plan to expose the APIs to public internet (outbound from Oracle Utilities Cloud services applications) from within your data center or if you application cannot access the public internet (inbound to Oracle Utilities Cloud services) but needs to be integrated with Oracle Utilities Cloud services.
• When you want a secured communication channel over public internet for integrating Oracle Utilities Cloud services with the applications in your data center or third party data center.
Preparing to Use VPN Connect
Before you implement VPN Connect to integrate external applications with Oracle cloud services, do the following:
• Understand the requirements and tasks for setting it up.
• Configure the customer-provided equipment (CPE).
• Plan redundancies that will prevent costly system downtime.
Set Up IPSec VPN Connect:
Setting up an IPSec VPN Connect network between external applications and Oracle SaaS is a multistep process that can be complex unless you understand it thoroughly This topic provides a basic overview of the required steps. For more details, refer to
Setting Up VPN Connect, referenced in
Before Using VPN Connect.
1. Choose the routing type that works best for your implementation. IPSec VPN has two redundant IPSec tunnels and you should configure your customer-provided equipment (CPE) device to use both tunnels. You can select either of two routing types for these tunnels:
BGP dynamic routing, with which the available routes are learned dynamically through BGP.
Static routing, with which, when you set up the IPSec connection to the DRG, you specify to your on-premises network the particular routes that you want the VCN to know about.
Refer to
Routing for the Oracle IPSec VPN, referenced in
Before Using VPN Connect for more details on choosing the routing type.
2. Complete the questionnaire in Setting Up VPN Connect, referenced in
Before Using VPN Connect. These questions require such information as your VCN's CIDR, public IP address of your CPE device, the routing type you plan to use, and other pertinent details.
3. Set up the IPSec VPN components:
• Create your VCN.
• Create a DRG.
• Attach the DRG to your VCN.
• Create a route table and route rule for the DRG.
• Create a security list and required rules.
• Create a subnet in the VCN.
• Create a CPE object and provide your CPE device's public IP address.
• Create an IPSec connection to the CPE object and provide required routing information.
4. Use the CPE Configuration Helper, which will generate the information for your network engineer to use when configuring your CPE device. For more information, see Using the CPE Configuration Helper and also CPE Configuration, referenced in
Before Using VPN Connect.
5. Have your network engineer configure your CPE device.
6. Validate connectivity.
Configure Customer-Provided Equipment
Network engineers require basic information about the inside and outside interfaces of your on-premises device; that is, your customer-provided equipment or CPE. This will allow them to configure these on-premises device at your end of the IPSec VPN so traffic can flow between your on-premises network and VCN.
Note: Oracle has verified specific software for use with VPN Connect; however, listing them here is beyond the scope of this chapter. You can see this list in Verified CPE Devices, referenced in
Before Using VPN Connect.
The network engineer will need to take the following steps:
1. Determine the routing requirements. Oracle uses asymmetric routing across the multiple tunnels that make up the IPSec VPN connection. Even if you configure one tunnel as primary and another as backup, traffic from your VCN to your on-premises network can use any tunnel that is "up" on your device.
Configure the firewalls accordingly. Otherwise, ping tests or application traffic across the connection will not reliably work. If you use BGP dynamic routing with your IPSec VPN, you can configure routing so that Oracle prefers one tunnel over the other.
2. Collect important information about VCN and an IPSec connections multiple IPSec tunnels. This information includes:
• VCN OCID, which is a unique Oracle Cloud Infrastructure identifier that has a UUID at the end
• VCN CIDR
• VCN CIDR subnet mask
• For each IPSec tunnel, the IP address of the Oracle IPSec tunnel endpoint (the VPN headend) and the shared secret
3. Collect basic information about the inside and outside interfaces of your on-premises device (your CPE).
4. Determine whether the Oracle VPN head ends use route-based tunnels or policy-based tunnels (note, too, that using policy-based tunnels comes with some caveats).
5. Observe these IPSec VPN best practices:
• Configure all tunnels for every IPSec connection.
• Have redundant CPEs in your on-premises locations.
• Consider backup aggregate routes.
6. Test and confirm the connection status. After configuring the IPSec connection, test the connection by launching an instance into the VCN and then pinging it from your on-premises network.
Plan Redundancies
Redundancies in your IPSec VPN Connect implementation ensure reliable performance and minimize or eliminate costly downtime and other stresses on the system. When implementing redundancies, the key is to create backup paths built for efficiency, speed and availability.
To plan for redundancy, consider all the components (hardware, facilities, circuits, and power) between your on-premises network and Oracle Cloud Infrastructure. Also consider diversity, to ensure that facilities are not shared between the paths. Redundancy considerations are described here:
To review some useful examples of redundancy planning, see
Redundancy Use Cases in the
Connectivity Redundancy Guide, referenced in
Before Using VPN Connect.
Before Using VPN Connect
The preceding VPN Connect best practices were culled from the Oracle Cloud Infrastructure documentation, which contains more detailed information on this service. Before using VPN Connect, you should review the following:
• For a VPN Connect prerequisite checklist, see Before You Get Started.
• To understand the VPN Connect setup process, see Setting Up VPN Connect.
• For a list of customer-provided equipment (CPE) devices and their configuration, see Verified CPE Devices and CPE Configuration.
• For redundancy planning guidelines, see Planning Redundancy.
Understanding Oracle Cloud Infrastructure FastConnect
Oracle FastConnect allows for a dedicated private line, to be installed by a telecommunications provider between an external data center and Oracle Cloud Infrastructure's (OCI) data center. This provides reliable and secured communication through a separate dedicated private line connecting the Oracle Cloud Infrastructure data center and external data center and provides communication capabilities outside the public internet.
Oracle FastConnect can be used with the data center belonging to Oracle Utilities Cloud services application's customer or with third party data center for integrating external applications. FastConnect capability with a third party data center may involve additional agreements/effort. If FastConnect capability is required, then it needs to be separately licensed and configured by the customer.
When to Use Oracle Cloud Infrastructure FastConnect
Use Oracle Cloud Infrastructure FastConnect whenever a high bandwidth dedicated private line between the data center hosting the external application and the Oracle Utilities Cloud services application is required.
Preparing to Use Oracle Cloud Infrastructure FastConnect
Before you implement Oracle Cloud Infrastructure FastConnect to integrate external applications with Oracle cloud services, do the following:
Review FastConnect Documentation
Oracle provides substantial and comprehensive documentation for implementing and using FastConnect which is beyond the scope of this chapter. Please refer to the links in
Before Using Oracle Cloud Infrastructure FastConnect to locate this content.
Understand FastConnect Requirements
Before getting started with FastConnect, you need to address a set of implementation requirements.
At a minimum, meet these requirements:
• Have an Oracle Cloud Infrastructure account, with at least one user with appropriate Oracle Cloud Infrastructure Identity and Access Management (IAM) permissions.
• Have the proper Oracle Cloud Infrastructure Identity and Access Management (IAM) permissions (for example, a user in the Administrators group).
• Possess network equipment that supports Layer 3 routing using BGP.
• For colocation with Oracle: Ability to connect using single mode fiber in your selected FastConnect location. Also see Hardware and Routing Requirements.
• For connection to an Oracle partner, you need at least one physical network connection with the partner.
• For connection to a third-party provider, you need at least one physical connection with the provider.
• For private peering only, you need a least one existing DRG set up for your VCN.
• For public peering only:, you need the list of public IP address prefixes that you want to use with the connection. Oracle will validate your ownership of each prefix.
You can find additional information on these requirements in the Hardware and Routing Requirements documentation, referenced in
Before Using Oracle Cloud Infrastructure FastConnect.
Review FastConnect Design Options
There are three FastConnect options to choose from: Oracle Provider, Third-Party Provider, and Colocation. This topic will help you to choose the best option for your implementation, based on consideration important points in the design.
You need to consider three main points when planning a FastConnect deployment:
• First, determine the Oracle location to which you want to connect.
Oracle has various locations around the globe, called Regions, where Oracle Cloud Infrastructure is deployed. Each region has one or two physical entry locations called FastConnect Data Centers (DC). The FastConnect DC is the entry point into the OCI region and is equiped with redundant hardware. The FastConnect DC is where the customer will establish connectivity to. You can find a complete list of FastConnect-enabled regions at Oracle's North America Network Provider and Exchange Partners website, referenced in
Before Using Oracle Cloud Infrastructure FastConnect.
• Next, identify the services to which you want to connect via FastConnect (also known as a virtual circuit).
FastConnect refers to the physical connection between on-prem and Oracle Cloud Infrastructure (OCI). Within FastConnect you will create a virtual circuit to connect to services within OCI. There are two types of virtual circuits (VC):
• Private peering, which is a virtual circuit when you want to connect on-prem to your Virtual Cloud Network (VCN) within OCI.
• Public peering, which is a virtual circuit you can use to connect your on-premises system to Oracle Services Network (OSN) and access public services without using the Internet.
• Finally, determine what kind of FastConnect to use:
Which of the three FastConnect options best meets your needs? To answer that question, you need to consider some different aspects of your design:
• Where is the customer's data center located?
• How many data centers the customer wants to connect to OCI
• What relation does the customer have with providers or carriers?
• Where can the provider deliver circuits or cross connects to
• How fast does the customer want FastConnect deployed? Cost Latency Bandwidth
These are key points to consider in the design and choosing the proper FastConnect option. For example, if the customer has a good relation with Provider A but Provider A is not an Oracle Provider, then the next option is to use Third-Party provider or Colocation option. If Provider A can deploy circuits to the FastConnect DC but can't deploy cross connect at the FastConnect DC then customer will have to look at a different provider. If the customer is not at the same address as the FastConnect DC then Colocation is not an option.
This is just a brief outline of how to address the design options for implementing OCI FastConnect. For a more detailed discussion of these design options, see the blog post FastConnect Design, referenced in
Before Using Oracle Cloud Infrastructure FastConnect.
Plan Redundancies
Redundancies in your FastConnect implementation ensure reliable performance and minimize or eliminate costly downtime and other stresses on the system. When implementing redundancies, the key is to create backup paths built for efficiency, speed and availability.
While which redundancy best practices you should follow depend on which connectivity model you use, you should always design your network to achieve high availability (HA) and so that it's prepared for these types of disruptions:
• Regularly scheduled maintenance by your organization, your provider (if you're using one), or Oracle.
• Unexpected failures on the part of your networking components, your provider, or Oracle. Failures are rare, but you should plan for them.
For help ensure redundancy, Oracle provides:
• Multiple providers for each region
• Two FastConnect locations for each of the following regions (all other regions have a single FastConnect location)
• Germany Central (Frankfurt)
• UK South (London)
• US East (Ashburn)
• US West (Phoenix)
• Two routers in each FastConnect location
• Multiple physical connections between each Oracle partner and Oracle (for a given region)
You can find a more comprehensive discussion of best practices specific to a FastConnect connectivity model in FastConnect Redundancy Best Practices, referenced in
Before Using Oracle Cloud Infrastructure FastConnect.
Before Using Oracle Cloud Infrastructure FastConnect
The preceding Oracle Cloud Infrastructure FastConnect best practices were culled from the OCI documentation, which contains more detailed information on this service. Before using FastConnect, you should review the following documentation:
• For comprehensive FastConnect documentation, see
FastConnect.
Understanding Private Endpoints
Many Oracle customer cloud networks are designed to prevent outbound connections to the internet. Typical on-premises deployed services are hosted on the enterprise intranet and don’t require public internet access. Migrating these services to the cloud by using the public connectivity model requires customers to enable internet access for their backend clients and punch holes in their firewalls and other security controls. Private connectivity using a service gateway offers a private and secure alternative. Although service gateways enable private access to Oracle services from customer OCI and on-premises networks, this access is over a publicly accessible IP.
Private endpoints allow customers to access Oracle services over a private IP taken from a subnet within their VCN. This capability allows a customer experience where the service is hosted in their own private network, either in their own VCN or on their on-premises site. When allowed, private endpoints support reverse connections to allow Oracle services to initiate connections to instances within the customer’s VCN or on-premises data sources.
The following architectural diagram depicts how customer-to-service (C2S) or forward direction and service-to-customer (S2C) or reverse direction traffic flows through the private endpoint. Within the customer VCN, the private endpoint is a logical representation of the service’s fully qualified domain name (FQDN) or IP address. Customers access the service using a dynamically allocated free private IP address from their chosen subnet as a target. Private endpoints physically reside outside the customer VCN and are managed on-behalf of the customer by the service provider.
Accessing SaaS Applications Using the Service Gateway
A service gateway lets resources in your VCN privately access specific Oracle services, without exposing the data to the public internet. The resources in the VCN can be in a private subnet and use only private IP addresses. The traffic from the VCN to the service of interest travels over the Oracle network fabric and never traverses the internet. Private endpoint is another way to have private access to oracle cloud services. This document is focusing on Service Gateway only.
By default, all incoming network traffic (Web/SOAP/REST) using Public Internet to Oracle Utilities SaaS applications MUST go through Akamai network. Any direct attempt to access Oracle Utilities SaaS applications bypassing Akamai is blocked.
The only exception to bypass Akamai network is to access Oracle Utilities SaaS applications via Service Gateway using Private Subnet in OCI VCN. This connectivity is routed privately and does not go through Akamai network. This exception is handled via Inbound Allowlist internally managed by Oracle.
Required Customer Actions
1. Create a Request for Inbound Allow List Cloud Operations service request via My Oracle Support and provide the following:
• VCN OCID that will access the application through Service Gateway.
• IP address ranges defined as CIDR blocks.
• Both IP and VCN OCID.
2. After confirmation that the service request has been completed, perform the following:
• For customers using OCI DNS resolver with the OCI VCN:
• Create a Private View for the utilities-cloud.oracleindustry.com Zone.
• Add Service Gateway to the OCI VCN.
• Add a Route Rule in the private subnet's Route Table that directs Oracle Services traffic through Service Gateway.
• For customers using Service Gateway with on-premises DNS resolver:
• Override the resolution of Application Hostname to resolve to the Home DNS of the region from the DNS resolver used in their network.
• Add Service Gateway to the VCN.
• Add a Route Rule in the private subnet's Route Table that directs Oracle Services traffic through Service Gateway.
Understanding the Differences Between VPN Connect and OCI FastConnect
If you don't need to use a reverse proxy to implement integration between Oracle Utilities Cloud services application and an application hosted externally but still aren't sure whether to use IPSec VPN Connect or OCI FastConnect, understanding the differences betweent the two will help you make the correct determination.
An IPSec VPN establishes an encrypted network connection over the internet between the external application's data center and your Oracle Cloud Infrastructure virtual cloud network (VCN). It provides low or modest bandwidth and has the inherent variability in internet-based connections.
FastConnect bypasses the internet. Instead, it uses dedicated, private network connections between the external application's network or data center and your VCN.
Further comparisons are here: