Connect Your On-Premises Corporate Resources with Multiple Virtual Cloud Networks

Vijay Kannan
Principal Product Manager

If you have organized your resources in multiple virtual cloud networks (VCNs) to meet your governance model and regional presence, connecting all those VCNs to your on-premises networks can be a real challenge. Until now, your only option was to have a FastConnect or IPSec connection terminate at each of your VCNs. However, this option means you incur costs for multiple FastConnect links, and you have the operational burden of provisioning a new FastConnect or IPSec connection for each new VCN you add.

We are excited to announce the availability of Oracle Cloud Infrastructure VCN Transit Routing, which now offers an alternative. This solution is based on a hub-and-spoke topology and enables the hub VCN to provide consolidated transit connectivity between an on-premises network and multiple spoke VCNs within the Oracle Cloud Infrastructure region. Only a single FastConnect or IPSec VPN (connected to hub VCN) is required for the on-premises network to communicate with all the spoke VCNs. This solution is based on our existing local VCN peering and dynamic routing gateway (DRG) offerings. 

With this solution, you no longer need to attach a DRG to each of your VCNs to access your on-premises network. You attach only a single DRG to the hub VCN and allow resources in the spoke VCNs to share the (FastConnect or IPSec VPN) connectivity to the on-premises resources. At a high level, you do this by performing the following steps:

  1. Establishing a peering relationship between each spoke VCN and the hub VCN

  2. Associating route tables with the hub VCN's local peering gateways (LPG) and DRG

  3. Setting up rules in those route tables to direct traffic from each LPG on the hub VCN to the DRG, and from the DRG to each LPG.


VCN transit routing offers customers many benefits:

  • Better network design: Simplified network management and fewer connections required to establish traffic flow between multiple VCNs and on-premises networks. The hub VCNs enables shared transit connectivity to remote networks and act as a central point of policy enforcement for all your traffic transiting in and out of the region.

  • Increased service velocity/Faster Time-to-Market: This solution supports Fastconnect and IPSec VPN connectivity requirements between VCNs and remote resources with minimal on-premises network changes.  If you add a new VCN, it will now just take few minutes to set up local peering and routing to the hub VCN. This is a marked improvement to previous lead times of days/weeks waiting on corporate change management procedures for establishing Fastconnect or provisioning IPsec connections at on-premises edge routers.

  • Centralized control of route advertisements:  This solution does not enable the traffic to flow between the on-premises network and the spoke VCNs by default

    • You may want to allow the spoke VCNs to access all or specific corporate network partitions (or subnets) in the customer premises. You control this with the route table associated with the LPG on the hub VCN. You can configure restrictive route rules that specify only the on-premises subnets that you want to make available to the spoke VCN. The routes advertised to the spoke VCN are those in that route table and the hub VCN's CIDR. This control enables isolated connectivity of spoke VCNs' resources to their on-premises counterparts.

    • Similarly, you may want to allow the on-premises network to access all or specific subnets in the spoke VCNs. You control this using the route table associated with the DRG on the hub VCN. You can configure restrictive route rules that specify only the spoke VCN subnets that you want to make available to the on-premises network. The BGP route advertisements to the on-premises network are those in that route table and the hub VCN's CIDR.

  • Cost savings: Significant TCO benefits based on centralized management of the private connectivity (Fast Connect/VPN links) and routing to corporate resources in customer premises.

  • Streamlined operations: This solution enables the service provider model where the hub VCN provides the transit connectivity service to the spoke VCNs. The governance boundaries of these hub VCNs may be different from those of the spoke VCNs and hence may be managed by separate compartments/tenancies. In some cases, the hub and spoke VCNs are in the same company, and the central IT team’s hub VCN provides transit service to spoke VCNs managed by LOBs (Lines of Business). In other cases, the hub and spoke VCNs are in different companies, and one company provides transit service to others.

I hope you enjoyed learning about the VCN Transit Routing feature in Oracle Cloud Infrastructure.

Join the discussion

Comments ( 2 )
  • Sergio Castro Monday, December 17, 2018

    Is there a known limit on the amount of VCN's that transit routing support?
  • Paul Cainkar (Oracle) Thursday, January 2, 2020
    Hi Sergio,

    VCNs reachable via transit routing must be peered to the hub VCN via a local peering gateway connection. The current service limits for Local Peering Gateway (LPG) peerings can be found under networking here:


    If the current limits are not able to address your needs, please open a service limit increase ticket via the console and we will see we can best assist you.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.