Oracle Cloud Infrastructure Documentation

Transit Routing: Private Access to Oracle Services

Transit routing refers to a network setup in which your on-premises network uses a connected virtual cloud network (VCN) to reach Oracle resources or services beyond that VCN. You connect the on-premises network to the VCN with FastConnect or VPN Connect, and then configure the VCN routing so that traffic transits through the VCN to its destination beyond the VCN.

There are two primary transit routing scenarios:

  • 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 internet. Instead, the traffic travels over a FastConnect private virtual circuit or VPN Connect, transits through a virtual cloud network (VCN), and then through a An optional virtual router that you can add to your VCN. The gateway enables on-premises hosts or VCN hosts to privately access Oracle services (such as Object Storage and Autonomous Database) without exposing the resources to the public internet. to the Oracle service of interest.
  • 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 VPN Connect. See Transit Routing: Access to Multiple VCNs in the Same Region.

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 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-phoenix-1). 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 desired 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 internet. However, you can access the Oracle Services Network without the traffic going over the 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 VPN Connect: This is the scenario 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 VPN Connect. 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-phoenix-1 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 Address Ranges for the Oracle Services Network (Service Gateway).

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: Access to Multiple VCNs in the Same Region.

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 VPN Connect 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. The following example 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 VCN OCIDs. 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.vcn.id='<hub_VCN_OCID>', request.vcn.id='<spoke_1_VCN_OCID>', request.vcn.id='<spoke_2_VCN_OCID>'},
        any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}}

For more information, see Task 4: (Optional) Update IAM Policies to Restrict Object Storage Bucket Access 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

There are two options 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.

Transit routing directly through gateways
Transit routing through a private IP in the VCN

Important Transit Routing Restrictions to Understand

This section includes some additional important details about routing:

  • Route table for the DRG attachment:

    • A 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 can exist without a route table associated with it. However, after you associate a route table with a DRG attachment, 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.
  • Route table for a service gateway:
    • A 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 should use the VCN only for transit between the on-premises network and spoke VCNs. You should 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. For example, in 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 given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should 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.

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

For routing directly between gateways
For routing through a private IP

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 of the rules.