Updated 2025-02-12

Transit Routing inside a hub VCN

Transit routing refers to a network topology in which an 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)  the 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:

  • Access between several networks through a single DRG with a firewall between networks: This scenario uses the DRG as the hub, with routing configured to send packets through a firewall in a 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 several VCNs in the same region: The scenario covered in this topic. This scenario uses a VCN as the hub, and creates communication between an on-premises network and several VCNs (connected by using local peering) in the same region over a single FastConnect private virtual circuit or Site-to-Site VPN. We recommend you use the previous scenario instead. This scenario is available to an implementation using a legacy or upgraded DRG.
  • Private access to Oracle services: This scenario uses a VCN as the hub, and gives an on-premises network private access to Oracle services, so that the on-premises hosts can use their private IP addresses and the traffic doesn't go over the internet. See Private Access to Oracle Services. This scenario is available to an implementation using either a legacy or upgraded DRG.

Highlights

  • You can use a single FastConnect or Site-to-Site VPN connection between an on-premises network with several VCNs in the same region, in a hub-and-spoke topology.
  • The VCNs must be in the same region but can be in different tenancies. 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 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 intended traffic from the on-premises network through the hub to a peered spoke VCN, you implement route rules for the hub DRG or the hub VCN's DRG attachment and LPG, and for the spoke VCN's subnets.
  • 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.
  • Configuring route tables that reside in the hub VCN lets you 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.
Tip

Another scenario lets you connect an on-premises network to several VCNs. Instead of using a single DRG and hub-and-spoke topology, you set up a separate DRG for each VCN and a separate private virtual circuit over a single FastConnect. However, the scenario can be used only with FastConnect through a third-party provider or through colocation with Oracle. The VCNs must be in the same region and same tenancy. For more information, see FastConnect with Multiple DRGs and VCNs.

Overview of Transit Routing

Transit routing is the task of routing traffic to either a Virtual Cloud Network (VCN) or an on-premises network through a central hub VCN. 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. An 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 Site-to-Site VPN.

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

This scenario uses a hub-and-spoke topology, as illustrated in the following diagram. The term hub 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 the on-premises network.

One of the VCNs acts as the hub (VCN-H) and connects to the on-premises network by way of FastConnect or an Site-to-Site 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. Each locally peered spoke VCN uses 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.

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, 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.
  • Add a route table to the hub VCN, associate it with the DRG attachment, and add a route rule with a target that sets 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).

  • Add another route table to the hub VCN, associate it with the hub VCN's LPG (for that spoke), and add a route rule that sets the target (the next hop) as the DRG for all traffic destined for the on-premises network (or a specific subnet in that network). :

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 several spokes and therefore several 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, the hub is LPG-H-1. More spokes would involve creation of an LPG-H-2, LPG-H-3, and so on.

Important Transit Routing Restrictions to Understand

This section includes some other important details about routing:

  • Route table for the DRG attachment:

    • A VCN route table associated with a DRG attachment can have only 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 an LPG:

    • A VCN route table that's associated with a DRG attachment can only have rules that target a service gateway, a private IP, or a local peering gateway.
    • 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 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 don't 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 particular VCN, you can't create a rule that lists that VCN's CIDR (or a subsection) 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 only use the hub VCN for transit between the on-premises network and spoke VCNs. Don't 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).
  • The following traffic flow isn't supported:

    unsupported route path
    • Traffic goes through DRG-1 out an attachment to VCN-1.
    • Traffic matches a rule in the attachment's ingress route table to LPG-1, which is peered to LPG-2 in VCN-2.
    • Traffic matches a rule in LPG-2's ingress route table to DRG-2 (attached to VCN-2).

    While it might seem that this should work, it's not supported. The supported way to move traffic as shown between two DRGs in the same region is through a remote peering connection within the region.

About CIDR Overlap

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

However, the Networking service doesn't validate whether the spoke VCNs overlap with each other, or if any of the VCNs overlap with the on-premises network. Ensure that CIDRs for all the subnets that need to communicate with each other don't overlap. Otherwise, traffic is dropped.

A Networking service route table can't 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 (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 (172.16.0.0/12) and spoke VCN (192.168.0.0/16) as the destination, 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're transit routing directly through gateways on the hub VCN:

This image shows the route tables and rules required when setting up the scenario.
Callout 1: Route table associated with Subnet-H
Destination CIDR Route Target
172.16.0.0/12 DRG
192.168.0.0/16 LPG-H-1
Callout 2: Route table associated with Subnet-1
Destination CIDR Route Target
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 3: Route table associated with DRG attachment
Destination CIDR Route Target
192.168.0.0/16 LPG-H-1
Callout 4: Route table associated with LPG-H-1
Destination CIDR Route Target
172.16.0.0/12 DRG

No special route table is associated with LPG-1.

Second, if you're 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.
Callout 1: Route table associated with Subnet-H-Frontend
Destination CIDR Route Target
172.16.0.0/12 DRG
192.168.0.0/16 10.0.4.3
Callout 2: Route table associated with Subnet-H-Backend
Destination CIDR Route Target
192.168.0.0/16 LPG-H-1
172.16.0.0/12 10.0.8.3
Callout 3: Route table associated with Subnet-1
Destination CIDR Route Target
10.0.0.0/16 LPG-1
172.16.0.0/12 LPG-1
Callout 4: Route table associated with DRG attachment
Destination CIDR Route Target
192.168.0.0/16 10.0.4.3
Callout 5: Route table associated with LPG-H-1
Destination CIDR Route Target
172.16.0.0/12 10.0.8.3

No special route table is associated with LPG-1.

Required IAM Policy

To use Oracle Cloud Infrastructure, an administrator must be a member of a group granted security access in a policy  by a tenancy 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 the tenancy administrator what type of access you have and which compartment  your access works 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 create instances. See IAM Policies for Networking.

Setting Up VCN Transit Routing in the Console

This section shows how to use the Console to set up transit routing with a VCN to give your on-premises network access to multiple VCNs in the same region.

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

Changes to the API

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