Oracle Cloud Infrastructure Documentation

Overview of Networking

When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources. This topic gives you an overview of Oracle Cloud Infrastructure Networking components and typical scenarios for using a VCN.

Networking Components

The Networking service uses virtual versions of traditional network components you might already be familiar with:

virtual cloud network (vcn)
A virtual, private network that you set up in Oracle data centers. It closely resembles a traditional network, with firewall rules and specific types of communication gateways that you can choose to use. A VCN covers a single, contiguous IPv4 CIDR block of your choice. See Default Components that Come With Your VCN. The terms virtual cloud network, VCN, and cloud network are used interchangeably in this documentation. For more information, see VCNs and Subnets.
subnets

Subdivisions you define in a VCN (for example, 10.0.0.0/24 and 10.0.1.0/24). Subnets contain virtual network interface cards (VNICs), which attach to instances. Each subnet exists in a single One or more isolated, fault-tolerant Oracle data centers that host cloud resources such as instances, volumes, and subnets. A region contains several availability domains. and consists of a contiguous range of IP addresses that do not overlap with other subnets in the VCN. Subnets act as a unit of configuration within the VCN: All VNICs in a given subnet use the same route table, security lists, and DHCP options (see the definitions that follow). You can designate a subnet as either public or private when you create it. Private means VNICs in the subnet can't have public IP addresses. Public means VNICs in the subnet can have public IP addresses at your discretion. See Access to the Internet.

vnic
A virtual network interface card (VNIC), which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN. The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC), and remove them as you like. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in subnets in the same availability domain as the instance. For more information, see Virtual Network Interface Cards (VNICs).
private ip
A private IP address and related information for addressing an instance (for example, a hostname for DNS). Each VNIC has a primary private IP, and you can add and remove secondary private IPs. The primary private IP address on an instance doesn't change during the instance's lifetime and cannot be removed from the instance. For more information, see Private IP Addresses.
public ip
A public IP address and related information. You can optionally assign a public IP to your instances or other resources that have a private IP. Public IPs can be either ephemeral or reserved. For more information, see Public IP Addresses.
dynamic routing gateway (drg)
An optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and on-premises network. You can use it with other Networking components and a router in your on-premises network to establish a connection by way of IPSec VPN or Oracle Cloud Infrastructure FastConnect. It can also provide a path for private network traffic between your VCN and another VCN in a different region. For more information, see Access to Your On-Premises Network, Dynamic Routing Gateways (DRGs), and Remote VCN Peering (Across Regions).
internet gateway
Another optional virtual router that you can add to your VCN for direct internet access. For more information, see Access to the Internet and also Typical Networking Scenarios.
network address translation (nat) gateway
Another optional virtual router that you can add to your VCN. It gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections. For more information, see Access to the Internet and also NAT Gateway.
service gateway
Another optional virtual router that you can add to your VCN. It provides a path for private network traffic between your VCN and a public Oracle service such as Oracle Cloud Infrastructure Object Storage. For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet. For more information, see Access to Object Storage: Service Gateway.
local peering gateway (LPG)
Another optional virtual router that you can add to your VCN. It lets you peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network. A given VCN must have a separate LPG for each peering it establishes. For more information, see Local VCN Peering (Within Region).
remote peering connection (rpc)
A component that you can add to a DRG. It lets you peer one VCN with another VCN in a different region. For more information, see Remote VCN Peering (Across Regions).
route tables
Virtual route tables for your VCN. They have rules to route traffic from subnets to destinations outside the VCN by way of gateways or specially configured instances. Your VCN comes with an empty default route table, and you can add custom route tables of your own. For more information, see Route Tables.
security lists
Virtual firewall rules for your VCN. Security lists have ingress and egress rules that specify the types of traffic (protocol and port) allowed in and out of the instances. You can choose whether a given rule is stateful or stateless. For example, you can allow incoming SSH traffic from anywhere to a subnet's instances by setting up a stateful ingress rule with source CIDR 0.0.0.0/0, and destination TCP port 22. Your VCN comes with a default security list with default rules, and you can add custom security lists of your own. For more information, see Security Lists.
dhcp options
Configuration information that is automatically provided to the instances when they boot up. For more information, see DHCP Options.

Allowed VCN Size and Address Ranges

A VCN covers a single, contiguous IPv4 CIDR block of your choice. The allowable VCN size range is /16 to /30. Example: 10.0.0.0/16. The Networking service reserves the first two IP addresses and the last one in each subnet's CIDR. After you've created a VCN or subnet, you can't change its size, so it's important to think about the size of VCN and subnets you need before creating them.

For your VCN, Oracle recommends using one of the private IP address ranges specified in RFC 1918 (10.0.0.0/8, 172.16/12, and 192.168/16). However, you can use a publicly routable range. Regardless, this documentation uses the term private IP address when referring to IP addresses in your VCN's CIDR.

The VCN's CIDR must not overlap with your on-premises network or another VCN you peer with. The subnets in a given VCN must not overlap with each other. For reference, here's a CIDR calculator.

Default Components that Come With Your VCN

Your VCN automatically comes with these default components:

You can't delete these default components. However, you can change their contents (for example, the rules in the default security list). And you can create your own custom versions of each kind of component in your VCN. There are limits to how many you can create and the maximum number of rules. For more information, see Service Limits.

Each subnet always has these components associated with it:

  • One route table
  • One or more security lists (for the maximum number, see Service Limits
  • One set of DHCP options

During subnet creation, you can choose which route table, security list, and set of DHCP options the subnet uses. If you don't specify a particular component, the subnet automatically uses the VCN's default component. You can change which components the subnet uses at any time.

Connectivity Choices

You can control whether subnets are public or private, and whether instances get public IP addresses. You can set up your VCN to have access to the internet if you like. You can also privately connect your VCN to public Oracle Cloud Infrastructure services such as Object Storage, to your on-premises network, or to another VCN.

Public vs. Private Subnets

When you create a subnet, by default it's considered public, which means instances in that subnet are allowed to have public IP addresses. Whoever launches the instance chooses whether it will have a public IP address. You can override that behavior when creating the subnet and request that it be private, which means instances launched in the subnet are prohibited from having public IP addresses. Network administrators can therefore ensure that instances in the subnet have no internet access, even if the VCN has a working internet gateway, and security lists and firewall rules allow the traffic.

How IP Addresses Are Assigned

Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC) and remove them as you like.

Every VNIC has a private IP address from the associated subnet's CIDR. You can choose the particular IP address (during instance launch or secondary VNIC creation), or Oracle can choose it for you. The private IP address does not change during the lifetime of the instance and cannot be removed. You can also add secondary private IPs to a VNIC.

If the VNIC is in a public subnet, then each private IP on that VNIC can have a public IP assigned to it at your discretion. Oracle chooses the particular IP address. There are two types of public IPs: ephemeral and reserved. An ephemeral public IP exists only for the lifetime of the private IP it's assigned to. In contrast, a reserved public IP exists as long as you want it to. You maintain a pool of reserved public IPs and allocate them to your instances at your discretion. You can move them from resource to resource in a region as you need to.

Access to the Internet

There are two optional gateways (virtual routers) that you can add to your VCN depending on the type of internet access you need:

  • Internet gateway: For resources with public IP addresses than need to be reached from the internet (example: a web server) or need to initiate connections to the internet.
  • NAT gateway: For resources without public IP addresses that need to initiate connections to the internet (example: for software updates) but need to be protected from inbound connections from the internet.

Just having an internet gateway alone does not expose the instances in the VCN's subnets directly to the internet. The following requirements must also be met:

  • The internet gateway must be enabled (by default, the internet gateway is enabled upon creation).
  • The subnet must be public.
  • The subnet must have a route rule that directs traffic to the internet gateway.

  • The subnet must have security list rules that allow the traffic (and each instance's firewall must allow the traffic).
  • The instance must have a public IP address.

Tip

To access Object Storage (which uses public endpoints) from your VCN without the traffic going over the internet, use a service gateway.

Also, be aware that when an internet gateway receives traffic from your VCN destined for a public IP address that is part of Oracle Cloud Infrastructure (such as Object Storage), the internet gateway routes the traffic to the destination without sending the traffic over the internet.

You can also give a subnet indirect access to the internet by setting up an internet proxy in your on-premises network and then connecting that network to your VCN by way of a DRG. For more information, see Access to Your On-Premises Network.

Access to Public Oracle Cloud Infrastructure Services

You can use a service gateway with your VCN to enable private access to public Oracle Cloud Infrastructure services such as Object Storage. For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet. No internet gateway or NAT is required. For more information, see Access to Object Storage: Service Gateway.

Access to Your On-Premises Network

There are two ways to connect your on-premises network to Oracle Cloud Infrastructure:

  • IPSec VPN: Offers multiple IPSec tunnels between your existing network's edge and your VCN, by way of a DRG that you create and attach to your VCN.
  • Oracle Cloud Infrastructure FastConnect: Offers a private connection between your existing network's edge and Oracle Cloud Infrastructure. Traffic does not traverse the internet. Both private peering and public peering are supported. That means your on-premises hosts can access private IPv4 addresses in your VCN as well as regional public IPv4 addresses in Oracle Cloud Infrastructure (for example, Object Storage or public load balancers in your VCN).

You can use one or both types of the preceding connections. If you use both, you can use them simultaneously, or in a redundant configuration. These connections come to your VCN by way of a single DRG that you create and attach to your VCN. Without that DRG attachment and a route rule for the DRG, traffic does not flow between your VCN and on-premises network. At any time, you can detach the DRG from your VCN but maintain all the remaining components that form the rest of the connection. You could then reattach the DRG again, or attach it to another VCN.

Access to Another VCN

You can connect your VCN to another VCN over a private connection that doesn't require the traffic to traverse the internet. In general, this type of connection is referred to as VCN peering. Each VCN must have specific components to enable peering. The VCNs must also have specific IAM policies, route rules, and security lists that permit the connection to be made and the desired network traffic to flow over the connection. For more information, see Access to Other VCNs: Peering.

Connection to Oracle Cloud Infrastructure Classic

You can ask Oracle to provision a dedicated connection between your Oracle Cloud Infrastructure environment and Oracle Cloud Infrastructure Classic environment. This connection facilitates hybrid deployments between the two environments, or migration from Oracle Cloud Infrastructure Classic to Oracle Cloud Infrastructure. For more information, see Access to Oracle Cloud Infrastructure Classic.

Connection to Other Clouds with Libreswan

You can connect your VCN to another cloud provider by using an IPSec VPN with a Libreswan VM as the customer-premises equipment (CPE). For more information, see Access to Other Clouds with Libreswan.

Typical Networking Scenarios

This section describes several typical scenarios for using a VCN.

Scenario A: Public Subnets

This is the fastest way to try out Networking. The following figure illustrates the scenario. You set up a VCN with:

  • One public subnet per availability domain
  • An internet gateway
  • A corresponding route rule in the default route table
  • The default security list
  • The default set of DHCP options

You then launch one or more compute A bare metal or virtual machine (VM) compute host. The image used to launch the instance determines its operating system and other software. The shape specified during the launch process determines the number of CPUs and memory allocated to the instance.in one of the subnets. In this scenario, each instance gets both a public and private IP address. You can then communicate with the instances via the public IP address over the internet from your on-premises network.

This image shows Scenario A: a VCN with public subnets and an Internet Gateway.

For instructions on using the Console or API to set up a VCN with public subnets, see Scenario A: Public Subnets.

Scenario B: Private Subnets with an IPSec VPN

In this scenario you set up a VCN with:

  • Two private subnets in separate availability domains (to illustrate redundancy)
  • A virtual private network connection (IPSec VPN) to provide private communication with your on-premises network
  • A corresponding route rule in the default route table
  • A modified default security list, with additional rules to allow these additional types of traffic:

    • Stateful ingress rule for traffic from anywhere on TCP port 80 (HTTP)
    • Stateful ingress rule for traffic from anywhere on TCP port 443 (HTTPS)
    • Stateful ingress rule for traffic from anywhere on TCP port 1521 (for Oracle databases)
  • The default set of DHCP options

Tip

For additional security, you could modify all the security list ingress rules to allow traffic only from within your VCN and your on-premises network.

The following figure illustrates the general layout. To use this scenario, you must have a network administrator configure the router at your end of the IPSec VPN. You can then launch an instance in your VCN and communicate with it using its private IP address from your on-premises network.

This image shows Scenario B: a VCN with private subnets and a VPN IPSec connection.

You might use this scenario, for example, if you want to extend your private database servers in your on-premises network into the cloud.

For instructions on using the Console or API to set up a VCN with private subnets and IPSec VPN, see Scenario B: Private Subnets with a VPN.

Scenario C: Public and Private Subnets

In this scenario you set up a VCN with:

  • Both a public subnet and a private subnet in a single availability domain
  • Similar subnets in a second availability domain for redundancy
  • An internet gateway so the instances in the public subnets can communicate with the internet using their public IP addresses
  • An IPSec VPN so the instances in the private subnets can communicate securely with your on-premises network using their private IP addresses
  • Two route tables to direct traffic out of the VCN—one for traffic to the internet and one for traffic to your on-premises network
  • A modified default security list, where you change all the existing stateful ingress rules to allow traffic only from your on-premises network's CIDR block
  • A separate security list just for the public subnets, with these rules:

    • Stateful ingress rule for traffic from anywhere, on TCP ports 80 (HTTP) and 443 (HTTPS)
    • Stateful egress rule for any traffic to the private subnets on TCP port 1521 (for Oracle databases)
  • A separate security list just for the private subnets, with these rules:

    • Stateful ingress rule for any traffic from the public subnets, on TCP port 1521 (for Oracle databases)
    • Stateful ingress rule for any traffic in the private subnets, on TCP port 1521 (for Oracle databases)
    • Stateful egress rule for any traffic in the private subnets on TCP port 1521 (for Oracle databases)
  • The default set of DHCP options

Notice that the public subnet would use both the default security list and the public subnet security list. Likewise, the private subnet would use both the default security list and the private subnet security list. The default security list contains a core set of stateful rules that all subnets in the scenario need to use.

The following figure illustrates the general layout. To use this scenario, you must have a network administrator configure the router at your end of the IPSec VPN.

This image shows Scenario C: a VCN with both public and private subnets, an Internet Gateway, and a VPN IPSec connection.

You might use this scenario to host a cloud-based website that's connected to a database. The web servers reside in the public subnet and are thus reachable from the internet. The database servers reside in the private subnet.

For instructions on using the Console or API to set up a VCN with public and private subnets, see Scenario C: Public and Private Subnets with a VPN.

Regions and Availability Domains

Your VCN resides in a single Oracle Cloud Infrastructure region. Each subnet resides in a single availability domain (AD). Availability domains are designed to provide isolation and redundancy in your VCN, as illustrated in Scenario B and C earlier. For example, you could set up your primary set of subnets in a single AD, and then set up a duplicate set of subnets in a secondary AD. The two ADs are isolated from each other in the Oracle data centers, so if one fails, you can easily switch over to the other AD. For more information, see Regions and Availability Domains.

Public IP Address Ranges for Your VCN

Your VCN's public IP addresses can come from the following CIDR blocks. You should whitelist these on your on-premises network.

Ashburn (IAD) region
Frankfurt (FRA) region
London (LHR) region
Phoenix (PHX) region

IP Addresses Reserved for Use by Oracle

The following IP addresses are reserved for Oracle Cloud Infrastructure use:

169.254.0.0/16
For iSCSI connections to the boot and block volumes, instance metadata, and other services.
three ip addresses in each subnet
The first two IP addresses and the last one in each subnet's CIDR are reserved.

Resource Identifiers

Each Oracle Cloud Infrastructure resource has a unique, Oracle-assigned identifier called an Oracle Cloud ID (OCID). For information about the OCID format and other ways to identify your resources, see Resource Identifiers.

Ways to Access Oracle Cloud Infrastructure

You can access Oracle Cloud Infrastructure using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see Software Development Kits and Command Line Interface.

To access the Console, you must use a supported browser. You can use the Console link at the top of this page to go to the sign-in page. You will be prompted to enter your cloud tenant, your user name, and your password.

For general information about using the API, see REST APIs.

Authentication and Authorization

Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).

An administrator in your organization needs to set up A collection of users who all need a particular type of access to a set of resources or compartment., A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization., and 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. that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.

If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.

Limits on Your Networking Components

See Service Limits for a list of applicable limits and instructions for requesting a limit increase.