Oracle Cloud Infrastructure Documentation

Transit Routing: Access to Multiple VCNs in the Same Region

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:

  • Access to multiple VCNs in the same region: The scenario covered in this topic. This scenario enables communication between your on-premises network and multiple VCNs in the same region over a single FastConnect private virtual circuit or VPN Connect.
  • Private access to Oracle services: 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. See Transit Routing: 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.

Highlights

  • You can use a single FastConnect or IPSec VPN to connect your on-premises network with multiple VCNs in the same region, in a hub-and-spoke layout.
  • The VCNs must be in the same region but can be in different tenancies. For accurate routing, the CIDR blocks of the various subnets of interest in the on-premises network and VCNs must not overlap.
  • The VCN that acts as the hub uses a dynamic routing gateway (DRG) to communicate with the on-premises network. This hub VCN peers with each VCN that is acting as a spoke (referred to as spoke VCNs in this topic). The hub and spoke VCNs use local peering gateways (LPGs) to communicate.
  • To enable the desired traffic from the on-premises network through the hub VCN to a peered spoke VCN, you implement route rules for the hub VCN's DRG attachment and LPG, and for the spoke VCN's subnets.
  • If you like, you can set up transit routing through a private IP in the hub VCN. For example, you might want to filter or inspect the traffic between the on-premises network and a spoke VCN. In that case, you route the traffic to a private IP on an instance in the hub VCN for inspection, and the resulting traffic continues to its destination. This topic covers both situations: transit routing directly between gateways on the hub VCN, and transit routing through a private IP.
  • By configuring route tables that reside in the hub VCN, you can control whether a particular subnet in a peered spoke VCN is advertised to the on-premises network, and whether a particular subnet in the on-premises network is advertised to a peered spoke VCN.

Overview of Transit Routing

A basic networking scenario involves connecting your on-premises network to a VCN with either Oracle Cloud Infrastructure FastConnect or an IPSec VPN. These two basic scenarios illustrate that layout: Scenario B: Private Subnet with a VPN and Scenario C: Public and Private Subnets with a VPN.

There's an advanced networking scenario that lets you use your single FastConnect or IPSec VPN to communication with multiple VCNs from your on-premises network. The VCNs must be in the same region but can be in different tenancies.

Here's a basic example of why you might use transit routing: you have a large organization with different departments, each with their own VCN. Your on-premises network needs access to the different VCNs, but you don't want the administration overhead of maintaining a secure connection from each VCN to the on-premises network. Instead you want to use a single FastConnect or IPSec VPN.

The scenario uses a hub-and-spoke layout, as illustrated in the following diagram. The term hub VCN here means only that a VCN is acting as the hub in this hub-and-spoke design.

This image shows the basic hub and spoke layout of VCNs connected to your on-premises network.

One of the VCNs acts as the hub (VCN-H) and connects to your on-premises network by way of FastConnect or an IPSec VPN. The other VCNs are locally peered with the hub VCN. The traffic between the on-premises network and the peered VCNs transits through the hub VCN. The VCNs must be in the same region but can be in different tenancies.

Gateways Involved in Transit Routing

The next diagram shows the gateways on the VCNs. The hub VCN has a dynamic routing gateway (DRG), which is the communication path with the on-premises network. For each locally peered spoke VCN, there's a pair of local peering gateways (LPGs) that anchor the peering connection. One LPG is on the hub VCN, and the other is on the spoke VCN.

This image shows the basic hub and spoke layout of VCNs along with the gateways required.

Transit Routing Through a Private IP in the Hub VCN

If you want, you can route all the traffic through a private IP on an instance in the hub VCN. For example, you could set up a firewall or intrusion detection system on the instance in the hub VCN to filter or inspect the traffic between the on-premises network and spoke VCNs. Then you would configure the hub VCN's routing so that the transit traffic is routed to a private IP on that instance. You must disable the source/destination check for the private IP's VNIC. The resulting traffic would then travel on to its destination in either the spoke VCN or on-premises network. The following diagram illustrates the idea. Regardless of whether you choose to route through a private IP or not, the same gateways are required. However, you configure the hub VCN's routing a little differently.

This image shows the same diagram but with traffic flowing through an NVA in the hub VCN.

Summary of New Concepts for Experienced Networking Service Users

If you're already familiar with the Networking service and local VCN peering, these are the most important new concepts to understand:

  • For each spoke VCN subnet that needs to communicate with the on-premises network, you must update the subnet's route table with a rule that sets the target (the next hop) as the spoke VCN's LPG for all traffic destined for the on-premises network.
  • You must add a route table to the hub VCN, associate it with the DRG attachment, and add a route rule with a target that depends on your situation:

    • Transit routing directly through gateways: Set the target (the next hop) to the hub VCN's LPG (for that spoke) for all traffic destined for that spoke VCN (or a specific subnet in that VCN).
    • Transit routing through a private IP: Set the target (the next hop) to a private IP on the instance, for all traffic destined for that spoke VCN (or a specific subnet in that VCN). Make sure to disable the source/destination check for the private IP's VNIC.
  • You must add another route table to the hub VCN, associate it with the hub VCN's LPG (for that spoke), and add a route rule with a target that depends on your situation:

    • Transit routing directly through gateways: Set the target (the next hop) as the DRG for all traffic destined for the on-premises network (or a specific subnet in that network).
    • Transit routing through a private IP: Set the target (the next hop) to anotherprivate IP on that instance, for all traffic destined for the on-premises network (or a specific subnet in that network). Again, make sure to disable the source/destination check for the private IP's VNIC. In the example presented here, the private IP is on a secondary VNIC on the instance, in a different subnet. In the subsequent diagrams, the subnets are referred to as the frontend subnet and backend subnet.

For transit routing directly through gateways, see these specific tasks for more information:

For transit routing through a private IP: see these specific tasks for more information:

Example: Components and Routing for a Hub and Single Spoke

The examples in this section show a VCN acting as a hub and only a single spoke VCN for simplicity.

Note

In a hub-and-spoke model, the hub VCN can have multiple spokes and therefore multiple LPGs (one per spoke). This topic uses the phrase the hub VCN's LPG, which could therefore be ambiguous. When the phrase is used here, it means the hub LPG for the particular spoke of interest. In the following diagrams, it's LPG-H-1. Additional spokes would involve creation of an LPG-H-2, LPG-H-3, and so on.

For transit routing directly through gateways
For transit routing through a private IP

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 have only rules that target an LPG or a private IP.
    • 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 an LPG:

    • A route table that is associated with an LPG can have only rules that target a DRG or a private IP.
    • An LPG can exist without a route table associated with it. However, after you associate a route table with an LPG, 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 through the hub VCN:The route tables discussed here are intended only for moving traffic through the hub VCN between locations in the on-premises network and locations in the spoke VCN. If you're using a private IP in the hub, you configure those route tables so that the private IP is placed in that traffic path going through the hub.
  • Inbound traffic to the hub VCN: Even though the preceding statement is true (about traffic through the hub), inbound traffic to subnets within the hub 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 hub LPG's route table. When this kind of inbound traffic reaches the DRG or the hub LPG, the traffic is automatically routed to its destination in the hub 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 sub-section) as the rule's destination.
  • Hub VCN traffic when transit routing through a private IP: The immediately preceding statement about VCN local routing means that you should use the hub VCN only for transit between the on-premises network and spoke VCNs. Do not set up workloads in the hub VCN itself. More explicitly, if you set up transit routing through a private IP in the hub VCN, you can't also route the hub VCN's traffic through that private IP. For example, in the preceding diagram, if you were to change the route rule in the LPG-H-1 route table so that the destination CIDR is 0.0.0.0/0 instead of 172.16.0.0/12, only traffic coming from VCN-1 and destined for addresses outside the hub 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 LPG-H-1 route table (in general, over any of the VCN's route tables).

About CIDR Overlap

In this example, the various networks do not have overlapping CIDR blocks (172.16.0.0/12 versus 10.0.0.0/16 versus 192.168.0.0/16). The Networking service does not allow local VCN peering between two VCNs with overlapping CIDRs. That means each spoke must not overlap with the hub.

However, the Networking service does not validate whether the spoke VCNs themselves overlap with each other, or if any of the VCNs overlap with the on-premises network. You must ensure that CIDRs for all the subnets that need to communicate with each other don't overlap. Otherwise, traffic may be dropped.

A Networking service route table cannot contain two rules with the exact same destination CIDR. However, if two rules in the same route table have overlapping destination CIDRs, the most specific rule in the table is used to route the traffic (that is, the rule with the longest prefix match).

Route Advertisement to the On-Premises Network and Spoke VCNs

From a security standpoint, you can control route advertisement so that only specific subnets in the on-premises network are advertised to the spoke VCNs. Similarly, you can control which subnets in the spoke VCNs are advertised to the on-premises network.

The routes advertised to the on-premises network consist of:

  • The rules listed in the route table associated with the DRG attachment (192.168.0.0/16 in the preceding diagram)
  • The individual subnets in the hub VCN

The routes advertised to the spoke VCN consist of:

  • The individual subnets in the hub VCN
  • The rules listed in the route table associated with the hub VCN's LPG for the spoke (172.16.0.0/12 in the preceding diagram)

Therefore, the administrator of the hub VCN alone can control which routes are advertised to the on-premises network and spoke VCNs.

In the preceding example, the relevant routes use the full CIDR block of the on-premises network and spoke VCN as the destination (172.16.0.0/12 and 192.168.0.0/16, respectively), but they could instead use a subnet of those networks to restrict routing to specific subnets.

Details About Routing for Different Traffic Paths

To further illustrate how routing takes place in the preceding example, let's look more closely at different paths of traffic. Here are the same diagrams again.

First, if you are transit routing directly through gateways on the hub VCN:

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

Second, if you are transit routing through a private IP in the hub VCN:

This image shows the route tables and rules required when setting up the scenario with a network virtual appliance in the hub VCN.

Traffic from the on-premises network to the spoke VCN
Traffic from the spoke VCN to the on-premises network
Traffic from the spoke VCN to a subnet in the hub VCN (routing directly between gateways only)

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 VCN Transit Routing in the Console

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 each LPG on the hub VCN.

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 LPG can exist without a route table associated with it. However, after you associate a route table with a DRG attachment or LPG, 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.

Changes to the API

For information about changes to the Networking service API to support transit routing, see the transit routing release notes.