Networking & Connectivity always play an important role in any enterprise architecture and cloud is no different. It is an important aspect of your deployment on Oracle Cloud Infrastructure and is one of the first things you configure in your tenancy on OCI. There are a lot of similarities between cloud networking and the on-prem specifics that you are used to. In this post we will look at the key concepts of OCI Networking and will give you a view into how you should get started with your networking in Oracle Cloud Infrastructure. The main idea here is to give you an idea of the basic components and configuration elements of OCI Networking.
Virtual Cloud Network (VCN)
The way we will look at networking is by starting with a blank canvas, which is your tenancy in OCI. The first thing that you would configure is a Virtual Cloud Network (VCN). By definition “A VCN is a virtual, private network that you set up in Oracle Cloud Infrastructure”. Your compute instances, databases and other resources created in OCI are connected to a VCN. It is a regional construct and therefore resides in a single Oracle Cloud Infrastructure region.
A VCN covers a single, contiguous IPv4 CIDR block, which should not overlap with a customer’s on-prem network. A VCN comprises subnets, security controls and communication gateways that can be used to provide connectivity to specific destinations according to the intended use.
A VCN can be created from the OCI console in one of 2 ways:
- Create VCN
- Create VCN wizard
The Create option is simple and allows you to create the VCN and associate the chosen CIDR block to it. You can configure the remaining items such as subnets, gateways etc. as and when needed.
The Create VCN Wizard on the other hand provides you with an easy way to configure your VCN, create the initial subnets and configure the required connectivity according to your needs. The wizard provides you with the option to configure the Cloud Network with connectivity to the Internet or Internet Connectivity & VPN Connectivity to your on-prem network. The wizard will ask you questions related the subnets to create, on-prem CIDR, CPE information etc. based on the chosen mode of connectivity. You can always add connectivity methods once the VCN is ready.
Subnets
We started with a blank canvas and created a VCN associated with an IPv4 CIDR block. The next thing that comes up in the configuration of a VCN is a Subnet. The CIDR block is sub-divided into smaller IP Blocks and used for segmentation according to application tier, purpose or workload type. Each subnet has a route-table, security lists and DHCP options associated with it.
Subnets can be associated to a single Availability Domain or exist at a regional level (across an entire region – spanning all ADs). It is recommended to use regional subnets as they allow instances to share the same subnet and still exist in different ADs.
Each Subnet is associated with a route table, security list and DHCP options. The route-table can be subnet-specific or the default VCN route-table of the VCN. In case of Security Lists, up to 5 SLs can be associated with a Subnet. DHCP options let you control certain functions such as DNS Type and Search domain.
Public vs. Private Subnets
A subnet in OCI can be designated as public or private. This depends on how the resources in the subnet need to be accessed – accessible directly from the Internet or kept private and inaccessible to the public domain. Depending on the type of subnet, specific OCI gateways need to be configured in order to provide the network “stitching” to allow access:
- To / From On-prem
- To / From Internet
- To Internet
- To Native OCI Services
VNICs in the private subnet cannot have public IP Addresses, whereas instances in a public subnet can have non-RFC 1918 (Public) IP Address assigned to their VNICs.
VNIC (Virtual Network Interface Card)
A VNIC is the attachment point of an instance to a Subnet in a particular VCN. The VNICs are responsible for connecting the instance and determining how communication happens between the instance and other systems internal / external to the virtual cloud network. The VNIC has a primary IP Address assigned to it from the subnet that it is part of.
Communication Scenarios and Gateways
This is where we start looking at the various traffic scenarios to / from your VCN. I thought for a bit, should I talk about route tables first or the gateways. I decided to discuss the scenarios and the gateways first, to shed light on how we use the gateways as route targets in route rules (details in the next section). But remember Communication Gateways are responsible to forward traffic to destinations like the internet, on-prem networks, other VCNs and Oracle Services and you need the route tables associated with rules to forward traffic from the subnets through the gateways to the intended CIDRs and destinations.
Access to the Internet
One of the most common access scenarios from your VCN would be to allow internet access for your resources. However, the access requirements could differ from one resource / subnet to another. You might want to expose certain resources, such as web servers to the internet, while keeping others private. The private resources might still need internet access for multiple purposes.
In order to enable internet access to / from your VCN, OCI provides the Internet & NAT Gateways, which cater to each use case. In either case, the route table for the subnet must have a default route configured with either of the gateways as the route target.
Internet Gateway
You can create an Internet Gateway and associate with your VCN to provide access to / from the internet. This is applicable to a Public Subnet and resources having public IP Addresses.
NAT Gateway
The NAT Gateway provides a private subnet with access to the internet. The difference between the Internet Gateway and NAT Gateway is that the latter only provides outbound access to the resources in the subnet, without exposing them to the internet.
Access to On-prem Networks
Once you start your implementation on OCI, either migration or creating a DR or Extended environment for your on-prem data center, the next communication flow that will be needed is the connection to your DC, HQ or Branch locations. Depending on the bandwidth and other connectivity requirements, customer would choose to connect to their on-prem networks either via a dedicated connection (FastConnect) or an IPSEC VPN (VPN Connect).
Dynamic Routing Gateway
OCI Dynamic Routing Gateway (DRG) provides the connectivity to your on-prem networks. Looking at it from a holistic perspective, a DRG is a virtual routing construct that provides connectivity from your VCN to networks outside your region – On-prem & VCNs in other OCI Regions.
Access Networks in Other VCNs (VCN Peering)
There are a few of scenarios where you might have instances in multiple Virtual Cloud Networks and these VCNs can be in the same or different OCI Region. VCN peering is the process of connecting the VCNs in order to facilitate the communication between the resources using Private IP Addresses.
Before we dive into each of the VCN Peering scenarios, we need to list some points to remember as key considerations:
- The VCNs should have non-overlapping CIDRs.
- Route rules need to be configured in the respective subnets requiring the communication.
- Security rules must be configured to control the traffic types allowed to/from the instances.
- The connection can be used for communication between resources in the directly peered VCNs only.
Local VCN Peering (Local Peering Gateway)
When you connect two VCNs in the same OCI region to allow communication between resources, it is referred to as Local VCN Peering. A Local Peering Gateway (LPG) is the virtual construct that is created to enable this connection. First you will create the LPGs in the VCNs and then establish a connection between the two.
As shown in the figure below, when instance in a Subnet in VCN A need to communicate with resources in VCN B, the traffic will go over the peering connection between the LPGs in the respective VCNs. The subnet route table in VCN A will have a route entry for the 10.20.0.0/16, which is the CIDR for VCN B using the LPG-A as the route target. Similar entry will exist in the subnets in VCN B needing to communicate with VCN A.
Remote VCN Peering (Dynamic Routing Gateway)
Remote VCN peering, facilitated by the DRG, is the process of connecting Virtual Cloud Networks in different OCI regions. A key point to note here is that these VCNs should be in the same customer tenancy. A dynamic routing gateway that might already exist in the VCN for on-prem connectivity, will be used for establishing the peering connection. First, we will define a remote peering connection (RPC) on each DRG in the VCNs and the establish the connection between the RPCs.
The traffic from a subnet in the respective VCN A will be forwarded to the DRG-A to reach 10.10.0.0/16 (VCN B CIDR) and the traffic will traverse of the peering connection. A reverse route will exist in VCN B for the return traffic. This is show in the figure below.
Private Access to Native Oracle Services
Oracle Cloud Infrastructure has a conceptual network for Oracle Services, and this is referred to as the Oracle Services Network. Point to know about the services in the OSN:
- The Services have Public IP Addresses
- These services can be reached over the internet.
Service Gateway
A Service Gateway is used to allow access to the supported resources in the Oracle Services Network. The resources in the OSN have public IP Addresses because you would want to reach them over the internet in several scenarios. However, communication between your resources and Oracle Services in the same OCI region should happen internally without the need to traverse the internet. The Service Gateway is the virtual construct in your VCN that makes this happen.
As shown in the figure below, the route table for the Subnet with instance requiring connection to the Services in the OSN will have an entry with the destination as Object Storage or All Services and the Service Gateway as the route target. The Service Gateway is a regional construct and this setup will allow private communication between instances and services in the same region.
The service gateway makes use of the concept of a Service CIDR Label, which is a string that represents the IP Address Ranges related to the specific service of group of services that instances need to communicate with. As shown in the figure below, the CIDR labels for the services in IAD region could be:
- OCI IAD Object Storage
- All IAD Services in Oracle Services Network
The same labels are used to configure the route rules to forward traffic to the Service Gateway. The benefit of using the label is that if the IP Addresses for the service change in the future, no reconfiguration is required from your end.
Route Tables
Earlier in this post I spoke about providing the “stitching” with communication gateways and route tables help complete that story. Just like traditional networks, the Virtual Cloud Network has a route table to send traffic out of the VCN. These virtual route tables are associated to subnets and control where traffics are forwarded from the VCN and through which next hops (route targets in this case). A route table has route rules which are is a list of the destination CIDRs along with the target for that route.
The route targets that can be configured for respective routes are listed below:
- Dynamic Routing Gateway – The DRG is used as a route target when forwarding traffic to a CIDR belonging to your on-prem networks using FastConnect or VPN Connect (IPSEC VPN). It is also used to forward traffic to a peered VCN in another OCI region.
- Internet Gateway – This is used to forward traffic to the internet from Public Subnets.
- NAT Gateway – You can use the NAT Gateway to forward traffic to the internet from a Private Subnet.
- Service Gateway – Use the Service Gateway as the next hop to get private access to Oracle Services such as Object Storage, Autonomous Data Warehouse etc.
- Local Peering Gateway – Configure LPG as a route target for CIDR belonging to a peered VCN in the same region.
- Private IP – In order to forward traffic from Subnet an instance in the same VCN.
VCN Security
As discussed in the Subnet section, we associate the subnets with Security Lists to control the traffic types accessing the instances in the subnet. We must remember that Oracle Cloud Infrastructure is built on the principles of a least-trust design. You have to allow each traffic type that can flow and access the resources in the VCN.
Security Rules
In order to control the traffic in / out of an instance, security rules are configured. The security rules can be part implemented as a Security List or a Network Security Group. We will take a look at the 2 options here, but first let’s quickly look at Security Rules and their configuration.
Security rules are used to allows a traffic specific types in either egress or ingress direction. Security rules can be stateful or stateless, with stateful rules being the default.
- Stateful Rule – The rule uses connection tracking for the traffic allowed by the rule. In case of an ingress rule, the connection is allowed and tracked, and the return traffic is automatically allowed.
- Stateless Rule – There is no connection tracking for traffic allowed by the rule, which basically means that in case of an ingress rule, the return traffic is not allowed automatically. A matching rule is needed in the opposite direction to allow the return traffic.
A key point to remember here is that a stateless rule takes priority over a stateful rule. This will apply to a situation where a specific traffic type is matched by both kind of rules.
As shown in the image above, the security rule configuration includes the following elements:
- Direction – Ingress or Egress
- Stateful or Stateless
- Source type and Source (Ingress Rules) – Valid Source Types are: CIDR, Network Security Group and Service
- Destination type and Destination (Egress Rules) – Valid Destination Types are: CIDR, Network Security Group and Service
- IP Protocol – You can select a single protocol or use “All” to allow all protocols
- Source Port – Originating port(s) (TCP or UDP) for the traffic
- Destination Port – The port the traffic will hit on the destination resource
- ICMP type and code (ICMP rules)
- Description
The image below shows sample ingress security rules allow HTTP / HTTPS traffic to a specific subnet.
Security Lists (SL)
A Security List is the virtual firewall for an instance. The list contains security rules allowing specific traffic type in a specific direction (ingress or egress). SL is configured at a subnet level and applies to all VNICs in the particular subnet. Up to 5 Security Lists can be applied to a single subnet. A packet is allowed if any security rule in any of the 5 (or as many) applied SLs permits the traffic.
Each VCN has a default security list that is created. This SL allows SSH traffic to instances in the subnet from all sources, along with ingress ICMP traffic. In the egress direction all traffic with all port types is allowed. All rules in the default SL are stateful.
In the above figure, the security list is configured and associated with Subnets A & B both. The rules are being applied to all instances (and VNICs) in the respective subnets, allowing the desired traffic.
Network Security Groups (NSG)
Network Security Groups provide a virtual firewall for instances and resources and allow you to tie security controls to applications & architecture instead of applying this at the entire subnet. What this means is that an NSG contains security rules and is applied to specific VNICs in a particular VCN. The security rules are applied to all VNICs that have the NSG applied to them.
Key points to remember for NSGs, there is no default NSG for a subnet or VCN and an NSG can be specified as the source or destination of a security rule included in the NSG. Network Security Groups can be applied to multiple resources in a VCN:
- Compute Instances
- Load Balancers
- Database Systems
- Autonomous Databases
- Mount targets for file systems.
As shown in the above figure, the NSGs are applied to specific VNICs in the respective subnets. The NSG is tied to the application architecture and not the subnet. Specific rules are applied to VNICs regardless of which subnet they belong to.
In this post we looked at the basic concepts of Oracle Cloud Infrastructure Networking. We looked at the basic networking and communication scenarios as well. I plan to dive into more complex networking scenarios in another post. Stay tuned for the advanced version of this post.