When you work with Oracle Cloud Infrastructure (OCI), one of your first steps is to set up a virtual cloud network (VCN) for your cloud resources. This post gives you an overview of Oracle Cloud Infrastructure Networking components and typical scenarios for using a VCN.
The Networking service uses virtual versions of traditional network components.
A VCN is 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 use. A VCN resides in a single OCI region and covers a single, contiguous IPv4 CIDR block of your choice.
The allowable VCN size range is /16 to /30 (for 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 create a VCN or subnet, you can’t change its size, so it’s important to think about the size of the VCN and subnets that you need before creating them.
For your VCN, we recommend using one of the private IP address ranges specified in RFC 1918 (10.0.0.0/16, 172.16/16, or 192.168/16). However, you can use a publicly routable range. Regardless, this post uses the term private IP address when referring to IP addresses in your VCN’s CIDR. Address ranges that are disallowed are described in IP Addresses Reserved for Use by Oracle.
The VCN’s CIDR block 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.
Each VCN is divided into subnets. Each subnet can be specific to an availability domain or to a region (recommended). An availability-domain-specific subnet is contained within a single availability domain in a region that has multiple availability domains. A regional subnet spans all three availability domains in a region that has multiple availability domains.
Each subnet has a contiguous range of IP addresses, described in CIDR notation. Subnet IP address ranges can’t overlap.
Figure 1: Subnets Within and Spanning Availability Domains in a Region
Instances are placed in subnets and draw their internal IP address and network configuration from their subnet. These subnets can be designated as either private (instances contain private IP addresses assigned to VNICs) or public (instances contain both private and public IP addresses assigned to VNICs). An instance within OCI connects to the subnet within a VCN using a VNIC, which is a component that enables a compute instance to connect to a VCN. See the next section for more information.
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 the same availability domain as the instance.
Private IP addresses provide a private IPv4 address and related information for addressing an instance (for example, a hostname for DNS). Each VNIC has a primary private IP address, and you can add and remove secondary private IP addresses. The primary private IP address on an instance doesn’t change during the instance’s lifetime and can’t be removed from the instance. A private IP address can have an optional public IP address assigned to it.
Public IP addresses provide a public IPv4 address and related information. You can optionally assign a public IP address to your instances or other resources that have a private IP address. Public IP addresses can be either ephemeral or reserved.
Ephemeral public IP addresses are temporary and exist for the lifetime of the instance.
Reserved public IP addresses are persistent and exist beyond the lifetime of the instances to which they are assigned (they can be unassigned and then reassigned to another instance).
Ephemeral IP addresses can be assigned to primary private IP addresses only (hence, only one per VNIC, compared to a maximum of 32 for reserved IP addresses). Oracle doesn’t charge for public IP addresses, including reserved public IP addresses that are unassociated with an instance. Public IP addresses are Oracle provided; you can’t choose or edit them.
An internet gateway is another optional virtual router that you can add to your VCN for direct internet access. You can have only one internet gateway for a VCN. After creating an internet gateway, you must add a route for the gateway in the VCN’s route table to enable traffic flow.
Figure 2: Internet Gateway
A dynamic routing gateway (DRG) is 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.
After attaching a DRG, you must add a route for the DRG in the VCN’s route table to enable traffic flow. A DRG is a standalone object, so you must attach it to a VCN. A VCN and a DRG have a 1-to-1 relationship.
Figure 3: Dynamic Routing Gateway
Route tables have rules that 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.
Each route table consists of a set of route rules. Each rule specifies a destination CIDR block and a route target (the next hop) for the traffic that matches that CIDR block.
Each subnet uses a single route table that’s specified when the subnet is created but can be edited later. A route table is used only if the destination IP address is not within the VCN’s CIDR block. No route rules are required to enable traffic within the VCN itself. When you add an internet gateway, NAT gateway, service gateway, dynamic routing gateway, or a peering connection, you must update the route table for any subnet that uses these gateways or connections.
A NAT gateway is 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. Hosts can initiate outbound connections to the internet and receive responses, but not receive inbound connections initiated from the internet. NAT gateways can be useful for getting updates and patches.
You can have more than one NAT gateway on a VCN, but a given subnet can route traffic to only one NAT gateway.
Figure 4: NAT Gateway
A service gateway provides a path for private network traffic between your VCN and supported services in the Oracle Services Network (such as Oracle Cloud Infrastructure Object Storage and Autonomous Database). For example, database (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.
Figure 5: Service Gateway
Local VCN peering is the process of connecting two VCNs in the same region so that their resources can communicate using private IP addresses. A local peering gateway (LPG) is a component on a VCN for routing traffic to a locally peered VCN. However, the two VCNs in the peering relationship shouldn’t have overlapping CIDR blocks.
Figure 6: Local Peering
You can add a remote peering connection (RPC) to a DRG. An RPC lets you peer one VCN with another VCN in a different region.
Figure 7: Remote Peering Connection
Security rules are virtual firewall rules for your VCN. Ingress and egress rules 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 set of instances by setting up a stateful ingress rule with source CIDR block 0.0.0.0/0 and destination TCP port 22.
To implement security rules, you can use network security groups or security lists. A network security group consists of a set of security rules that apply only to the resources in that group. Contrast this with a security list, in which the rules apply to all the resources in any subnet that uses the list. Your VCN is created with a default security list with default security rules.
DHCP options are configuration information that is automatically provided to the instances when they boot up.
Before you can launch a compute instance, you need to have a VCN and subnet to launch it into. In this exercise, you access the instance over the internet that you will provision in the private subnet. So, your route table directs traffic to a NAT gateway. The subnet also uses a security list to control traffic in and out of the instance.
Figure 8: VCN Wizard, VCN with Internet Connectivity
Enter the following values:
VCN Name: Enter a name for the VCN. The name is incorporated into the names of all the related resources that are automatically created. Avoid entering confidential information.
Compartment: This field defaults to your current compartment. Select the compartment that you want to create the VCN and related resources in, if it’s not the default.
VCN CIDR Block: Enter a valid CIDR block for the VCN. For example, 10.0.0.0/16.
Public Subnet CIDR Block: Enter a valid CIDR block for the subnet. The value must be within the VCN’s CIDR block. For example, 10.0.0.0/24.
Private Subnet CIDR Block: Enter a valid CIDR block for the subnet. The value must be within the VCN’s CIDR block and not overlap with the public subnet’s CIDR block. For example, 10.0.1.0/24.
Accept the default values for any other fields.
Figure 9: Configuration Page of the Create a VCN with Internet Connectivity Option
Figure 10: VCN Resource Review
The VCN has the following resources and characteristics:
To create an OCI compute instance in the private subnet, follow these steps:
By default, OCI selects the Oracle Linux operating system image. You don’t need to change it for this exercise.
After the instance is created, the instance details page is displayed. Make a note of the private IP address.
To create an OCI compute instance in the public subnet, follow the preceding steps with the following changes:
In step 3, name the instance JumpHost.
In step 10, select the public subnet.
On the instance details page, make a note of the public IP address.
ssh -i <path-of-the-private-ssh-key> opc@<Public-IP-Address>
chmod 400 id_rsa
ssh -i id_rsa opc@<Private-IP-Address>
www.google.comto see if the NAT gateway is set up correctly and is allowing traffic from the private instance to go out.
Figure 11: NAT Gateway Example
You are able to ping an outside address from the private instance because of the route rule in the private subnet. The following screenshot shows the route rules in the route table for the private subnet.
Figure 12: Route Rules in the Route Table for the Private Subnet
This blog post gave you an overview of the Oracle Cloud Infrastructure VCN and its components. It shows how you can create an instance in the private subnet and access the internet through a NAT gateway, and how you can access this private instance from a jump host sitting in the same VCN.
Every use case is different. The only way to know if Oracle Cloud Infrastructure is right for you is to try it. You can select either the Oracle Cloud Free Tier or a 30-day free trial, which includes US$300 in credit to get you started with a range of services, including compute, storage, and networking.