Transit Routing: Private Access to Oracle Services

Transit routing refers to a network topology 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 public 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 service gateway  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 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 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 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 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 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: 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 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

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

In this example, you route directly through the two gateways on the VCN: the dynamic routing gateway (DRG)  and the service gateway . See the following diagram.

This image shows the route tables and rules required when setting up the scenario.

The diagram shows two route tables, each associated with a different resource:

  • DRG attachment:

    • The route table belongs to the VCN and is associated with the DRG attachment. Why the attachment and not the DRG itself? Because the DRG is a standalone resource that you can attach to any VCN in the same region and tenancy as the DRG. The attachment itself identifies which VCN.
    • The route table routes the inbound traffic that is from the on-premises network and destined for a supported Oracle service. You configure the rule to send that traffic to the service gateway.
  • Service gateway:

    • This route table belongs to the VCN and is associated with the service gateway.
    • The route table routes response traffic that is from a supported Oracle service and destined for the on-premises network. You configure the rule to send that traffic to the DRG.
Transit routing through a private IP in the VCN

In this example, you set up an instance in the VCN to act as a firewall or intrusion detection system to filter or inspect the traffic between the on-premises network and Oracle Services Network. See the following diagram.

This image shows the route tables and rules required when setting up the scenario with a private IP in the hub VCN.

The instance has two VNICs, each with a private IP. One of the VNICs is in a subnet that faces the on-premises network (referred to here as the frontend subnet). The other VNIC is in a subnet that faces the Oracle Services Network (referred to here as the backend subnet). The frontend VNIC has private IP 10.0.4.3, and the backend VNIC has private IP 10.0.8.3.

The diagram shows four route tables, each associated with a different resource:

  • DRG attachment:

    • The route table belongs to the VCN and is associated with the DRG attachment. Why the attachment and not the DRG itself? Because the DRG is a standalone resource that you can attach to any VCN in the same region and tenancy as the DRG. The attachment itself identifies which VCN.
    • The route table routes the inbound traffic that is from the on-premises network and destined for a supported Oracle service. You configure the rule to send the traffic to the private IP in the frontend subnet.
  • Service gateway:

    • This route table belongs to the VCN and is associated with the service gateway.
    • The route table routes response traffic that is from a supported Oracle service and destined for the on-premises network. You configure the rule to send that traffic to the private IP in the backend subnet.
  • Subnet-frontend:

    • This route table belongs to the VCN and is associated with Subnet-frontend.
    • It includes a rule to enable traffic with the on-premises network.
  • Subnet-backend:

    • This route table belongs to the VCN and is associated with Subnet-backend.
    • It includes a rule to enable traffic with the regional Oracle Services Network.

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 policy  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 compartment  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
Tip

You might already have many of the necessary Networking components and connections in this advanced scenario already set up. So you might be able to skip some of the following tasks. If you already have a network layout with a VCN connected to your on-premises network, and a service gateway for that VCN, then Task 4 is the most important. It enables traffic to be routed between your on-premises network and the Oracle Services Network.
Task 1: Set up the VCN

This image shows task 1: setting up the VCN.

In this task, you set up the VCN. For this example, no subnet is required.

For more information and instructions:

Task 2: Add a service gateway to the VCN

This image shows task 2: adding a service gateway to the VCN.

In this task, you add a service gateway to the VCN and enable the gateway for the regional Oracle Services Network.

Notice that you do not yet create the route table that will be associated with the service gateway. That comes in a later task.

  1. In the Console, view the VCN's details.
  2. Under Resources, click Service Gateways.
  3. Click Create Service Gateway.
  4. Enter the following values:

    • Name: A descriptive name for the service gateway. It doesn't have to be unique. Avoid entering confidential information.
    • Create in compartment: The compartment where you want to create the service gateway, if different from the compartment you're currently working in.
    • Services: All <region> Services in Oracle Services Network.
  5. Click Create Service Gateway.

    The service gateway is then created and displayed on the Service Gateways page in the compartment you chose.

Task 3: Connect the VCN to your on-premises network

This image shows task 3: connecting the VCN to your on-premises network.

In this task, you set up either FastConnect or VPN Connect between your VCN and your on-premises network. As part of this process, you attach a DRG to the VCN and set up routing between the VCN and your on-premises network. Notice that you do not yet create the route table that will be associated with the DRG attachment. That comes in a later task. For more information and instructions:
Important

If you're using VPN Connect with static routing, and you've configured the VCN to give your on-premises network private access to Oracle services, you must configure your edge device with the routes for the Oracle Services Network public IP ranges that are advertised by the DRG over the private path (through the service gateway). For a list of those ranges, see Public IP Addresses for VCNs and the Oracle Services Network
Task 4: Set up ingress routing for the DRG and service gateway

This image shows task 4: setting up ingress routing between the DRG and service gateway.

In this task, you set up the route tables for the DRG attachment and the service gateway.

Prerequisites:

  • You already have a DRG attached to the VCN.
  • You already have a service gateway.
  1. Create a route table for the DRG attachment:

    1. In the Console, view the VCN's details.
    2. Under Resources, click Route Tables to view the VCN's route tables.
    3. Click Create Route Table.
    4. Enter the following:

      • Name: A descriptive name for the route table. Example: DRG Route Table. Avoid entering confidential information.
      • Create in Compartment: Leave as is.
    5. Click + Additional Route Rule, and enter this information for the route rule:

      • Target Type: Service gateway.
      • Destination Service: All <region> Services in Oracle Services Network.
      • Compartment: The compartment where the service gateway is located.
      • Target: The service gateway.
      • Description: An optional description of the rule.
    6. Click Create Route Table.

      The route table is created and displayed in the list.

  2. Associate the route table (called DRG Route Table in this example) with the VCN's DRG attachment:

    1. While still viewing the VCN's details, click Dynamic Routing Gateways to view the attached DRG.
    2. Click the Actions icon (three dots), and then click Associate With Route Table.
    3. Enter the following:

      • Route Table Compartment: Select the compartment of the route table for the DRG attachment.
      • Route Table: Select the route table for the DRG attachment.
    4. Click Associate.

      The route table is associated with the DRG attachment.

  3. Create a route table for the service gateway:

    1. While still viewing the VCN's details, click Route Tables.
    2. Click Create Route Table.
    3. Enter the following:

      • Create in Compartment: Leave as is.
      • Name: A descriptive name for the route table. Example: Service Gateway Route Table. Avoid entering confidential information.
    4. Click + Additional Route Rule, and enter this information for the route rule:

      • Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
      • Destination CIDR Block: The on-premises network's CIDR (172.16.0.0/12 in the earlier example).
      • Description: An optional description of the rule.
    5. Click Create Route Table.

      The route table is created and displayed in the list.

  4. Associate the route table (called Service Gateway Route Table in this example) with the service gateway:

    1. While still viewing the VCN's details, click Service Gateways.
    2. For the service gateway, click the Actions icon (three dots), and then click Associate With Route Table.
    3. Enter the following:

      • Route Table Compartment: Select the compartment of the route table for the service gateway.
      • Route Table: Select the route table for the service gateway.
    4. Click Associate.

      The route table is associated with the service gateway.

For routing through a private IP
Tip

You might already have many of the necessary Networking components and connections in this advanced scenario already set up. So you might be able to skip some of the following tasks. If you already have a network layout with a VCN connected to your on-premises network, and a service gateway for that VCN, then Tasks 4 and 5 are the most important. They enable traffic to be routed between your on-premises network and the spoke VCN.
Task 1: Set up the VCN

This image shows task 1: setting up the VCN.

In this task, you set up the VCN. This example also has two subnets: one for the frontend VNIC on the instance, and one for the backend VNIC on the instance. Oracle recommends using regional private subnets.

For more information and instructions:

Task 2: Add a service gateway to the VCN

This image shows task 2: adding a service gateway to the VCN.

In this task, you add a service gateway to the VCN and enable the gateway for the regional Oracle Services Network.

Notice that you do not yet create the route table that will be associated with the service gateway. That comes in a later task.

  1. In the Console, view the VCN's details.
  2. Under Resources, click Service Gateways.
  3. Click Create Service Gateway.
  4. Enter the following values:

    • Name: A descriptive name for the service gateway. It doesn't have to be unique. Avoid entering confidential information.
    • Create in compartment: The compartment where you want to create the service gateway, if different from the compartment you're currently working in.
    • Services: All <region> Services in Oracle Services Network.
  5. Click Create Service Gateway.

    The service gateway is then created and displayed on the Service Gateways page in the compartment you chose.

Task 3: Connect the VCN to your on-premises network

This image shows task 3: connecting the VCN to your on-premises network.

In this task, you set up either FastConnect or VPN Connect between your hub VCN and your on-premises network. As part of this process, you attach a DRG to the hub VCN and set up routing between the hub VCN and your on-premises network.Notice that you do not yet create the route table that will be associated with the DRG attachment. That comes in a later step.For more information and instructions:
Important

If you're using VPN Connect with static routing, and you've configured the VCN to give your on-premises network private access to Oracle services, you must configure your edge device with the routes for the Oracle Services Network public IP ranges that are advertised by the DRG over the private path (through the service gateway). For a list of those ranges, see Public IP Addresses for VCNs and the Oracle Services Network
Task 4: Set up the private IPs on an instance in the VCN

This image shows task 4: setting up the instance in the VCN.

In this task, you set up the instance to have 2 private IPs. Prerequisites:
  1. If you haven't already, create the instance in the VCN. See Creating an Instance. The primary VNIC is created in the subnet you specify.
  2. Create a secondary VNIC for the other subnet and configure the OS to use it. See Using the Console.
  3. Disable the source/destination check on each of the VNICs. See Overview of VNICs and Physical NICs.
  4. For each VNIC, determine which private IP you want to use as the routing target. If you want to use a secondary private IP instead of the VNIC's primary private IP, assign that secondary private IP and configure the OS to use it. See Using the Console.
  5. For each of the private IPs you created, record the private IP address (for example: 10.0.4.3).
  6. Configure the instance as necessary for the job it will perform (for example, configure the firewall or intrusion detection system on the instance).
Task 5: Set up ingress routing for the DRG and service gateway

This image shows task 5: setting up ingress routing between the DRG and service gateway.

In this task, you set up the route tables for the DRG attachment and service gateway.

Prerequisites:

  • You already have a DRG attached to the VCN.
  • You already have a service gateway.
  • You already have the 2 private IPs to use as the routing targets (see the preceding task).
  1. Create a route table for the DRG attachment:

    1. In the Console, view the VCN's details.
    2. Under Resources, click Route Tables to view the VCN's route tables.
    3. Click Create Route Table.
    4. Enter the following:

      • Name: A descriptive name for the route table. Example: DRG Route Table. Avoid entering confidential information.
      • Create in Compartment: Leave as is.
    5. Click + Additional Route Rule, and enter this information for the route rule:

      • Target Type: Private IP.
      • Destination: Service.
      • Destination Service: All <region> Services in Oracle Services Network
      • Compartment: The compartment where the frontend subnet's private IP is located.
      • Target: The frontend subnet's private IP, which you recorded in the previous task (10.0.4.3 in the example).
      • Description: An optional description of the rule.
    6. Click Create Route Table.

      The route table is created and displayed in the list.

  2. Associate the route table (called DRG Route Table in this example) with the VCN's DRG attachment:

    1. While still viewing the VCN's details, click Dynamic Routing Gateways to view the attached DRG.
    2. Click the Actions icon (three dots), and then click Associate Route Table.
    3. Select the route table.
    4. Click Associate Route Table.

      The route table is associated with the DRG attachment.

  3. Create a route table for the service gateway:

    1. While still viewing the VCN's details, click Route Tables.
    2. Click Create Route Table.
    3. Enter the following:

      • Create in Compartment: Leave as is.
      • Name: A descriptive name for the route table. Example: Service Gateway Route Table. Avoid entering confidential information.
    4. Click + Additional Route Rule, and enter this information for the route rule:

      • Target Type: Private IP.
      • Destination: CIDR Block.
      • Destination CIDR Block: The on-premises network's CIDR (172.16.0.0/12 in the earlier example).
      • Compartment: The compartment where the private IP is located.
      • Target: The backend subnet's private IP, which you recorded in the previous task (10.0.8.3 in the example).
      • Description: An optional description of the rule.
    5. Click Create Route Table.

      The route table is created and displayed in the list.

  4. Associate the route table (called Service Gateway Route Table in this example) with the service gateway:

    1. While still viewing the VCN's details, click Service Gateways.
    2. For the service gateway, click the Actions icon (three dots), and then click Associate With Route Table.
    3. Enter the following:

      • Route Table Compartment: Select the compartment of the route table for the service gateway.
      • Route Table: Select the route table for the service gateway.
    4. Click Associate.

      The route table is associated with the service gateway.

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.