04 Networking ‐ Virtual Cloud Network - KleberVales/OCI-Architect-Associate GitHub Wiki

1. CIDR Blocks/Prefixes

1. What is CIDR?

2. Octets and Bits

3. Formula to Calculate the Number of IPs

4. Decimal to Binary Conversion

2. Virtual Cloud Network

1. What is a VCN?

2. CIDR Blocks in the VCN

3. Allowed VCN Size

4. Reserved IP Addresses

5. Availability Domains

6. IPv6 in a VCN

7. VCN as a Software-Defined Network

3. VCN Components

1. Subnet

2. Route Table

3. DHCP Options

4. Security Components

5. Gateways

6. Visualized Architecture

4. Subnets

1. What is a Subnet?

2. Non-Overlapping Rule

3. Subnet Types Regarding Availability

4. Subnet-Level Configurations

5. Subnet Types Regarding Access

5. Route Tables

6. Internet Gateway

7. NAT Gateway

8. Service Gateway

9. Public Subnet

10. Private Subnet

11. VCN Security

12. Network Security Groups

13. Security Lists

.
.
.
.
.

1. CIDR Blocks/Prefixes

What is CIDR?

CIDR Notation

A.B.C.D/x

  • A.B.C.D is an IP address.
  • / is the slash character.
  • x is a decimal number called the prefix length.

For example, instead of writing:

10.0.0.0 to 10.0.255.255

we can write:

10.0.0.0/16

The /16 tells us how many leading bits are fixed. In this case, the first 16 bits—the first two octets—do not change. The remaining bits can vary, which creates the address range.

Octets and IPv4 Bits

An octet is a group of 8 bits. IPv4 addresses have four octets:

10 . 0 . 0 . 0

Each octet contains 8 bits, so IPv4 has a total of:

4 × 8 = 32 bits

In the example 10.0.0.0/16, the first two octets are fixed because the prefix length is 16. That means the first 16 bits are the network portion, and the remaining 16 bits are available for hosts. So the range becomes:

10.0.0.0 – 10.0.255.255

How Many IP Addresses Are in a CIDR Block?

To calculate the total number of IP addresses in a CIDR block, use this formula:

2^(32 − prefix length)

The 32 comes from the total number of bits in an IPv4 address. The prefix length is the number after the slash.

For 10.0.0.0/16:

2^(32 − 16) = 2^16 = 65,536 addresses

So a /16 block contains 65,536 total IP addresses. In practical networking, the first and last addresses may be reserved for the network address and broadcast address, but the total block size is still 2^16.

Another example: a /24 block has:

2^(32 − 24) = 2^8 = 256 addresses

Understanding the Binary Behind CIDR

To really understand CIDR, it helps to see how decimal octets become binary. Each octet uses these place values:

128, 64, 32, 16, 8, 4, 2, 1

These correspond to powers of 2 from 2^7 down to 2^0.

Why CIDR Matters

CIDR allows networks to be described efficiently without being tied to traditional fixed address classes. The prefix length tells you how many bits identify the network, while the remaining bits identify hosts. This makes CIDR useful for subnetting, routing, and allocating IP address ranges of different sizes.

CIDR Blocks/Prefixes - part 2

CIDR blocks provide a compact way to represent IP address ranges using notation such as A.B.C.D/x. The prefix length indicates how many bits are used for the network portion, while the remaining bits are used for hosts. Subnetting allows larger networks to be divided into smaller ones, and a key rule is that a smaller prefix number represents a larger network—so /16 is bigger than /24. For example, /16 gives 2^16 = 65,536 addresses, while /24 gives 2^8 = 256 addresses. In a /24 network, the first 24 bits are the network address and the last 8 bits are the host address. Using the example 192.168.1.2/24, the subnet mask is 255.255.255.0, and a logical AND operation between the IP address and the subnet mask produces the network address 192.168.1.0. Understanding these concepts helps you read CIDR notation, calculate network sizes, identify network addresses, and prepare for more advanced topics such as subnetting and virtual cloud networks.

1. CIDR Notation Recap

A CIDR prefix represents an IP address or a range of IP addresses. It is written in the form:

A.B.C.D/x

For example:

192.168.1.0/24

The notation contains:

  • An IP address, such as 192.168.1.0
  • A slash character /
  • A prefix length, such as 24

The prefix length tells us how many leading bits are used for the network portion.

2. Subnetting

Subnetting is the process of breaking a larger network into smaller networks. Using subnetting, a larger CIDR prefix can be divided into smaller CIDR prefixes.

For example, a larger network can be split into multiple smaller subnets to organize devices, improve routing, or separate departments.

We will explore subnetting in more detail in upcoming sections.

3. Prefix Length and Network Size

An important rule to remember is:

The smaller the prefix number, the larger the network.

For example:

  • /16 is a larger network than /24
  • /16 gives 2^(32−16) = 2^16 = 65,536 addresses
  • /24 gives 2^(32−24) = 2^8 = 256 addresses

So even though /16 looks like a smaller number than /24, it actually represents a much larger address range.

4. Network Bits and Host Bits

The prefix length separates the network portion from the host portion.

For a /24 network:

  • The first 24 bits are the network address
  • The last 8 bits are the host address

For a /16 network:

  • The first 16 bits are the network address
  • The remaining 16 bits are for host addresses

In a /16 network, the host portion can range from:

0.0 to 255.255

5. Example: 192.168.1.2/24

Consider the IP address:

192.168.1.2/24

The /24 subnet mask is:

255.255.255.0

This is because the first 24 bits are all set to 1:

11111111.11111111.11111111.00000000

Now convert the IP address to binary:

192 = 128 + 64 = 11000000
168 = 128 + 32 + 8 = 10101000
1 = 00000001
2 = 00000010

So:

192.168.1.2 = 11000000.10101000.00000001.00000010

When we perform a logical AND between the IP address and the subnet mask, we get the network address.

Logical AND works like this:

  • 1 AND 1 = 1
  • 1 AND 0 = 0
  • 0 AND 1 = 0
  • 0 AND 0 = 0

Applying the AND operation:

11000000.10101000.00000001.00000010 AND 11111111.11111111.11111111.00000000 = 11000000.10101000.00000001.00000000

This gives:

192.168.1.0

So 192.168.1.0 is the network address for 192.168.1.2/24.

3. Virtual Cloud Network

A Virtual Cloud Network, or VCN, is a software-defined private network that you create inside an Oracle Cloud Infrastructure region. It is a core OCI networking building block and acts like a private, isolated network for your cloud resources. When you create a VCN, you must attach at least one CIDR block, and you can have up to five IPv4 CIDR blocks and up to five IPv6 CIDR blocks, as long as they do not overlap. VCN CIDR sizes can range from /16 to /30, and CIDR blocks can be resized after creation. Inside any CIDR, the first IP is the network address, the second IP is the subnet default gateway, and the last IP is the broadcast address; these are reserved and cannot be assigned to hosts. A VCN is regional, meaning it resides in one region, but it can span multiple availability domains within that region—it cannot span multiple regions. For IPv6, you can use an Oracle-allocated /56 prefix or bring your own IPv6 prefix. Understanding VCNs is essential for designing secure and scalable OCI network architectures.

What Is a VCN?

A VCN is:

  • A virtual private network inside an OCI region
  • A software-defined network
  • A regional construct
  • A network that can span multiple availability domains (ADs) within the same region

A VCN cannot span multiple regions. It always resides within a single region.

For example, if a region has three availability domains—AD1, AD2, and AD3—a VCN can span all three. But a VCN in Region 1 cannot extend into Region 2.

CIDR Blocks in a VCN

When you create a VCN, you must associate at least one CIDR block. A CIDR block defines the IP address range for the VCN.

Key rules for VCN CIDR blocks:

  • You can have up to five IPv4 CIDR blocks.
  • If IPv6 is enabled, you can also have up to five IPv6 CIDR blocks.
  • At least one CIDR block is mandatory.
  • CIDR blocks must be non-overlapping.
  • You can resize CIDR blocks even after the VCN is created.

Allowed VCN Size

A VCN can be created with a CIDR prefix length from /16 to /30.

Examples:

  • /16 is a very large VCN.
  • /24 is a smaller VCN.
  • /30 is a very small VCN.

Reserved IP Addresses

Within any CIDR block, some IP addresses are reserved and cannot be assigned to hosts. The reserved addresses are:

  1. The first IP address — network address
  2. The second IP address — subnet default gateway address
  3. The last IP address — broadcast address

Example: 192.168.0.0/24

Consider the CIDR block:

192.168.0.0/24

The reserved IP addresses are:

Address Purpose
192.168.0.0 Network address
192.168.0.1 Subnet default gateway
192.168.0.255 Broadcast address

These three IPs cannot be allocated to hosts.

VCN and Availability Domains

An OCI region can have:

  • One availability domain, or
  • Three availability domains

A VCN is regional, so it resides in a single region. However, if the region has multiple availability domains, the VCN can span across them. This allows resources in different ADs to be part of the same VCN.

Remember:

  • VCN can span multiple ADs within one region.
  • VCN cannot span multiple regions.

IPv6 in a VCN

When using IPv6, you have two main options:

  1. Oracle-allocated IPv6 prefix — Oracle provides a /56 prefix.
  2. Bring Your Own IPv6 prefix (BYOIPv6) — You can use your own IPv6 prefix.

This gives flexibility depending on your organization’s addressing needs.

4. VCN Components - Quick Overview

This video lesson provides a 10,000-foot overview of the components of a VCN (Virtual Cloud Network) in OCI. The goal is to give a high-level introduction before delving deeper into each component in subsequent lessons.

1. Subnet

Definition: A subnet is a division of the VCN—a smaller network within the larger network.

Example taught:

  • VCN CIDR: 10.0.0.0/16

  • Divided into three subnets:

  • 10.0.1.0/24

  • 10.0.2.0/24

  • 10.0.3.0/24

Why it's important:

  • It's the configuration unit of the VCN.

  • Virtual machine (VM) instances reside within the subnet.

  • Some constructs are defined at the subnet level:

  • Route table

  • Security list

  • DHCP options

  • If you attach a route table to a subnet, it affects all VMs within it.

Subnet Types:

Type Description
Public Subnet Public subnet.
Private Subnet Private subnet.

2. Route Table

Definition: Determines how traffic flows within the VCN and defines the path to the destination.

Analogy taught:

  • Roads with intersections and a traffic warden controlling the flow of vehicles.

  • The route table is like that warden: it decides where the traffic goes.

Note: Every VCN has a default route table when it is created.

3. DHCP Options

Definition: DHCP = Dynamic Host Configuration Protocol.

Function: To automatically provide configuration information to instances when they initialize (boot).

Importance: Essential component for the automatic configuration of instances.

4. Security Components

There are two main security components in the VCN:

Security List

  • Defines which traffic is allowed to enter and exit.

  • Associated with a subnet.

Network Security Group (NSG)

  • Also defines which traffic is allowed to enter and exit.

  • Associated with a Virtual Network Interface Card (VNIC).

Main difference:

Component Associated with
Security List Subnet
NSG Virtual Network Interface Card (VNIC)

5. Gateways (Communication Portals)

Definition: These are "portals" that allow communication between the VCN and other destinations.

Analogy taught:

  • To go from home to the market, you need to exit through a gate.

  • In the VCN, gateways are these "gates" to different destinations.

Types of gateways presented:

Gateway Function
Internet Gateway Allows communication with the internet.
NAT Gateway Allows instances in a private subnet to access the internet (without being accessed from outside).
Service Gateway Allows communication with the Oracle Services Network (e.g., Object Storage).

6. Visualized Architecture

This lesson presents an architecture with:

  • OCI Region

  • VCN

  • Public Subnet

  • Private Subnet

  • Customer Data Center (left) — with Customer Premises Equipment.

  • Oracle Services Network (right) — e.g., Object Storage.

  • Gateways (middle) — Internet Gateway, NAT Gateway, Service Gateway.

Note: The terms will be detailed in subsequent lessons; the objective here is only to visualize the architecture.

5. Subnets

This video lesson teaches the concept of subnets in OCI (Oracle Cloud Infrastructure), a fundamental component of a VCN (Virtual Cloud Network). Subnets are sub-networks created by dividing a VCN, with their own IP ranges, types, and configuration rules.

1. What is a Subnet?

Definition: A subnet is a sub-network — a division of the VCN into smaller networks. It is represented in CIDR notation.

Example taught:

  • VCN: 10.0.0.0/16
  • Subnet A: 10.0.1.0/24
  • Subnet B: 10.0.2.0/24

Important rule:

The larger prefix number, the smaller the network.

  • /16 = larger network
  • /24 = smaller network

2. Non-Overlapping Rule

If a VCN has multiple subnets (A, B, C, D), each has its own IP address range, and these ranges cannot overlap.

Example 1 — Overlapping:

  • CIDR 1: 10.0.0.0/16
  • CIDR 2: 10.0.0.0/24
  • Result: There is overlap, because /24 is part of /16.

Example 2 — No overlap:

  • CIDR 1: 10.0.1.0/24
  • CIDR 2: 10.0.2.0/24
  • Result: There is no overlap — they can be used as subnet ranges. Flexibility: Just like the VCN, the subnet's CIDR can be changed after creation.

3. Subnet Types Regarding Availability

3.1 AD-Specific Subnet

  • Created in a specific Availability Domain.

  • Example:

  • Subnet A → AD1

  • Subnet B → AD2

  • Subnet C → AD3

3.2 Regional Subnet

  • Recommended as best practice.

  • Can cover all Availability Domains in a region.

  • Valid only in multi-AD regions.

  • In regions with a single AD, creating an AD-specific or regional subnet is the same thing.

4. Subnet-Level Configurations

When creating a subnet, you specify:

  • Associated Route Table.

  • Associated Security List.

  • Associated DHCP Options.

Importance: All instances within the subnet inherit the configuration defined at the subnet level.

Example: If the Default Route Table is associated with the subnet, all instances in that subnet will use the routing information from that table.

Key Concept: The subnet is the configuration unit of the VCN.

5. Subnet Types Regarding Access

5.1 Public Subnet

  • VMs within it receive a public IP and a private IP on the vNIC.

  • Typical Use: Web servers.

5.2 Private Subnet

  • VMs within it receive only private IPs.

  • They do not receive a public IP on the vNIC.

  • Typical use: Database servers.

Important decision:

When creating the subnet, you must decide whether it will be public or private. This choice cannot be changed later.

6. Route Tables

Introduction

In this lesson, we will explore the concept of Route Tables within a Virtual Cloud Network (VCN). We will cover what they are, the different types available, and how they function to direct traffic flow within and outside your network.

What is a Route Table?

A route table is a set of rules that determines how traffic flows inside a VCN and how traffic originating from the VCN flows to external destinations. Essentially, it defines the path for data packets to reach their destination.

Types of Route Tables

There are two primary types of route tables in a VCN:

1. Default Route Table

  • Creation: This is automatically created when you create a VCN.
  • Implicit Rules: The default route table contains an implicit local route.
    • What this means: All subnets within the VCN are associated with this table by default.
    • Function: This rule allows all subnets and instances within the VCN to communicate with each other without requiring any additional configuration.
    • Note: While the table may appear empty in the interface, this local route exists behind the scenes to facilitate internal communication.

2. Custom Route Table

  • Creation: This is a user-created route table.
  • Implicit Rules: Like the default table, a custom route table also includes the implicit local route for internal VCN communication.
  • Purpose: Custom route tables are used to influence the routing of specific subnets.
    • Example: If you have both Public and Private subnets in your VCN, they likely require different routing rules. A single route table cannot handle both scenarios efficiently, so you create custom tables to associate with specific subnets (e.g., a custom table for the public subnet).

Anatomy of a Route Rule

A route table consists of two main columns that define a route rule:

  1. Destination CIDR Block: This defines the IP range of the traffic's destination.
  2. Target (Next Hop): This defines where the traffic should be sent to reach that destination.

Example Scenario

Imagine an instance in a subnet that wants to communicate with the Internet.

  • Destination: The Internet is the destination. In CIDR notation, this is represented as 0.0.0.0/0.
  • Target: The traffic needs to pass through an Internet Gateway.
  • The Rule: To enable this, you create a rule where the Destination is 0.0.0.0/0 and the Target is the Internet Gateway.

Types of Targets (Next Hops)

While the Internet Gateway is a common target, route tables can direct traffic to various other targets, including:

  • Service Gateway: For accessing Oracle services without going over the internet.
  • NAT Gateway: For allowing private subnets to access the internet for updates without being exposed.
  • Dynamic Routing Gateway (DRG): For connecting to on-premises networks or other VCNs.
  • Local Peering Gateway (LPG): For connecting to another VCN in the same region.
  • Private IP: For routing traffic to a specific private IP address (e.g., a firewall appliance).

Summary

  • Route Tables determine traffic flow.
  • Default Route Tables are created automatically with a VCN.
  • Custom Route Tables are created by users for specific routing needs.
  • Both table types include an implicit local route for internal communication.
  • Route rules consist of a Destination CIDR and a Target (Next Hop).

Route Table part 2

1. Route Table Basics

A route table defines the path for a destination. It determines how traffic flows, especially when traffic is leaving the VCN. Traffic inside the VCN is handled by the local route, so internal communication does not require additional route rules.

A route table is always associated with a subnet. The association rules are important:

  • One subnet can be associated with only one route table.
  • One route table can be associated with multiple subnets.

For example:

  • The default route table can be associated with multiple subnets (e.g., Subnet A, Subnet B, Subnet C).
  • You cannot associate a single subnet with two different route tables at the same time.

This means:

  • ✅ One route table → many subnets
  • ❌ One subnet → many route tables

2. Local Routing Inside the VCN

Inside a VCN, instances in different subnets can communicate with each other because of the VCN local route. This local route is implicit and enables internal communication without any extra configuration.

Key point:

  • Local traffic is automatically handled by the local route.
  • Route tables mainly influence traffic leaving the VCN or going to specific external destinations.

3. Rule Priority: Most Specific Rule Wins

When multiple route rules overlap, the most specific rule wins.

Example 1: Specific vs. Generic

Compare these two CIDR blocks:

  • 0.0.0.0/0 — generic, matches all internet traffic.
  • A specific IP range — more specific.

The specific range is considered the most specific and will be chosen.

Example 2: Internet Gateway vs. Service Gateway

Imagine a VCN with a subnet and two possible destinations:

Destination CIDR Target
0.0.0.0/0 Internet Gateway
Object Storage CIDR Service Gateway

Object Storage is part of the Oracle Services Network and has its own IP range. Because 0.0.0.0/0 also matches Object Storage traffic, both rules could apply. However, the Object Storage CIDR is more specific, so traffic to Object Storage goes through the Service Gateway, not the Internet Gateway.

Critical rule: Most specific route wins in case of overlapping rules.

What if no rule matches?

If traffic does not match any route in the route table, the traffic is dropped.

4. Default vs. Custom Route Tables

There are two types of route tables:

Default Route Table

  • Automatically created when you create a VCN.
  • Contains an implicit local route.
  • In the console, the number of rules may show 0, but the local route still exists behind the scenes.
  • Can be associated with multiple subnets.

Custom Route Table

  • Created by you whenever needed.
  • Also contains the implicit local route.
  • Used to influence routing for specific subnets, such as separating public and private subnet behavior.

Each rule in a route table has:

  1. Destination CIDR block
  2. Route target (next hop)

5. Example: Public and Private Subnets

Consider a VCN with:

  • A public subnet
  • A private subnet

Private Subnet Route Table

Private instances may need to download patches from the internet or access Oracle services.

Destination Target
0.0.0.0/0 NAT Gateway
Object Storage CIDR Service Gateway
  • Internet-bound traffic uses the NAT Gateway.
  • Object Storage traffic uses the Service Gateway because it is more specific.

Public Subnet Route Table

Public instances may need direct internet access.

Destination Target
0.0.0.0/0 Internet Gateway
  • Internet-bound traffic uses the Internet Gateway.

If Object Storage is also required from the public subnet, a more specific Service Gateway rule can be added.

6. Supported Route Target Types

The following target types are valid for a route rule:

Target Type Typical Use Case
Internet Gateway Public subnets that need direct internet access.
NAT Gateway Private subnets that need to download from the internet. This is unidirectional, not bidirectional.
Service Gateway Private access to Oracle services such as Object Storage.
Local Peering Gateway Access to another VCN in the same region after peering.
Dynamic Routing Gateway Communication between an on-premises network and your VCN.
Private IP Route traffic to a specific instance in the VCN.

7. Internet Gateway

1. What Is an Internet Gateway?

An Internet Gateway (IGW) is a VCN component that enables direct connectivity between a VCN and the internet. It is a managed service, meaning Oracle Cloud Infrastructure handles scaling, high availability, and fault tolerance automatically.

Key characteristics:

  • Supports bidirectional communication (ingress and egress).
  • Enables instances in a VCN to communicate with the internet.
  • Allows internet hosts to initiate communication with instances in the VCN.
  • Only one Internet Gateway per VCN is required — and you cannot create multiple IGWs for a single VCN.

2. Ingress vs. Egress Traffic

An Internet Gateway supports both directions of traffic:

Direction Description Example
Ingress Traffic entering the VCN from the internet. An external user connects to a web server in your VCN.
Egress Traffic leaving the VCN to the internet. A VM in your VCN downloads updates from the internet.

Because it supports both, the IGW enables full bidirectional communication.

3. Conditions for Internet Access

For an instance to send traffic to the internet through an Internet Gateway, three conditions must be met:

  1. The instance must be in a public subnet.
  2. The instance must have a public IP address.
  3. The subnet’s route table must have a valid route entry pointing to the Internet Gateway.

Note: Only one Internet Gateway is needed per VCN. It is associated at the VCN level and used by subnets via route tables.

4. Route Table Configuration Example

Consider a public subnet with a VM that needs to access the internet.

Destination CIDR Target
0.0.0.0/0 Internet Gateway
  • Destination: 0.0.0.0/0 represents all internet traffic.
  • Target: The Internet Gateway.

This route entry allows the VM in the public subnet to send traffic to the internet. The IGW then handles both outbound (egress) and inbound (ingress) traffic.

5. Important Reminder: Security Rules

Routing alone is not enough. Even if:

  • The VM has a public IP,
  • The VM is in a public subnet,
  • The route table points to the Internet Gateway,

you still need to open the required ports using Security Lists or Network Security Groups (NSGs). These security rules control which traffic is allowed to reach or leave the instance. Without them, communication will fail.

Key takeaway: Routing determines the path; security rules determine whether traffic is permitted.

6. Summary

  • An Internet Gateway provides direct internet connectivity for a VCN.
  • It supports both ingress and egress traffic.
  • It is a managed service with built-in high availability.
  • One IGW per VCN is sufficient and is the maximum allowed.
  • To use an IGW, an instance must be in a public subnet, have a public IP, and be associated with a route table that points to the IGW.
  • Security rules (Security Lists or NSGs) must also allow the traffic.

8. NAT Gateway

A NAT Gateway (Network Address Translation Gateway) is a managed VCN component that allows instances in a private subnet to initiate outbound connections to the internet and receive responses, while blocking inbound connections initiated from the internet. It translates the private source IP addresses of those instances to the NAT Gateway’s own public IP address.

Learning Objectives

By the end of this lesson, you will be able to:

  • Explain why a NAT Gateway is needed for private subnets.
  • Describe how NAT Gateway handles outbound and inbound traffic.
  • Identify the supported traffic types.
  • Understand source IP translation and public IP options.
  • Configure routing for a NAT Gateway.
  • Recognize the scope and limitations of a NAT Gateway.

1. Why NAT Gateway Is Needed

Instances deployed in a private subnet only have private IP addresses. They do not have public IP addresses. Therefore, they cannot directly communicate with the internet.

A NAT Gateway solves this problem by providing instances in a private subnet with outbound internet access.

Common use case: Database servers in a private subnet that need to download patches or updates from the internet.

2. How NAT Gateway Works

NAT stands for Network Address Translation.

Outbound Connections

  • Private instances can initiate connections to the internet.
  • They can also receive responses to those connections.
  • This is allowed.

Inbound Connections

  • Connections initiated from the internet to private instances are not allowed.
  • They are denied or rejected.

Because of this behavior, NAT Gateway is often described as unidirectional in nature, unlike an Internet Gateway, which supports bidirectional communication.

Source IP Translation

Since private instances do not have public IP addresses:

  • The source IP of outbound traffic becomes the NAT Gateway’s public IP address.
  • The NAT Gateway must therefore have a public IP assigned to it.

3. Supported Traffic Types

NAT Gateway supports:

  • TCP
  • UDP
  • ICMP ping

4. Blocking Traffic Through NAT Gateway

NAT Gateway includes a feature that allows you to block traffic flowing through the NAT Gateway.

When enabled:

  • All traffic through the NAT Gateway is blocked.
  • This happens regardless of route rules or security rules in the VCN.

This is a useful feature for quickly cutting off outbound internet access from private subnets.

5. NAT Gateway Characteristics

  • Managed service: Oracle Cloud Infrastructure handles high availability and scaling.
  • Highly available: No need to manage redundancy yourself.
  • Concurrent connections: Supports up to 20,000 concurrent connections.
  • Public IP options:
    • Ephemeral IP: Assigned by Oracle; not permanent.
    • Reserved IP: You can assign a reserved public IP to the NAT Gateway.

The public IP assigned to the NAT Gateway is used as the source IP for outbound traffic from private instances.

6. Routing and Scope

Routing

For a private subnet to use a NAT Gateway, the subnet must be associated with a route table that has a route to the internet through the NAT Gateway.

Typical route table entry:

Destination CIDR Target
0.0.0.0/0 NAT Gateway

Scope Limitation

A NAT Gateway can be used only by resources in its own VCN.

It cannot be used by:

  • Resources in a peered VCN.
  • Resources in an on-premises network connected to the VCN.

Even if another VCN is peered with the VCN containing the NAT Gateway, resources in that other VCN cannot use the NAT Gateway to access the internet.

7. Example Architecture

  • VCN
    • Private Subnet
      • Database system
      • No public IP
      • Route table: 0.0.0.0/0 → NAT Gateway
    • NAT Gateway
      • Has a public IP
      • Allows outbound internet access
      • Blocks inbound connections initiated from the internet

The database server can initiate connections to the internet and receive responses, but internet hosts cannot initiate connections to the database server.

8. Summary

  • NAT Gateway provides outbound internet access for private subnet instances.
  • It supports TCP, UDP, and ICMP ping.
  • It allows responses to outbound-initiated connections but blocks inbound-initiated connections.
  • Source IP is translated to the NAT Gateway’s public IP.
  • It is a managed, highly available service.
  • It supports 20,000 concurrent connections.
  • Public IP can be ephemeral or reserved.
  • It can only be used by resources in the same VCN.
  • A route table entry is required: 0.0.0.0/0 → NAT Gateway.

9. Service Gateway

A Service Gateway is a VCN component that enables resources in a VCN — including resources with only private IP addresses — to privately access services in the Oracle Services Network (OSN) without traversing the internet. Traffic travels over the Oracle network fabric, providing secure and private connectivity to supported Oracle services in the same region.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define the Oracle Services Network (OSN).
  • Explain the purpose and benefits of a Service Gateway.
  • Describe how Service Gateway enables private access to Oracle services.
  • Understand what a Services CIDR Label is and why it is used.
  • Configure a route table entry for Service Gateway.
  • Recognize that Service Gateway is a regional service.

1. Oracle Services Network (OSN)

The Oracle Services Network (OSN) is a construct reserved for Oracle services. These services have public IP addresses, and traditionally, they are reached over the internet.

However, accessing them over the internet is not the best practice because it can expose data. The better approach is to access these services privately.

2. What Is a Service Gateway?

A Service Gateway allows cloud resources that do not have public IP addresses — meaning resources with only private IP addresses — to reach Oracle services in the OSN.

Key benefits:

  • Enables private access to Oracle services.
  • Traffic never traverses the internet.
  • Traffic travels over the Oracle network fabric.
  • Provides a secure and private path for network traffic.
  • Hosts in a VCN do not need public IP addresses.
  • You do not need an Internet Gateway or NAT Gateway for this access.

3. Why Private Access Matters

The main concern is not exposing data when traffic goes over the internet. By using a Service Gateway, communication with Oracle services remains on Oracle’s private network, reducing exposure and improving security.

4. Services CIDR Label

Oracle services have public IP address ranges, not just single IP addresses. You could manually enter these ranges, but that creates problems:

  • If the service’s public IP addresses change, you may need to update routing, security rules, and route tables manually.

To avoid this, use a Services CIDR Label.

  • A Services CIDR Label is a string that represents all regional public IP address ranges for Oracle services.
  • Example: OCI PHX Object Storage represents the Object Storage service in the Phoenix region.
  • Using the label means you do not have to manually adjust IP ranges if they change.

5. Architecture Example

Consider a VCN with a private subnet containing servers that:

  • Do not have public IP addresses.
  • Have only private IP addresses.
  • Need to access Object Storage, which is part of the Oracle Services Network.

A Service Gateway is deployed, and the route table is updated.

Route Table for the Private Subnet

Destination Target
0.0.0.0/0 NAT Gateway
Services CIDR Label for Object Storage Service Gateway
  • Internet-bound traffic uses the NAT Gateway.
  • Object Storage traffic uses the Service Gateway.
  • The destination for Oracle services uses the Services CIDR Label instead of manually entered IP addresses.

This allows the private servers to communicate with Object Storage privately.

6. Regional Scope

Service Gateway is a regional service. It enables access to supported Oracle services in the same region. It does not provide access to services in other regions.

7. Summary

  • Oracle Services Network (OSN) is reserved for Oracle services with public IP addresses.
  • Service Gateway enables private access to OSN services without internet traversal.
  • Traffic stays on the Oracle network fabric.
  • Resources only need private IP addresses.
  • No Internet Gateway or NAT Gateway is required for this private access.
  • Use a Services CIDR Label instead of manually entering IP ranges.
  • Service Gateway is regional and provides access to supported services in the same region.
  • Route table entry example: Services CIDR Label → Service Gateway.

9. Public Subnet

Lesson: Public Subnet in Oracle Cloud Infrastructure

Lesson Definition

A Public Subnet is a subnet within a VCN that allows instances deployed inside it to be assigned public IP addresses on their Virtual Network Interface Cards (VNICs). When combined with a route table entry pointing to an Internet Gateway and appropriate security rules, a public subnet enables instances to communicate directly with the internet.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define a public subnet and its purpose.
  • Explain how public IP addresses are assigned to instances in a public subnet.
  • Identify the components required for internet communication from a public subnet.
  • Configure a public subnet with the necessary route table and security rules.
  • Visualize the architecture of a public subnet with internet access.

1. Types of Subnets in a VCN

Inside a VCN, there are two types of subnets:

  1. Public Subnet
  2. Private Subnet

This lesson focuses on the public subnet.

2. What Is a Public Subnet?

When creating a subnet in the OCI Console, you will see an option under Subnet Access:

  • Public Subnet — This is the default choice.
  • Private Subnet

Key Feature

Selecting Public Subnet enables the ability to assign public IP addresses to the virtual NICs (VNICs) of instances deployed within that subnet.

  • If you do not select public subnet, you cannot assign a public IP address to instances.
  • A public IP address is allocated to the instance's VNIC, not the subnet itself.

3. How Public Subnet Works

Consider a VCN with a public subnet containing virtual machine instances (VM1, VM2). The public subnet allows these instances to have public IP addresses.

For an instance in a public subnet to communicate with the internet, the following must be in place:

Step 1: Create a Public Subnet

  • Select Public Subnet under Subnet Access when creating the subnet.

Step 2: Deploy Instances

  • Deploy virtual machine instances inside the public subnet.
  • Enable public IP address for the instance's VNIC.

Step 3: Associate a Route Table

  • Associate the subnet with a route table that has a route entry to the internet.
Destination CIDR Target
0.0.0.0/0 Internet Gateway

Step 4: Configure Security Rules

  • Open the required ports using:
    • Security Lists (associated with the subnet)
    • Network Security Groups (NSGs)
  • Without proper security rules, communication will fail even if routing is correct.

4. Architecture Overview

Imagine the following setup:

  • VCN

    • Private Subnet
    • Public Subnet
      • VM instance with public IP enabled on its VNIC
      • Route table: 0.0.0.0/0 → Internet Gateway
      • Security rules allowing traffic

  • Internet Gateway attached to the VCN.

This configuration allows the VM in the public subnet to communicate with the internet.

5. Summary

  • A public subnet allows instances to have public IP addresses on their VNICs.
  • Public Subnet is the default option when creating a subnet in OCI.
  • To enable internet communication from a public subnet, you need:
    1. A public subnet.
    2. An instance with a public IP on its VNIC.
    3. A route table with 0.0.0.0/0 → Internet Gateway.
    4. Security rules (Security Lists or NSGs) allowing the traffic.
  • Public IP addresses are assigned to the VNIC of the instance, not the subnet.

10. Private Subnet

A Private Subnet is a subnet within a VCN that prohibits public IP addresses for instances deployed inside it. Instances in a private subnet can only have private IP addresses. To enable outbound internet access, a NAT Gateway is used. To communicate with an on-premises environment, a Dynamic Routing Gateway (DRG) is used.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define a private subnet and its key characteristics.
  • Explain why instances in a private subnet cannot have public IP addresses.
  • Identify the gateways used for internet and on-premises connectivity from a private subnet.
  • Describe how a route table is configured for a private subnet.
  • Visualize a typical private subnet architecture with NAT Gateway and DRG.

1. What Is a Private Subnet?

When creating a subnet inside a VCN, you have two options under Subnet Access:

  • Public Subnet
  • Private Subnet

A private subnet:

  • Does not allow public IP addresses for instances.
  • Allows instances to have only private IP addresses.
  • Prohibits the assignment of public IPs to the VNICs of instances created inside it.

This is the opposite of a public subnet, where public IPs are allowed.

2. IP Addressing in a Private Subnet

  • Instances deployed in a private subnet receive only private IP addresses.
  • They do not have public IP addresses.
  • This restriction is automatically enforced when you create the subnet as a private subnet.

Because instances lack public IPs, they cannot directly communicate with the internet or external networks.

3. Connectivity Options for Private Subnet Instances

Even though private instances lack public IPs, they can still communicate with external networks using specific gateways:

Destination Gateway Purpose
Internet NAT Gateway Allows outbound internet access (e.g., downloading patches).
On-Premises Network Dynamic Routing Gateway (DRG) Enables communication with your on-premises environment.

NAT Gateway

  • Provides outbound internet access for private instances.
  • Allows responses to outbound-initiated connections.
  • Blocks inbound connections initiated from the internet.
  • Covered in detail in a previous lesson.

Dynamic Routing Gateway (DRG)

  • Used to connect your VCN to an on-premises network.
  • Will be covered in an upcoming lesson.
  • For now, note that DRG is the gateway for on-premises communication.

4. Route Table for a Private Subnet

The route table for a private subnet typically contains entries that direct traffic to the appropriate gateway.

Example route table for a private subnet:

Destination CIDR Target
0.0.0.0/0 NAT Gateway
On-premises CIDR Dynamic Routing Gateway
  • Internet-bound traffic (0.0.0.0/0) goes through the NAT Gateway.
  • Traffic destined for the on-premises network goes through the DRG.

5. Architecture Overview

Consider a VCN with a private subnet containing virtual machine instances.

  • Private Subnet

    • Instances with only private IP addresses.
    • Route table:
      • 0.0.0.0/0 → NAT Gateway
      • On-prem CIDR → Dynamic Routing Gateway

  • NAT Gateway attached to the VCN for internet access.

  • Dynamic Routing Gateway attached to the VCN for on-premises connectivity.

This setup allows private instances to:

  • Initiate outbound internet connections via NAT Gateway.
  • Communicate with on-premises resources via DRG.
  • Remain protected from inbound internet-initiated connections.

6. Summary

  • A private subnet prohibits public IP addresses for instances.
  • Instances have only private IP addresses.
  • NAT Gateway provides outbound internet access.
  • Dynamic Routing Gateway (DRG) enables on-premises communication.
  • The route table for a private subnet directs traffic to these gateways.
  • Private subnets are ideal for resources that should not be directly exposed to the internet, such as database servers.

11. VCN Security

VCN Security refers to the set of strategies, constructs, and policies used to control and protect network traffic within a Virtual Cloud Network. It includes the use of public and private subnets, Security Lists, Network Security Groups (NSGs), firewall rules, IAM policies, and Security Zones to ensure that resources are protected and comply with Oracle security principles and best practices.

Learning Objectives

By the end of this lesson, you will be able to:

  • Identify the different strategies for securing a VCN.
  • Explain the purpose of Security Lists and Network Security Groups (NSGs).
  • Distinguish between Security Lists and NSGs using an analogy.
  • Understand the association limits for Security Lists and NSGs.
  • Describe the role of IAM policies and Security Zones in VCN security.

1. Strategies for VCN Security

There are multiple ways to control and secure a Virtual Cloud Network:

Strategy Description
Public and Private Subnets Designate subnets as private to restrict public IP addresses.
Security Lists A virtual firewall associated with a subnet.
Network Security Groups (NSGs) A virtual firewall associated with a VNIC.
Firewall Rules on Instance Configure firewall rules directly on the instance.
IAM Policies Control who can set up VCNs, subnets, security lists, and NSGs.
Security Zones Ensure networking resources comply with Oracle security principles and best practices.

2. Security Lists and Network Security Groups (NSGs)

In OCI, there are two main constructs for controlling traffic:

Security List

  • Associated with a subnet.
  • Acts as a virtual firewall for the subnet.
  • Applies to all instances within the subnet.

Network Security Group (NSG)

  • Associated with a VNIC (Virtual Network Interface Card).
  • Acts as a virtual firewall for specific instances.
  • Provides more granular control than Security Lists.

You may choose to use:

  • Security Lists alone
  • NSGs alone
  • Both together

3. Layman Analogy: Housing Society

To understand the difference between Security Lists and NSGs, consider a Housing Society:

  • Housing Society = Subnet
  • Individual Houses = Virtual Machine Instances
  • Main Gate Guard = Security List
  • Dedicated Guard at Each House = Network Security Group

How It Works

  1. A person (traffic) must first pass through the main gate (Security List) to enter the society (subnet).
  2. Then, to enter a specific house (instance), the person must be allowed by the dedicated guard (NSG).

This means:

  • Security List controls traffic at the subnet level.
  • NSG controls traffic at the instance (VNIC) level.

4. Association Limits

There are limits to how many Security Lists and NSGs can be associated:

Resource Maximum Associations
Subnet Up to 5 Security Lists
VNIC Up to 5 Network Security Groups (NSGs)

5. Default Security List

Just as a VCN automatically creates a default route table, it also creates a default security list when the VCN is created. This default security list provides initial security rules for the VCN.

6. IAM Policies

IAM (Identity and Access Management) policies control:

  • Who can set up VCNs and subnets.
  • Who can configure Security Lists and NSGs.
  • Who can manage other networking resources.

This adds an additional layer of security by restricting administrative access.

7. Security Zones

A Security Zone is a construct that ensures networking resources comply with Oracle security principles and best practices.

Key characteristics:

  • Always associated with a compartment.
  • Does not permit the use of public IP addresses.
  • Allows only private subnets.

Security Zones help enforce strict security policies across your cloud resources.

8. Summary

  • VCN Security involves multiple strategies: subnets, Security Lists, NSGs, firewall rules, IAM policies, and Security Zones.
  • Security Lists are associated with subnets and act as the main gate guard.
  • Network Security Groups (NSGs) are associated with VNICs and act as dedicated guards for instances.
  • Up to 5 Security Lists can be associated with a subnet.
  • Up to 5 NSGs can be associated with a VNIC.
  • A default security list is created automatically with each VCN.
  • IAM policies control administrative access.
  • Security Zones enforce Oracle security best practices and prohibit public IP addresses.

12. Network Security Groups

A Network Security Group (NSG) is a virtual firewall that consists of a collection of ingress and egress security rules. It is associated with the VNIC of a compute instance or other supported resources (such as load balancers, mount targets, and API gateways). NSGs provide granular, instance-level traffic control and support both stateful and stateless rule types.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define a Network Security Group (NSG) and its purpose.
  • Explain ingress and egress rules and the components that define them.
  • Identify the supported source and destination types for NSG rules.
  • Distinguish between stateful and stateless rules.
  • Describe common use cases for NSGs, including tiered application architectures.
  • Understand how NSGs are associated with VNICs.

1. What Is a Network Security Group (NSG)?

A Network Security Group (NSG) is a virtual firewall that allows you to define:

  • Ingress rules — controls incoming traffic to an instance.
  • Egress rules — controls outgoing traffic from an instance.

Key Points

  • NSGs are associated with VNICs (Virtual Network Interface Cards).
  • NSGs are not limited to compute instances. They also support:
    • Load Balancers
    • Mount Targets
    • API Gateways
    • Other resources with VNICs

To use an NSG, you define:

  1. Security rules (ingress and egress).
  2. VNICs to which the NSG will be associated.

2. Ingress and Egress Rules

Ingress Rule

An ingress rule controls traffic entering an instance. The direction of traffic is from outside to the instance.

Components of an ingress rule:

Component Description
Source Type Where the traffic is coming from.
Source Depends on the source type (CIDR, Service, or NSG).
IP Protocol The protocol used (e.g., RDP, SSH, ICMP).
Source Port Range Optional.
Destination Port Range Optional; auto-populated based on selected protocol.

Supported Source Types:

  1. CIDR Block — e.g., 0.0.0.0/0
  2. Service — e.g., Object Storage service
  3. NSG — Another Network Security Group

Egress Rule

An egress rule controls traffic leaving an instance. The direction of traffic is from the instance to outside.

Components of an egress rule:

Component Description
Destination Type Where the traffic is going.
Destination Depends on the destination type (CIDR, Service, or NSG).
IP Protocol The protocol used.
Source Port Range Optional.
Destination Port Range Optional.

Supported Destination Types:

  1. CIDR Block
  2. Service
  3. NSG

Applying the NSG

After configuring rules, you associate the NSG with the desired VNICs. This determines which instances the rules apply to.

3. Stateful vs. Stateless Rules

When creating ingress or egress rules, you can specify the rule type as either stateful or stateless.

Rule Type Behavior
Stateful Responses are automatically tracked and allowed. Uses connection tracking.
Stateless Responses are not automatically allowed. You must define separate egress rules to allow responses.

Example

  • You define an ingress rule for destination port 80 with source 0.0.0.0/0.
  • If the rule is stateful, the response traffic is automatically allowed.
  • If the rule is stateless, you must define an egress rule to allow the response.

4. Use Case: Tiered Application Architecture

NSGs are ideal for environments with resources that have different security postures.

Example: Web Tier and App Tier

  • Web Tier: 3 instances
  • App Tier: 2 instances

In this scenario:

  • Create NSG 1 for all web tier instances.
  • Create NSG 2 for all app tier instances.

If the app tier needs to receive traffic from the web tier:

  • In NSG 2 (app tier), set the source type to NSG.
  • Specify NSG 1 (web tier) as the source.

This allows controlled communication between tiers without using CIDR blocks.

5. Summary

  • Network Security Group (NSG) is a virtual firewall associated with VNICs.
  • NSGs contain ingress and egress rules.
  • Supported source/destination types: CIDR, Service, and NSG.
  • Rules can be stateful (responses auto-allowed) or stateless (responses require separate rules).
  • NSGs support compute instances, load balancers, mount targets, API gateways, and more.
  • NSGs are useful for grouping resources with similar security postures (e.g., web tier, app tier).
  • Communication between tiers can be controlled by referencing NSGs as sources or destinations.

Network Security Groups - part 2

A Network Security Group (NSG) is a virtual firewall that consists of a set of VNICs and a set of security rules (ingress and egress). It allows you to group resources with the same security posture within the same VCN and control traffic to and from those resources using stateful or stateless rules.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define a Network Security Group (NSG) and its components.
  • Explain how NSGs group resources with the same security posture.
  • Identify supported resources for NSGs.
  • Configure ingress and egress rules with CIDR, Service, or NSG source/destination types.
  • Distinguish between stateful and stateless rules with examples.
  • Understand when to use stateless rules.
  • Recognize that a default NSG is not created with a VCN.

1. What Is a Network Security Group (NSG)?

A Network Security Group (NSG) is a virtual firewall that allows you to define ingress and egress rules.

An NSG consists of two main items:

  1. A set of VNICs — the resources to which the NSG is associated.
  2. A set of security rules — including both ingress and egress rules.

Key Characteristics

  • NSGs group resources with the same security posture (e.g., all web tier instances, all app tier instances).
  • All resources associated with an NSG must be in the same VCN.
  • NSGs are associated with VNICs, not subnets.

2. Supported Resources

While NSGs are commonly associated with compute instances, they also support other resources, including:

  • Load Balancers
  • Mount Targets
  • API Gateways
  • Other resources with VNICs

3. NSG Architecture Example

Consider a VCN with:

  • Subnet A — 2 VM instances
  • Subnet B — 1 VM instance

Two NSGs are created:

NSG-A Rules

Direction Source Protocol Destination Port Rule Type
Ingress 0.0.0.0/0 TCP 80 Stateful
Ingress 0.0.0.0/0 TCP 22 Stateful

NSG-B Rules

Direction Source Protocol Destination Port Rule Type
Ingress 0.0.0.0/0 TCP 22 Stateful

Association

  • NSG-A is associated with:
    • Instance 1 in Subnet A
    • Instance 2 in Subnet A
  • NSG-B is associated with:
    • Instance 1 in Subnet B

Outcome

  • Instances associated with NSG-A can receive HTTP (port 80) and SSH (port 22) traffic from the internet.
  • The instance associated with NSG-B can receive SSH (port 22) traffic from the internet.

4. Source and Destination Types

When configuring NSG rules:

Rule Type Field Supported Types
Ingress Source Type CIDR, Service, NSG
Egress Destination Type CIDR, Service, NSG

NSG-to-NSG Communication

  • You can use an NSG as a source (for ingress) or destination (for egress).
  • This allows you to control traffic between different tiers (e.g., web tier to app tier).
  • Condition: Both NSGs must be in the same VCN.

Example: Web Tier to App Tier

  • Create NSG-Web for web tier instances.
  • Create NSG-App for app tier instances.
  • In NSG-App, set the source type to NSG and specify NSG-Web as the source.
  • This allows the app tier to receive traffic from the web tier.

5. Stateful vs. Stateless Rules

Stateful Rules

  • Responses are automatically tracked and allowed.
  • Uses connection tracking.
  • You do not need to create a separate egress rule for response traffic.

Example:

  • Ingress rule allows port 80 from the internet.
  • Response traffic is automatically allowed.

Stateless Rules

  • Responses are not automatically allowed.
  • You must explicitly define an egress rule to allow response traffic.
  • Does not use connection tracking.

Example:

  • Ingress rule allows port 80 from the internet.
  • You must create an egress rule:
    • Destination: 0.0.0.0/0
    • Protocol: TCP
    • Source Port: 80
    • Destination Port: All

When to Use Stateless Rules

  • Recommended for high-volume internet-facing websites.
  • Typical scenario: HTTP and HTTPS traffic.

6. Default NSG vs. Default Security List

  • When you create a VCN, a default security list is automatically created.
  • A default NSG is NOT created when you create a VCN.
  • To use an NSG, you must manually create it and define its security rules.

7. Summary

  • NSG is a virtual firewall consisting of VNICs and security rules.
  • NSGs group resources with the same security posture in the same VCN.
  • Supported resources include compute instances, load balancers, mount targets, and API gateways.
  • Source/destination types: CIDR, Service, and NSG.
  • Stateful rules automatically allow responses; stateless rules require explicit egress rules.
  • Stateless rules are recommended for high-volume HTTP/HTTPS traffic.
  • A default NSG is not created with a VCN; you must create it manually.
  • NSG-to-NSG communication allows tiered traffic control (e.g., web tier to app tier).

13. Security Lists

A Security List is a virtual firewall consisting of a collection of ingress and egress security rules that is associated with a subnet. It is applied to all instances within the subnet and is enforced at the VNIC level. Security Lists provide subnet-level traffic control and support stateful rules.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define a Security List and its purpose.
  • Explain how Security Lists differ from Network Security Groups (NSGs).
  • Describe how Security Lists are associated with subnets and enforced at the VNIC level.
  • Identify the supported source and destination types for Security List rules.
  • Understand how multiple Security Lists and NSGs work together.
  • Apply the guiding principle for allowing traffic.

1. What Is a Security List?

A Security List is a common set of firewall rules — a collection of both ingress and egress security rules.

Key Characteristics

  • Associated with a subnet.
  • Applied to all instances within the subnet.
  • Enforced at the VNIC level.
  • Controls which traffic is allowed to enter and leave the subnet.

Comparison with Network Security Group (NSG)

Feature Security List Network Security Group (NSG)
Association Subnet VNIC
Scope All instances in the subnet Specific instances (VNICs)
Source/Destination Types CIDR, Service CIDR, Service, NSG
Rule Type Stateful Stateful or Stateless

2. How Security Lists Work

Consider a VCN with three subnets:

  • Subnet A
  • Subnet B
  • Subnet C

A single Security List is created and associated with all three subnets. The Security List contains:

  • One egress rule
  • One ingress rule

Both rules are stateful.

This means:

  • The same set of rules applies to all instances in all three subnets.
  • Traffic entering or leaving any instance in these subnets is controlled by the Security List rules.

3. Combining Security Lists and NSGs

You can use:

  • Security Lists alone
  • Network Security Groups alone
  • Both together

Example

  • A subnet is associated with Security List 1 and Security List 2.
  • A VNIC in that subnet is associated with NSG-A and NSG-B.

Rule Evaluation: The Union Principle

When multiple Security Lists and NSGs are applied:

  • The effective rules are the union of all rules from:
    • All Security Lists associated with the subnet.
    • All NSGs associated with the VNIC.

Guiding Principle

A packet or traffic is allowed only if there is an Allow Rule in either a Security List or a Network Security Group.

If any construct has an Allow rule for the traffic, it is allowed.

4. Source and Destination Types

When configuring Security List rules:

Rule Type Supported Source/Destination Types
Ingress CIDR, Service
Egress CIDR, Service

Key Difference from NSG

  • NSG supports NSG as a source/destination type.
  • Security List does not support Security List or NSG as a source/destination type.

This is a critical distinction between the two constructs.

5. Use Case: Enforcing Uniform Rules

If you want to enforce the same set of ingress and egress rules for all instances in a VCN:

  1. Define the rules in a Security List.
  2. Associate the Security List with all subnets in the VCN.

This ensures that all instances in the VCN are subject to the same security rules.

6. Summary

  • Security List is a virtual firewall associated with a subnet.
  • It is applied to all instances in the subnet and enforced at the VNIC level.
  • Supports stateful ingress and egress rules.
  • Source/destination types: CIDR and Service.
  • Does not support Security List or NSG as a source/destination type.
  • Multiple Security Lists and NSGs result in a union of rules.
  • Traffic is allowed if any Security List or NSG has an Allow rule.
  • Use Security Lists to enforce uniform rules across all instances in a VCN.