Choose the gateway that provides a path for network traffic between your vcn and the internet.

In my previous blog posts, I have discussed the generic security concepts and Identity and Access Management in OCI. This part of the series discusses OCI Networking Service. Its concepts and best practices for securing networks in OCI.

High-throughput and reliable networking is fundamental to public-cloud infrastructure that delivers compute and storage services at scale. As a result, Oracle has invested significant innovation in Oracle Cloud Infrastructure networking to support requirements of enterprise customers and their workloads. Oracle Cloud Infrastructure regions have been built with a state-of-the-art, non-blocking Clos network that is not over-subscribed and provides customers with a predictable, high-bandwidth, low latency network. The data centers in a region are networked to be highly available and have low-latency connectivity between them.

In this post, I will go into depth on the components that make up the networking layer, and the security rules which can be applied to them.

Virtual Cloud Network (VCN)

The Oracle Cloud Infrastructure Networking service offers a customisable private network (a VCN, or virtual cloud network) to customers, which enforces logical isolation of customer Oracle Cloud Infrastructure resources. A VCN covers a single, contiguous IPv4 CIDR block of customer’s choice. A VCN resides within a single region but can cross multiple Availability Domains.

The VCN can be configured for internet connectivity, or connected to the customer’s private data center through an IPSec VPN gateway or FastConnect. FastConnect offers a private connection between an existing network’s edge router and dynamic routing gateways (DRGs). Traffic does not traverse the internet.

The Networking service also supports bi-directional stateful and stateless firewalls that allow customers to initialize network security access controls. Firewalls and ACLs specified for a customer VCN are propagated throughout the network topology and control plane, ensuring a multi-tiered and defense-in-depth implementation. Each tenant (customer) can create multiple VCNs to implement logical grouping of their resources. All these concepts and terminology involved is explained in the subsequent sections.

Subnets

Each VCN network is subdivided into subnets. Each subnet has a contiguous range of IPs described in CIDR notation. Subnet IP ranges cannot overlap. Instances are placed in subnets. Instances draw their internal IP address and network configuration from their subnet. Subnets can be designated as either: Private – where instances contain private IP addresses assigned to vNICs and Public – contain both private and public IP addresses assigned to vNICs. Each subnet is contained within a single Availability Domain (AD). The following figure 1 depicts the same:

Internet Gateway

Internet Gateway provides a path for the network traffic between your VCN and the internet. 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. This is depicted in the figure 2 below:

Route Table

Each subnet uses a single route table specified at time of subnet creation, but that can be edited later also. Route table is used only if the destination IP address is not within the VCN’s CIDR block. No route rules are required in order 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. The following figure 3 depicts this below:

NAT Gateway

NAT gateway gives an entire private network access to the internet without assigning each host a public IP address. Hosts can initiate outbound connections to the internet and receive responses, but not receive inbound connections initiated from the internet. Use case: updates, patches). You can have more than one NAT gateway on a VCN, though a given subnet can route traffic to only a single NAT gateway. This is depicted in figure 4 below:

Service Gateway

Service gateway lets resources in VCN access public OCI services such as Object Storage, but without using an internet or NAT gateway. Any traffic from VCN that is destined for one of the supported OCI public services uses the instance’s private IP address for routing, travels over OCI network fabric, and never traverses the internet. For example, back up DB Systems in VCN to Object Storage will go through the Service Gateway. This is depicted in the figure 5 below:

Dynamic Routing Gateway

Dynamic Router is a virtual router that provides a path for private traffic between your VCN and destinations other than the internet. You can use it to establish a connection with your on-premises network via IPsec VPN or FastConnect (private, dedicated connectivity). After attaching a DRG, you must add a route for the DRG in the VCN’s route table to enable traffic flow. DRG is a standalone object. You must attach it to a VCN. VCN and DRG have a 1:1 relationship. This is depicted in the figure 6 below:

Local Peering

VCN Peering is a process for connecting multiple VCNs. 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. The two VCNs in the peering relationship shouldn’t have overlapping CIDRs. This is depicted in the figure 7 below:

Remote Peering

Remote VCN peering is the process of connecting two VCNs in different regions so that their resources can communicate using private IP addresses. It requires a remote peering connection (RPC) to be created on the DRGs. RPC’s job is to act as a connection point for a remotely peered VCN. It is generally available for for ASH-PHX and LHR-FRA regions (it can be made available through Oracle support for other combinations). The two VCNs in the peering relationship must not have overlapping CIDRs. This is depicted in the figure 8 below:

Security Lists

They are a common set of firewall rules associated with a subnet and applied to all instances launched inside the subnet. Security lists provide ingress and egress rules that specify the types of traffic allowed in and out of the instances. Security lists apply to a given instance whether it’s talking with another instance in the VCN or a host outside the VCN. You can choose whether a given rule is stateful or stateless. The figure 9 belwo depicts the security lists:

Stateful Security Rules

When an instance receives traffic matching the stateful ingress rule, the response is tracked and automatically allowed regardless of any egress rules; similarly for sending traffic from the host. This is called Connection Tracking. The default Security Lists rules are stateful. The figure 10 below depicts the host in the group that are reachable from the internet on port 80:

Stateless Security Rules

With stateless rules, response traffic is not automatically allowed. •To allow the response traffic for a stateless ingress rule, you must create a corresponding stateless egress rule. If you add a stateless rule to a security list, that indicates that you do NOT want to use connection tracking for any traffic that matches that rule. Stateless rules are better for scenarios with large numbers of connections (Load Balancing, Big Data). The following figure 11 depicts the stateless security rules:

OCI Virtual Private Network (VPN) Overview

OCI VPN securely connects on-premises network to OCI VCN through an IPsec VPN connection. VPN can help ensure a business that its networks provide secure remote connectivity. Bandwidth is dependent on the customer’s access to the Internet and general Internal congestion (Typically less than 250 Mbps – but your mileage may vary). Customer Proof of Concepts usually start as a VPN and then morph into FastConnect designs. OCI provisions redundant VPN tunnels located on physically and logically isolate tunnel endpoints. The figure 12 below depicts the OCI VPN overview:

OCI VPN Configuration Example of Single Site

OCI VPN Configuration Example of Multi Sites

OCI VPN Redundancy Model (Single CPE)

OCI VPN Redundancy Model (Multi CPE)

Summary of OCI network connectivity options and scenarios

Conclusion

In this article, I have tried to explain various networking components and concepts that are available with OCI Networking Service. Based on the enterprise requirements it can be configured to provide the necessary security posture.

In my next article of the series, I will explain the OCI Key Management Service.