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.
While accessing private end points/APIs of external application, an intermediary on Oracle Cloud Infrastructure would be required along with VPN Connect. Oracle Utilities Cloud services cannot connect to private IP addresses for outbound communication from SaaS, they need a public IP address to connect to, for integration.
• When external applications don't use CA-issued certificates and you plan to use a reverse proxy set up within Oracle Cloud Infrastructure and the external application doesn't expose any APIs to public internet. VPN Connect may be required for the reverse proxy to be able to connect to the external application from Oracle Cloud Infrastructure.
• 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 Reverse Proxy Example
A reverse proxy is a type of proxy server that proxies one or more servers and retrieves resources from those servers on behalf of a client. The client sees it's requests as being serviced by the reverse proxy and is oblivious to the servers that the reverse proxy abstracts. A reverse proxy can be used for exposing private end points/APIs to public internet and also to provide secure communications using signed certificates, if a server/application doesn't use signed certificates.
You can provision a reverse proxy in your data center-demilitarized zone that has access to your corporate/private network and expose specific end points of your application to public internet through the reverse proxy, for integration with Oracle Utilities Cloud services applications on OCI.
In the absence of CA-signed certificates in the external applications that have to be integrated with Oracle Utilities Cloud services applications (more specifically for outbound communication from Oracle Utilities Cloud services applications), you can setup a reverse proxy with CA-signed certificates to proxy for the external application/applications.
A single reverse proxy can be setup to proxy for multiple applications, subject to network setup. The reverse proxy can be setup on either the Oracle Cloud Infrastructure or within your data center's de-militarized network zone, based on applicability. You can use appropriate proxy software that needs VM and other resource subscriptions, setup and configuration as necessary, to have the reverse proxy setup on Oracle Cloud Infrastructure.
When to Use Reverse Proxy
External application's APIs are not exposed to public internet, so a reverse proxy that's setup in the data center of the external application or on Oracle Cloud Infrastructure can expose those end points to Oracle Utilities Cloud services applications.
In case the reverse proxy is setup on Oracle Cloud Infrastructure, then VPN Connect may be needed if the external application's APIs are not exposed to public internet. If the external applications don't use CA-signed certificates. Then a single reverse proxy with CA issued certificates can be set up to proxy one or more external applications.
Here is an example of setting up a Reverse Proxy on OCI:
1. To set up a reverse proxy on OCI, create a VM instance in your VCN.
2. If you're using Linux as the O/S for your VM, set up ingress rules in your VCN to allow SSH to the VM.
3. Download and install a reverse proxy software on the newly provisioned VM on OCI and configure it so it can receive communication from Oracle Utilities Cloud services and route it to the external application through the VPN.
4. Be sure to set up the reverse proxy with a public IP address so Oracle Utilities Cloud Service can send outbound communication to the reverse proxy.
See
Understanding Connection Technologies for more information about the supported channels and additional requirements for integrating with external systems.
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: