OCI Networking 101: A Deep Dive into Controlling VM Traffic
OCI Networking 101: A Deep Dive into Controlling VM Traffic

OCI Networking 101: A Deep Dive into Controlling VM Traffic

So you've decided to explore Oracle Cloud Infrastructure (OCI) and have launched your first "Compute Instance"—OCI's term for a Virtual Machine (VM). It's up and running, but how do you control who can access it? By default, a new VM is a locked-down box. The real power of cloud computing comes from precisely managing the network traffic that can get in and out. This guide will take you on a deep dive into the foundational components of OCI networking, showing you how to build a secure and efficient network for your cloud resources.

The Foundation: Your Virtual Cloud Network (VCN)

Before you can even think about your VM, you must first understand the Virtual Cloud Network (VCN). Think of a VCN as your own private, fenced-off data center in the cloud. It's a logically isolated section of the OCI cloud where you can launch your resources. Nothing can get into or out of your VCN unless you explicitly create a secure gate for it. Within your VCN, you create different "rooms" called subnets. For example:

  • A Public Subnet: This "room" has a door to the outside world via an "Internet Gateway." This is where you would place resources that need to be directly reachable from the internet, like a web server.
  • A Private Subnet: This "room" has no direct door to the outside. It's where you place your secure backend resources, like databases, that should only be accessible from within your VCN.

The Guards at the Gate: Security Lists vs. Network Security Groups (NSGs)

OCI gives you two primary tools to act as virtual firewalls for your VMs. Understanding the difference is critical.

1. Security Lists (The Room Guard)

A Security List acts as a firewall for an entire subnet. The rules you define in a Security List are applied to every single VM inside that "room" (subnet). This is a good approach for applying broad, general rules to a group of similar resources. For example, you might create a rule in the public subnet's Security List that allows all web traffic on ports 80 and 443.

2. Network Security Groups (The Personal Bodyguard)

A Network Security Group (NSG) is a more modern and granular firewall that applies directly to a VM's virtual network card (VNIC), regardless of which subnet it's in. A VM can be a member of up to five different NSGs, allowing you to create very specific, layered security policies. This is the recommended approach for modern applications, as the security rules are tied to the application's role, not just its location.

Key Difference: Security Lists are for subnets. NSGs are for specific VMs. You can use both together, and OCI will evaluate the combination of all rules that apply.

A Practical Guide: Creating Your First Firewall Rules

Let's imagine you have a web server VM in your public subnet. You need to allow two things: web traffic from anywhere in the world and SSH access for yourself to manage the server.

The best-practice way to do this is with an NSG:

  1. Navigate to your VCN's details page and click on "Network Security Groups."
  2. Click "Create Network Security Group" and give it a name, like `WebServer-NSG`.
  3. Once created, click on the NSG's name and select "Add Rules." You will add two Ingress (inbound) rules:
    • Rule 1 (HTTPS): Set Source to `0.0.0.0/0` (meaning "any IP address"), Protocol to `TCP`, and Destination Port to `443`.
    • Rule 2 (SSH): Set Source to `YOUR_HOME_IP/32` (replace with your actual IP address for security), Protocol to `TCP`, and Destination Port to `22`.
  4. Now, navigate to your Compute Instance, click on its attached VNIC, and associate it with the `WebServer-NSG` you just created.

That's it. Your VM will now accept traffic only on those specific ports from those specific sources. All other traffic will be dropped.

Conclusion: Building a Secure Foundation

Controlling traffic in OCI is a matter of layered security. The VCN provides the isolated network, and Security Lists and Network Security Groups act as the vigilant guards that enforce your access policies. By always starting with a "deny all" security posture and only opening the specific ports you need—preferably using granular NSGs—you can build a secure, robust, and professional-grade cloud environment for any application.