Updated 2024-11-06

Private Access to Oracle Services

Transit routing refers to a network topology in which your on-premises network uses an intermediary to reach Oracle resources or services or VCNs. The intermediary can be a VCN or a Dynamic Routing Gateway (DRG)  your on-premises network is already attached to. You connect the on-premises network to a DRG with FastConnect or Site-to-Site VPN, and then configure routing so that traffic transits through the intermediary to its destination.

The three primary transit routing scenarios are:

  • Private access to Oracle services: The scenario covered in this topic. This scenario gives your on-premises network private access to Oracle services, so that your on-premises hosts can use their private IP addresses and the traffic does not go over the public internet. Instead, the traffic travels over a FastConnect private virtual circuit or Site-to-Site VPN, transits through a Virtual Cloud Network (VCN), and then through a service gateway  to the Oracle service of interest. This scenario is available to an implementation using either a legacy or upgraded DRG.
  • Access between multiple networks through a single DRG with a firewall between networks: This scenario connects several VCNs to a single DRG, with all routing configured to send packets through a firewall in a hub VCN before they can be sent to another network. See Routing traffic through a central network virtual appliance. This scenario is only available to an implementation using an upgraded DRG.
  • Access to multiple VCNs in the same region: This scenario enables communication between an on-premises network and multiple VCNs in the same region over a single FastConnect private virtual circuit or Site-to-Site VPN and uses a VCN as the hub. See Transit Routing inside a hub VCN. This scenario is available to an implementation using a legacy DRG.

Highlights

  • You can set up a VCN so that your on-premises network has private access to Oracle services in the Oracle Services Network by way of the VCN. The hosts in your on-premises network communicate with their private IP addresses.
  • The VCN uses a dynamic routing gateway (DRG) to communicate with the on-premises network. Access to Oracle services is through a service gateway on the VCN. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the public internet.
  • The service gateway is regional and enables access only to supported Oracle services in the same region as the VCN.
  • The supported Oracle services are Oracle Cloud Infrastructure Object Storage and others in the Oracle Services Network. For a list, see Service Gateway: Supported Cloud Services in Oracle Services Network.
  • The service gateway uses the concept of a service CIDR label, which is a string that represents all the regional public IP address ranges for the service or group of services of interest (for example, OCI PHX Object Storage is the string for Object Storage in US West (Phoenix)). You use that service CIDR label when you configure the service gateway and related route rules to control traffic to the service. You can optionally use it when configuring security rules. If the service's public IP addresses change in the future, you don't have to adjust those rules.
  • To enable the intended traffic from the on-premises network through the VCN to Oracle services, you implement route rules for the VCN's DRG attachment and service gateway.
  • If you want, you can set up transit routing through a private IP in the VCN. For example, you might want to filter or inspect the traffic between the on-premises network and the Oracle service. In that case, you route the traffic to a private IP on an instance in the VCN for inspection, and the resulting traffic continues to its destination. This topic covers both situations: transit routing directly between gateways on the VCN, and transit routing through a private IP.

Overview of the Oracle Services Network

The Oracle Services Network is a conceptual network in Oracle Cloud Infrastructure that is reserved for Oracle services. These services have public IP addresses that you typically reach over the public internet. However, you can access the Oracle Services Network without the traffic going over the public internet. There are different ways, depending on which of your hosts need the access:

  • Hosts in your on-premises network:

    • Private access through a VCN with FastConnect private peering or Site-to-Site VPN: This scenario is covered in this topic. The on-premises hosts use private IP addresses and reach the Oracle Services Network by way of the VCN and the VCN's service gateway.
    • Public access with FastConnect public peering: The on-premises hosts use public IP addresses.
  • Hosts in your VCN:

Overview of On-Premises Network Private Access to Oracle Services

The following diagram illustrates the basic layout for giving your on-premises network private access to Oracle services.

This image shows the basic layout of the networks.

Your on-premises network connects to the VCN by way of a FastConnect private virtual circuit or Site-to-Site VPN. Each of these types of connections terminates on a Dynamic Routing Gateway (DRG) that is attached to the VCN. The VCN also has a service gateway, which gives the VCN access to the Oracle Services Network. The traffic from your on-premises network transits through the VCN, through the service gateway, and to the Oracle service of interest. The responses return through the service gateway and VCN to your on-premises network.

When you set up a service gateway, you enable a service CIDR label, which is a string that represents all the regional public IP address ranges for the service or group of services that you want to access through the service gateway. For example, All PHX Services in Oracle Services Network is the service CIDR label for the Oracle services available in US West (Phoenix) through a service gateway. Oracle uses Border Gateway Protocol (BGP) on the DRG to advertise those regional public IP address ranges to the edge device (also called the customer-premises equipment or CPE) in your on-premises network. For a list of those ranges available through the service gateway, see Public IP Addresses for VCNs and the Oracle Services Network.

Multiple Connection Paths to Oracle Services

You can configure your on-premises network with multiple connection paths to Oracle Cloud Infrastructure and Oracle services for redundancy or other reasons. For example, you could use both FastConnect public peering and FastConnect private peering. If you have multiple paths, your edge device receives route advertisement of the Oracle services public IP address ranges over multiple paths. For important information about configuring your edge device correctly, see Routing Details for Connections to Your On-premises Network.

Multiple VCNs with Private Access to Oracle Services

Your organization might choose to use multiple VCNs, each with a service gateway to give the VCN's resources access to Oracle services. For example, you might have a different VCN for each department in your organization.

If you also want to set up your on-premises network with private access to Oracle services through a VCN with a service gateway, this section describes two different network layouts you could use.

In the first layout, you set up a single DRG, with the VCNs in a hub-and-spoke layout as shown in the next diagram. The VCN that acts as the hub is dedicated to providing the on-premises network with private access to Oracle services. The other VCNs are locally peered with the hub VCN. You configure only the hub VCN according to instructions in Setting Up Private Access to Oracle Services. This hub-and-spoke layout is recommended and described further in Transit Routing inside a hub VCN.

This image shows the on-premises network connected to a single DRG.

In the second layout, there's a separate DRG for each VCN, with a separate FastConnect private virtual circuit or Site-to-Site VPN from your on-premises network to each DRG. You dedicate one DRG and VCN to providing your on-premises network with private access to Oracle services. In the next diagram, it's the VCN in the center. To configure that VCN, follow the instructions in Setting Up Private Access to Oracle Services.

This image shows the on-premises network connected to multiple DRGs.

Notice that in both of these layouts, the on-premises network can reach the Oracle services only through a single VCN's service gateway (the one dedicated for this purpose) and not through the service gateways of the other VCNs. For those other VCNs, only the resources inside those VCNs can reach Oracle services through their VCN's service gateway.

Regardless of which layout you choose, you can write an IAM policy to restrict access to an Object Storage bucket so that only requests that come through a specific VCN's service gateway are allowed for that bucket. With either of these layouts, you might want to write the policy to allow requests from multiple VCNs. To restrict access to specific VCNs, create a network source to specify the allowed VCN, and then write the policy restricting access to only the network source. One network source can specify multiple VCNs or you can create one network source for each VCN. For information on creating networks sources, see Managing Network Sources.

The following example policy assumes you set up one network source for each of your VCNs. The policy lets resources in the example ObjectBackup group write objects to an existing bucket called db-backup that resides in a compartment called ABC. When writing a policy like this one, you can specify one or more network sources. This example shows three.

Allow group ObjectBackup to read buckets in compartment ABC

Allow group ObjectBackup to manage objects in compartment ABC where
   all {target.bucket.name='db-backup', 
        any {request.networkSource.name='<hub_VCN_network_source>', request.networkSource.name='<spoke_1_VCN_network_source>', request.networkSource.name='<spoke_2_VCN_network_source>'},
        any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

For more information, see Setting Up a Service Gateway in the Console in the procedure for setting up a service gateway.

Requests from Oracle Services to Your Clients

The service gateway does not allow incoming connection requests to the VCN or your on-premises network. Any connection requests coming from an Oracle service to your on-premises network must come over a public path such as the internet or FastConnect public peering.

If you use Oracle Analytics Cloud so that it initiates connection requests to clients, and you also want to set up private access to Oracle services for your on-premises network, see this known issue.

Transit Routing Options for Private Access to Oracle Services

Two options exist for routing through the VCN for private access to Oracle services:

  • Transit routing directly through gateways: You route the traffic directly through the VCN, from one gateway to the other.
  • Transit routing through a private IP: You set up an instance in the VCN to filter or inspect the traffic between the on-premises network and Oracle Services Network, and route traffic through a private IP on the instance.

The examples shown in the following sections assume that the VCN contains no workloads that need to access the on-premises network or Oracle Services Network. The VCN is being used only for transit routing of traffic through the VCN.

Important Transit Routing Restrictions to Understand

This section includes some additional important details about routing:

  • Route table for the DRG attachment:

    • A VCN route table that is associated with a DRG attachment can only have rules that target a service gateway, a private IP, or a local peering gateway.
    • A DRG attachment always has a route table associated with it, but you can associate a different route table, edit the table's rules, or delete some or all rules.
  • Route table for a service gateway:
    • A VCN route table that is associated with a service gateway can only have rules that target a DRG or a private IP.
    • A service gateway can exist without a route table associated with it. However, after you associate a route table with a service gateway, there must always be a route table associated with it. But, you can associate a different route table. You can also edit the table's rules, or delete some or all of the rules.
  • Traffic transiting through the VCN:The route tables discussed here are intended only for moving traffic through the VCN between locations in the on-premises network and the Oracle Services Network. If you're using a private IP in the VCN, you configure the route tables so that the private IP is placed in that traffic path going through the VCN.
  • Inbound traffic to the VCN: Even though the preceding statement is true (about traffic through the VCN), inbound traffic to subnets within the VCN is always allowed. You do not need to set up explicit rules for this inbound traffic in the DRG attachment's route table or service gateway's route table. When this kind of inbound traffic reaches the DRG or the service gateway, the traffic is automatically routed to its destination in the VCN by the VCN local routing. Because of VCN local routing, for any route table belonging to a given VCN, you can't create a rule that lists that VCN's CIDR (or a subsection) as the rule's destination.
  • VCN traffic when transit routing through a private IP: The immediately preceding statement about VCN local routing means that you only use the VCN for transit between the on-premises network and spoke VCNs. Do not set up workloads in the VCN itself. More explicitly, if you set up transit routing through a private IP in the VCN, you can't also route the VCN's traffic through that private IP. Referring to the preceding diagram, if you were to change the route rule in the service gateway's route table so that the destination CIDR is 0.0.0.0/0 instead of 172.16.0.0/12, only traffic coming from the Oracle Services Network and destined for addresses outside the VCN's CIDR block would be routed through the private IP. Because of VCN local routing, any traffic destined for addresses within the VCN is automatically routed directly to the destination IP address. The VCN local routing takes precedence over the service gateway's route table (in general, over any of the VCN's route tables).

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

If you're a member of the Administrators group, you already have the required access to set up transit routing. Otherwise, you need access to the Networking service, and you need the ability to launch instances. See IAM Policies for Networking.

Setting Up Private Access to Oracle Services

This section shows how to use the Console to set up transit routing with a VCN to give your on-premises network private access to Oracle services.

Turning Off Transit Routing

To turn off transit routing, remove the rules from:

  • The route table associated with the DRG attachment.
  • The route table associated with service gateway.

A route table can be associated with a resource but have no rules. Without at least one rule, a route table does nothing.

A DRG attachment or service gateway can exist without a route table associated with it. However, after you associate a route table with a DRG attachment or service gateway, there must always be a route table associated with it. But, you can associate a different route table. You can also edit the table's rules, or delete some or all rules.