Imagine you are building your dream house 🏠. You need walls, rooms, doors, gates, security guards, and roads. Oracle Cloud Infrastructure (OCI) is exactly like that — but in the cloud!
Every app you build on OCI lives inside a private "neighbourhood" called a VCN. The networking pieces we will learn , are the walls, doors, gates, and traffic signs of that neighbourhood.
Tap any card to jump straight to that section. 11 concepts, one complete OCI network. ⏱️ ~18 min read
🌍 The Big Picture — What Is OCI Networking?
Understanding OCI Like a City 🏙️
Before we dive into individual pieces, let's understand the whole picture first. Think of Oracle Cloud like a giant modern city. Oracle built this city and rents plots of land inside it to companies like yours.
When you sign up for OCI and create a VCN (Virtual Cloud Network), you are getting your own private plot of land inside that city. You decide: how to divide your land into rooms (subnets), which gates to install (gateways), what security rules to apply (Security Lists and NSGs), and which roads lead where (Route Tables).
💡 Think of it like: Oracle gives you an empty neighbourhood. Everything inside that neighbourhood — the rooms, the locks, the roads — is yours to design and control!
┌──────────────────────────────────────────────────────────────────────┐
│ OCI REGION (e.g., Mumbai) │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ VCN (Your Private Neighbourhood) │ │
│ │ │ │
│ │ ┌─────────────────────┐ ┌───────────────────────┐ │ │
│ │ │ Public Subnet │ │ Private Subnet │ │ │
│ │ │ (The Front Yard) │ │ (The Bedroom) │ │ │
│ │ │ │ │ │ │ │
│ │ │ Web Server 🖥️ │ │ Database 🗄️ │ │ │
│ │ └─────────────────────┘ └───────────────────────┘ │ │
│ │ │ │
│ │ Route Table | Security List | NSG │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ 🌐 Internet GW 🕵️ NAT GW 🏢 Service GW 🔗 LPG 🌍 DRG │
└──────────────────────────────────────────────────────────────────────┘
Each section below explains one piece of this diagram in depth. By the end, every single box and arrow above will make complete sense! Let's go. 🎯
📦 Section 1: Subnets — Rooms Inside Your House
What Is a Subnet?
You have your plot of land — the VCN. Now think of it as a big house. Inside that house, you build separate rooms. One room is the Guest Room (for visitors from the internet). Another is the Bedroom (for your private database). Another is the Kitchen (for backend services).
In OCI, each room is called a Subnet. A subnet is simply a smaller chunk of IP addresses carved out of the VCN's address space. Every virtual machine (VM), database, or load balancer you create must live inside a subnet — just like every person in a house must be in a room.
💡 What is an IP address? It's like a house number. Every resource in your cloud gets a unique number so messages know exactly where to be delivered. Example: 10.0.1.5 means "building 10, floor 0, room 1, desk 5". This is how computers find each other!
The Two Types of Subnets — This Is Critical!
There are two kinds of subnets, and choosing the right one is the most important security decision you make when designing your network:
-
🌐 Public Subnet
Think of this as your front yard. It faces the public street. Visitors walking by (internet users) can see it and knock on the gate. Resources inside a Public Subnet can be given a public IP address — which means the whole internet can reach them directly.
→ Use for: Web Servers, Load Balancers, Bastion Hosts (jump servers for admin access) -
🔒 Private Subnet
Think of this as your bedroom. It has no windows facing the street. No one from outside can directly knock on the bedroom door — they'd have to go through the guest room first. Resources inside a Private Subnet have no public IP address, so the internet literally cannot reach them directly.
→ Use for: Databases, Application Servers, Cache layers, Internal APIs
10.0.0.0/16) gets sliced into two smaller subnets. Focus on one thing only: the Web Server has a public IP (internet can reach it ✅) and the Database only has a private IP (internet is blocked out ❌). That contrast is the whole lesson.
Your VCN: 10.0.0.0/16 (the whole house — 65,536 addresses available)
│
├── Public Subnet: 10.0.1.0/24 ← The Front Yard
│ Resources here CAN have public IPs
│ └── Web Server IP: 10.0.1.10 (also gets public IP like 152.67.88.50)
│ Anyone on internet → can reach 152.67.88.50 ✅
│
└── Private Subnet: 10.0.2.0/24 ← The Bedroom
Resources here have NO public IPs
└── Database IP: 10.0.2.20 (only private IP — no public IP!)
Internet → CANNOT reach 10.0.2.20 ❌ (good! it's protected!)
Notice how the VCN uses the address space 10.0.0.0/16 and the subnets are smaller slices of it.
The /16 gives you 65,536 addresses. The /24 gives each subnet 256 addresses.
Think of it like: the VCN owns the whole street (10.0.x.x), and each subnet owns one building on that street (10.0.1.x, 10.0.2.x, etc.).
🛠️ How to Create a Subnet in OCI Console
- Step 1: Log in to OCI Console → navigate to Networking in the top menu → click Virtual Cloud Networks
- Step 2: Click on your VCN name to open it
- Step 3: In the left panel, click Subnets → then click Create Subnet
-
Step 4: Fill in the form:
- Name: Give it a meaningful name like
public-web-subnetorprivate-db-subnet - CIDR Block: Enter a range like
10.0.1.0/24— must be inside the VCN's CIDR and not overlap other subnets - Subnet Access: Choose Public Subnet or Private Subnet
- Route Table: Attach the correct Route Table (we will learn what this is in Section 4!)
- Security List: Attach the correct Security List (we learn this next!)
- Name: Give it a meaningful name like
- Step 5: Click Create Subnet — done! ✅
🛡️ Section 2: Security Lists — The Lock on the Room Door
What Is a Security List?
Great — you have rooms (subnets) now! But who is allowed to walk in? And who is allowed to walk out? A Security List answers both questions.
A Security List is a set of firewall rules that is applied to an entire subnet. Think of it like a notice board on the door of your room that lists the rules: "Only guests wearing a blue badge (port 443) may enter. No deliveries after 6pm (block port 25). Everyone inside may freely exit."
Every single resource inside that subnet automatically follows those rules. You cannot give different rules to individual VMs using a Security List — the rules apply equally to everyone in the room. (For that, you need NSGs — coming up in Section 3!)
Ingress vs Egress — Understanding Traffic Direction
Security List rules come in two flavours, based on the direction of the traffic:
-
📥 Ingress Rules — Controls traffic coming INTO your subnet.
Analogy: "Who is allowed to knock on my door and come inside?"
Example: "Allow port 443 from 0.0.0.0/0" means "Let anyone from the internet connect on HTTPS port 443" → your website is reachable ✅ -
📤 Egress Rules — Controls traffic going OUT OF your subnet.
Analogy: "Where am I allowed to go when I leave my room?"
Example: "Allow all protocols to 0.0.0.0/0" means "Let my resources send traffic to anyone" → your server can send responses back to users ✅
Very important: OCI Security Lists use a deny by default policy. If you don't write a rule to ALLOW something, it is automatically BLOCKED. You only write rules for what you WANT to let through!
Incoming traffic knocks at the subnet door...
Internet → Port 443 (HTTPS) → [Ingress Rule: ALLOW port 443] → ✅ Web Server gets it!
Internet → Port 22 (SSH) → [Ingress Rule: DENY port 22 ] → ❌ BLOCKED at the gate!
Internet → Port 3306 (MySQL) → [No matching rule at all ] → ❌ BLOCKED automatically!
Outgoing traffic tries to leave the subnet...
Web Server → Internet → [Egress Rule: ALLOW all ] → ✅ Response reaches user!
A Real-World Security List for a Web Server
Imagine you run an e-commerce website. Customers browse using HTTPS (port 443) and HTTP (port 80). Your admin team connects to the server using SSH (port 22) to fix bugs. The server must send back responses to all of them. The four rules below make all of this work safely — while blocking everything else!
-
Rule 1 — Ingress, TCP, Port 443, Source: 0.0.0.0/0
Translation: "Allow HTTPS traffic from ANYONE on the internet."
Why: Your website customers use HTTPS.0.0.0.0/0means "from the entire internet". ✅ -
Rule 2 — Ingress, TCP, Port 80, Source: 0.0.0.0/0
Translation: "Allow HTTP traffic from anyone."
Why: Some old browsers still use HTTP. Usually you'd redirect to HTTPS, but the port still needs to be open to receive the redirect request. ✅ -
Rule 3 — Ingress, TCP, Port 22, Source: 203.0.113.50/32
Translation: "Allow SSH login ONLY from the specific IP address of our office."
Why:/32means "exactly this one IP address". Only your admin's computer can SSH in — hackers get blocked! ✅ -
Rule 4 — Egress, All Protocols, All Ports, Destination: 0.0.0.0/0
Translation: "Allow all outbound traffic."
Why: Your web server must be able to send responses back to users. Without this rule, all outbound traffic is blocked and your server becomes completely silent! ✅
Notice Rule 3 carefully: instead of 0.0.0.0/0 (the whole internet) we restrict SSH to one specific IP.
The /32 at the end means "exactly this single IP address — not a range".
This tiny change makes your server dramatically safer. 🎯
The Big Limitation of Security Lists
Security Lists work well for simple setups. But they have one significant weakness: every resource in the subnet shares the exact same rules.
Imagine you have a subnet with 5 web server VMs (needing port 443 open) and 5 API server VMs (needing port 8080 open). With a Security List, you must open BOTH ports for the entire subnet — meaning your web servers also have port 8080 open (even though they don't need it), and your API servers also have port 443 open (even though they don't use it). That's unnecessary exposure!
This is exactly why OCI introduced Network Security Groups (NSGs). Let's learn about them now!
🔐 Section 3: Network Security Groups (NSGs) — Smart Badges for Each Resource
What Is an NSG?
Picture a big hotel. Every floor has a master key that unlocks all rooms on that floor — that's like a Security List. But VIP guests get a personal smart badge that unlocks specific doors based on who they are. That personal badge is an NSG (Network Security Group)!
An NSG is a set of firewall rules that you attach to individual resources: a specific VM, a specific database, a specific load balancer. Unlike a Security List (which applies to every resource in a subnet), an NSG only applies to the resources you explicitly attach it to.
Even better: NSG rules can say "allow traffic from another NSG" instead of from an IP address. This means you can write rules like "the App Server can talk to the Database" without knowing or hardcoding any IP addresses. This is incredibly powerful for dynamic cloud environments where IPs change!
Security List vs NSG — The Clear Difference
- 🛡️ Security List → Attached to a whole subnet. Every resource in that subnet shares the same rules. Like a sign on the room door that applies to all occupants. Rules use IP addresses or CIDR ranges as source/destination.
- 🔐 NSG → Attached to individual resources (a specific VM, DB, or Load Balancer). Each resource gets its own unique rules. One resource can be in multiple NSGs at once. Rules can reference other NSGs as source/destination — not just IP addresses!
WITHOUT NSG (Security List only — all resources share same rules):
┌──────────────── Private Subnet ─────────────────────────────────────┐
│ App Server (needs port 8080) │ Database (needs port 5432 ONLY) │
│ │
│ Security List opens BOTH 8080 AND 5432 for the WHOLE subnet. │
│ The database now has port 8080 open even though it should never │
│ receive app traffic directly. Bad design! ❌ │
└─────────────────────────────────────────────────────────────────────┘
WITH NSG (each resource gets its own tailored rules):
App Server → NSG-AppTier → Rules: Allow port 8080 FROM NSG-LoadBalancer only
Database → NSG-DbTier → Rules: Allow port 5432 FROM NSG-AppTier only
The database ONLY accepts connections from the App Server NSG.
Even if a hacker gets inside the subnet, they still cannot reach the database
unless their resource is also in NSG-AppTier! 🔐 ✅
A Complete NSG Design for a 3-Tier Application
Let's design NSGs for a real app: Load Balancer → App Servers → Database. Here's how each layer is protected:
-
NSG-LoadBalancer rules:
- Ingress: Allow port 443 from
0.0.0.0/0— internet users can reach the load balancer via HTTPS - Egress: Allow port 8080 to NSG-AppTier — load balancer can forward requests to app servers
- Ingress: Allow port 443 from
-
NSG-AppTier rules:
- Ingress: Allow port 8080 from NSG-LoadBalancer — ONLY the load balancer can send requests to app servers
- Egress: Allow port 5432 to NSG-DbTier — app servers can query the database
- Egress: Allow all to
0.0.0.0/0— app servers can call external APIs or download updates
-
NSG-DbTier rules:
- Ingress: Allow port 5432 from NSG-AppTier — ONLY app servers can query the database. Period.
- Egress: Allow all outbound — database can respond to app servers and reach Oracle services
The result: even if a hacker somehow gets onto a machine in your VCN, they still cannot reach the database unless that machine has the "NSG-AppTier badge". This is defence in depth — multiple layers of security! 🏆
🛠️ How to Create an NSG
- Step 1: OCI Console → Networking → Virtual Cloud Networks → Your VCN
- Step 2: In the left panel, click Network Security Groups
- Step 3: Click Create Network Security Group
- Step 4: Give it a descriptive name like
nsg-app-serversand click Next - Step 5: Add rules — choose Direction (Ingress/Egress), Protocol (TCP/UDP/ICMP), Port range, Source or Destination
- Step 6: Click Create
- Step 7: When creating a VM or Database, in the Networking section, select this NSG to attach it to that specific resource
🚦 Section 4: Route Tables — Road Signs for Your Network Traffic
What Is a Route Table?
You've built your rooms (subnets) and put locks on the doors (Security Lists, NSGs). Now, when a packet of data leaves a VM in your subnet, how does it know which road to take? Should it go to the internet? To another subnet? To your on-premises office? To Oracle Object Storage?
A Route Table is like a set of road signs posted at every junction in your neighbourhood. Each sign says: "If you are trying to reach destination X — take road Y (gateway)."
Without any route rules, traffic can only move within the VCN itself. To go anywhere else (internet, Oracle services, another VCN, your office), you need Route Table rules. Every subnet is associated with exactly one Route Table.
How Route Rules Work — A Simple Breakdown
Each route rule has exactly two parts:
- Destination CIDR — "I am looking for this address range." (Example:
0.0.0.0/0means "any internet address") - Target (Gateway) — "Go through this gateway to get there." (Example: Internet Gateway, NAT Gateway, DRG, etc.)
Route Table — Public Subnet (for your web servers):
┌──────────────────────────────────┬──────────────────────────────────┐
│ Destination │ Target (Which gateway to use?) │
├──────────────────────────────────┼──────────────────────────────────┤
│ 0.0.0.0/0 (all internet) │ Internet Gateway │
│ 10.0.2.0/24 (private subnet) │ Local (no gateway — it's local) │
└──────────────────────────────────┴──────────────────────────────────┘
Route Table — Private Subnet (for your databases and app servers):
┌──────────────────────────────────┬──────────────────────────────────┐
│ Destination │ Target (Which gateway to use?) │
├──────────────────────────────────┼──────────────────────────────────┤
│ 0.0.0.0/0 (all internet) │ NAT Gateway │
│ All Oracle Services │ Service Gateway │
│ 192.168.0.0/16 (on-premises) │ Dynamic Routing Gateway (DRG) │
│ 10.0.1.0/24 (public subnet) │ Local (no gateway — it's local) │
└──────────────────────────────────┴──────────────────────────────────┘
Notice the key difference: the Public Subnet routes internet traffic through the Internet Gateway (two-way door), while the Private Subnet routes internet traffic through the NAT Gateway (outbound-only door). This protects your private resources while still letting them download updates!
🌐 Section 5: Internet Gateway — The Main Front Door
What Is an Internet Gateway?
Your VCN is completely sealed by default. No traffic comes in, no traffic goes out. This is safe, but useless if you want to run a public website!
An Internet Gateway (IGW) is like installing a big, two-way front gate on your neighbourhood. Once the gate is installed (and you add the road sign pointing to it in the Route Table), traffic can flow in BOTH directions:
- 🌍 → 🏠 Internet visitors can reach your public web server
- 🏠 → 🌍 Your web server can send responses back to visitors
One important rule: the gate only works for resources that have a visible address on the public street — a public IP address. Your private bedroom (private subnet) has no nameplate on the public street, so the gate is useless for it. Only Public Subnet resources with public IPs can use the Internet Gateway!
🌍 THE ENTIRE INTERNET
│
│ Customers request your website (port 443)
│ Your server sends back webpages
▼
┌───── Internet Gateway ──────┐
│ The two-way front gate │
│ One per VCN (you only need │
│ one, no matter how many VMs)│
└─────────────┬───────────────┘
│
┌─────────────▼──────────────────┐
│ Public Subnet │
│ Load Balancer / Web Server │
│ (has a public IP address) │
└─────────────────────────────────┘
│
│ (private traffic — no internet)
▼
┌─────────────────────────────────┐
│ Private Subnet │
│ App Servers / Databases │
│ (NO public IP — internet │
│ cannot reach them!) │
└─────────────────────────────────┘
Everything You Need to Know About Internet Gateway
- ✅ One per VCN — You only ever need one Internet Gateway per VCN, regardless of how many subnets or VMs you have
- ✅ Two-way traffic — Handles both incoming (inbound) requests and outgoing (outbound) responses
- ✅ Free — OCI does not charge for the Internet Gateway itself (you're billed for data egress, not the gateway)
- ✅ Resources need public IPs — Only resources with a public IP address can use the Internet Gateway
- ✅ Requires a Route Table rule —
Destination: 0.0.0.0/0 → Target: Internet Gateway - ❌ Not for private subnets — Private subnet resources should never route through Internet Gateway
- ❌ Not for outbound-only from private resources — That's what NAT Gateway is for!
☐ Step 1: Create Internet Gateway inside your VCN
☐ Step 2: Add route rule in your Public Subnet's Route Table:
0.0.0.0/0 → Internet GatewayMiss either step and nothing works. Both are required!
🕵️ Section 6: NAT Gateway — The One-Way Secret Exit
What Is a NAT Gateway?
Here's a puzzle: 🧩 Your database lives in a private subnet (nice and hidden from the internet). But your database needs to download security patches from the internet. How can the database call OUT to the internet, without letting the internet call BACK IN to the database?
The answer is a NAT Gateway! NAT stands for Network Address Translation. Think of it like a one-way revolving door at a hotel lobby — hotel guests (your private resources) can walk out to the street (internet), but random people from the street cannot walk in through that same revolving door.
Here's the magic in detail: when your database sends a request to the internet (like "download this Linux patch"),
the NAT Gateway steps in front and sends the request using its own public IP address — hiding the database's private IP completely.
The internet sees the NAT Gateway's IP, not 10.0.2.20 (your database's private IP).
When the response comes back, NAT Gateway forwards it to the database.
But no one on the internet can ever initiate a new connection inward through the NAT Gateway. They don't even know your database exists!
🌍 INTERNET
▲
│ ← Outbound: "Please download this patch"
│ → Inbound: "Here is your patch data"
│
│ (Internet sees NAT Gateway's IP, not the DB's IP!)
│
┌────── NAT Gateway ──────────┐
│ Has its own public IP │
│ Translates: private IP │
│ → its own public IP │
│ for outbound requests only │
└─────────────┬───────────────┘
│
┌─────────────▼────────────────────────┐
│ Private Subnet │
│ │
│ Database 🗄️ (IP: 10.0.2.20) │
│ App Server 🖥️ (IP: 10.0.2.21) │
│ │
│ ✅ CAN send outbound (e.g., updates) │
│ ❌ Internet CANNOT reach them! │
└──────────────────────────────────────┘
Internet Gateway vs NAT Gateway — Crystal Clear Comparison
This is one of the most confusing points for beginners. Here is the definitive explanation:
-
🌐 Internet Gateway
- Which subnet uses it? → Public Subnets
- Traffic direction? → BOTH ways (inbound AND outbound)
- Can internet initiate connections to my resources? → YES (that's the point — web servers need this!)
- Do my resources need public IPs? → YES
- Example: A web server that users browse to
-
🕵️ NAT Gateway
- Which subnet uses it? → Private Subnets
- Traffic direction? → Outbound ONLY
- Can internet initiate connections to my resources? → NO (they're hidden!)
- Do my resources need public IPs? → NO (NAT GW uses its own public IP)
- Example: A database that needs to download OS security patches
🏢 Section 7: Service Gateway — The Private Oracle Tunnel
What Is a Service Gateway?
Your application is running inside OCI and needs to store backup files in Oracle Object Storage. Or it needs to write logs to OCI Logging. Or it needs to pull a Docker image from OCI Container Registry.
You have two options to reach Oracle's own services from your VCN:
- Option A (Bad): Route the traffic through the public internet via NAT Gateway. This is slow (traffic goes out to the internet and comes back in), costs money for data transfer, and sends Oracle-to-Oracle traffic through the public internet unnecessarily.
- Option B (Correct): Use a Service Gateway! This creates a private, direct tunnel from your VCN straight to Oracle's services, without leaving Oracle's private network backbone at all. Like having a secret corridor from your building directly to the Oracle office next door — no need to go outside!
WITHOUT Service Gateway — the expensive, slow, risky path:
Private VM → NAT Gateway → 🌍 Public Internet → Oracle Object Storage
(Costs money for data egress. Slow. Traffic exposed to public internet.) ❌
WITH Service Gateway — the fast, free, private path:
Private VM → Service Gateway → Oracle Object Storage directly
(Free within the same OCI region. Fast. Never leaves Oracle's network.) ✅
Which Oracle Services Can You Reach Through Service Gateway?
The Service Gateway covers essentially all OCI services, including:
- 📦 Object Storage — Store and retrieve files, images, ML training data, backups
- 🗄️ Autonomous Database — Fully managed Oracle database (ADB-S, ADB-D)
- 📊 OCI Monitoring and Logging — Send metrics and logs without internet
- 🐳 OCI Container Registry (OCIR) — Pull Docker container images privately
- 🔐 OCI Vault — Access encryption keys and secrets without internet exposure
- ⚡ OCI Functions — Trigger serverless functions from your VCN
- And practically all other OCI regional services!
The Three Big Benefits You Get Immediately
- 🚀 Faster performance — Traffic travels on Oracle's private backbone network, not the public internet. No ISP hops, no public routing — significantly lower latency for your Oracle service calls.
- 💰 Free data transfer within the same region — Data moving through a Service Gateway to Oracle services in the same region incurs NO egress charges. If you process 10TB of data between your VMs and Object Storage per month using Service Gateway — that's completely free! Via NAT Gateway + internet, you'd be paying for every GB. This saving adds up fast.
- 🔒 More secure — Your data never touches the public internet. There's no risk of interception by third parties between you and Oracle's services. For financial data, healthcare records, or any sensitive information, this matters enormously.
🔗 Section 8: Local Peering Gateway (LPG) — Bridge Between Two Neighbourhoods
What Is a Local Peering Gateway?
As your company grows, you'll often end up with multiple separate VCNs in the same OCI region. Maybe you have one VCN for your Development team and another for your Finance team. They need to share data — but you absolutely don't want that traffic going over the public internet!
A Local Peering Gateway (LPG) is like building a private road between two separate neighbourhoods. The road connects them directly — no public streets involved, no traffic from outsiders, completely private. VCN-A and VCN-B can talk to each other using their private IP addresses, and all traffic stays entirely on Oracle's internal network.
OCI Region: Mumbai
┌─────────────────────────────────┐ ┌────────────────────────────────────┐
│ VCN-A (Dev Team) │ │ VCN-B (Finance Team) │
│ CIDR: 10.0.0.0/16 │ │ CIDR: 172.16.0.0/16 │
│ │ │ │
│ Dev App Server: 10.0.1.10 │◄──LPG──►│ Finance Database: 172.16.1.20 │
│ │ private │ │
│ This server can query the │ road │ This DB only accepts connections │
│ Finance DB privately! ✅ │ │ from trusted VCN-A resources ✅ │
└─────────────────────────────────┘ └────────────────────────────────────┘
Traffic stays entirely on Oracle's private network — never touches public internet! 🔒
Setting Up an LPG — Step by Step
Think of setting up an LPG like two neighbours agreeing to build a connecting gate between their gardens. Both neighbours must build their side of the gate. Both must unlock it. Then traffic can flow!
- Step 1: Go to VCN-A in OCI Console → Create a Local Peering Gateway called
lpg-to-vcn-b - Step 2: Go to VCN-B in OCI Console → Create a Local Peering Gateway called
lpg-to-vcn-a - Step 3: From VCN-A's LPG, click "Peer This Gateway" and paste in the OCID (unique identifier) of VCN-B's LPG — this establishes the peering connection
-
Step 4: Update Route Tables in both VCNs so they know the road to each other:
- VCN-A Route Table: Add rule —
Destination: 172.16.0.0/16 → Target: lpg-to-vcn-b - VCN-B Route Table: Add rule —
Destination: 10.0.0.0/16 → Target: lpg-to-vcn-a
- VCN-A Route Table: Add rule —
- Step 5: Update Security Lists or NSGs in both VCNs to allow traffic on the specific ports needed across the peering connection
This is the most common LPG setup failure. If VCN-A uses
10.0.0.0/16 and VCN-B also uses 10.0.0.0/16,
OCI cannot route traffic correctly — both VCNs have the same addresses and OCI doesn't know which one you mean!
The fix: Plan your IP ranges BEFORE creating any VCNs. Use a simple rule:
VCN-A: 10.0.0.0/16, VCN-B: 172.16.0.0/16, On-Premises: 192.168.0.0/16
No overlap = no problems. Write this down before you build anything!
🌍 Section 9: Dynamic Routing Gateway (DRG) — The Superhighway Hub
What Is a DRG?
You've now mastered everything inside OCI. But what about the bigger picture? What if your company has a physical data center (real servers in a building) that needs to talk to OCI? Or what if you need your Mumbai VCN and your London VCN to communicate privately? Or what if you need a multi-cloud setup connecting OCI to AWS?
This is the job of the Dynamic Routing Gateway (DRG). Think of it as a massive highway interchange — the kind where motorways from 5 different cities all meet at one central junction, and traffic can flow between any of them through that single hub.
You attach your VCN to the DRG. Then the DRG becomes the central routing brain that manages connections to the outside world: your office, other OCI regions, other clouds. Everything routes through the DRG!
┌────────────────────────────────────────────┐
│ DRG (The Central Highway Hub) │
└──────┬────────────────┬────────────┬───────┘
│ │ │
┌────────────┘ ┌───────────┘ ┌────────┘
▼ ▼ ▼
┌──────────────────┐ ┌─────────────┐ ┌──────────────────────┐
│ Your VCN │ │ Other VCN │ │ Company Office │
│ (Mumbai) │ │ (London) │ │ Physical Servers │
│ │ │ DR Site │ │ (via VPN or │
│ Main workload │ │ Failover │ │ FastConnect) │
└──────────────────┘ └─────────────┘ └──────────────────────┘
What Can DRG Connect To ?
OCI DRG v2 (the current version) supports four major connection types:
-
🔐 IPSec VPN (Site-to-Site VPN)
Creates an encrypted tunnel over the public internet between your office and OCI. Imagine a completely opaque pipe going through a busy street — people on the street can see the pipe, but they cannot see what's flowing inside (all data is encrypted end-to-end).
Your office router connects to OCI's VPN endpoint. Traffic between your office and OCI flows through this encrypted tunnel.
Best for: Smaller offices, quick initial setup, budget-friendly, testing hybrid connectivity.
Limitation: Speed depends on your internet connection quality. Shared with internet traffic. -
⚡ FastConnect (Dedicated Private Line)
A physical, dedicated fiber optic connection from your office building (or data center) straight to Oracle's network. Think of it as Oracle building your company its own private road — no shared traffic, no internet involvement whatsoever.
Best for: Large enterprises, banks, hospitals — any company needing guaranteed high bandwidth, ultra-low latency, and maximum privacy.
Available in: 1 Gbps and 10 Gbps options. Consistent, predictable performance. -
🔗 Remote Peering Connections (VCNs in Different Regions)
Connects VCNs that are in different OCI regions privately. Example: Your Mumbai VCN (production) and your London VCN (disaster recovery site) can talk to each other through DRG-to-DRG peering. Traffic stays entirely on Oracle's global backbone — no public internet.
Best for: Multi-region architectures, global applications, disaster recovery setups. -
🔁 Transit Routing — Many VCNs Through One DRG
This is the most powerful feature of DRG v2. Attach multiple VCNs to a single DRG, and they can ALL communicate with each other through the DRG as the central router. No need to create individual LPGs between every pair of VCNs.
Example: 5 VCNs all attached to one DRG. Any VCN can talk to any other VCN through the DRG. That's 1 DRG doing the work of potentially 10 separate LPGs — much simpler to manage!
Best for: Organisations with many VCNs. Enterprise-scale architectures.
The Hub-and-Spoke Model — The Gold Standard Architecture
As organisations grow on OCI, they often end up with many VCNs: one for Dev, one for Prod, one for Security, one for Shared Services, one for Analytics, etc. The smartest way to organise all of this is the Hub-and-Spoke architecture using DRG.
Imagine a bicycle wheel 🚲: The hub is a central VCN connected to the DRG, containing shared services: firewalls, centralised DNS, logging, bastion hosts. Each team or workload VCN is a spoke that connects to the hub through the DRG. ALL traffic between spokes flows through the hub, where it can be inspected and controlled centrally.
┌──────────────────────────┐
│ HUB VCN │
│ (Shared Services) │
│ Centralised Firewall │
│ DNS / Bastion / Logging│
└────────────┬─────────────┘
│
┌───▼───┐
│ DRG │ ← Central Router for Everything
└───┬───┘
┌──────────────────────┼──────────────────────┐
│ │ │
┌────────▼────────┐ ┌──────────▼──────┐ ┌────────────▼──────┐
│ Spoke VCN │ │ Spoke VCN │ │ On-Premises │
│ (Dev Team) │ │ (Production) │ │ Data Center │
│ 10.1.0.0/16 │ │ 10.2.0.0/16 │ │ 192.168.0.0/16 │
└─────────────────┘ └─────────────────┘ └───────────────────┘
All traffic between spokes passes through Hub VCN.
Centralised security inspection, logging, and control. ✅
Adding a new team's VCN? Just attach it to DRG — done! ✅
The hub-and-spoke model with DRG v2 has become the standard enterprise architecture pattern on OCI. It scales to dozens of VCNs while keeping your network manageable and secure.
🏗️ Section 10: The Complete Picture — All Concepts Working Together
Building a Real E-Commerce Application on OCI
Now let's see ALL ten concepts working together in one complete, real architecture. Imagine you are launching an online shopping app. You need: a Load Balancer to receive customer traffic, App Servers to process orders, a Database to store customer data, Oracle Object Storage for product images, and a connection to your physical warehouse management system.
🌍 THE INTERNET
│
Customers visit your shop
│
┌───────────▼───────────┐
│ Internet Gateway │
│ (two-way front door) │
└───────────┬───────────┘
│
┌───────────────────────────▼───────────────────────────────────────┐
│ VCN: 10.0.0.0/16 │
│ │
│ ┌──────────────── Public Subnet: 10.0.1.0/24 ───────────────┐ │
│ │ Route Table: 0.0.0.0/0 → Internet Gateway │ │
│ │ NSG-LB: Allow port 443 inbound from 0.0.0.0/0 │ │
│ │ │ │
│ │ 🖥️ Load Balancer (has public IP) │ │
│ └──────────────────────────┬────────────────────────────────┘ │
│ │ (forwards to port 8080) │
│ ┌──────────────── Private Subnet A: 10.0.2.0/24 ────────────┐ │
│ │ Route Table: 0.0.0.0/0 → NAT Gateway │ │
│ │ All OCI Services → Service Gateway │ │
│ │ NSG-App: Allow port 8080 from NSG-LB only │ │
│ │ │ │
│ │ 🖥️ App Server 1 (10.0.2.10) 🖥️ App Server 2 (10.0.2.11)│ │
│ └──────────────────────────┬────────────────────────────────┘ │
│ │ (queries database on port 5432) │
│ ┌──────────────── Private Subnet B: 10.0.3.0/24 ────────────┐ │
│ │ Route Table: All OCI Services → Service Gateway │ │
│ │ NSG-DB: Allow port 5432 from NSG-App ONLY │ │
│ │ │ │
│ │ 🗄️ MySQL Database (10.0.3.10) │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
│ ┌───────────────┐ ┌───────────────────┐ ┌──────────────┐ │
│ │ NAT Gateway │ │ Service Gateway │ │ DRG │ │
│ └───────┬───────┘ └────────┬──────────┘ └──────┬───────┘ │
└──────────┼────────────────────┼─────────────────────┼───────────┘
│ │ │
▼ ▼ ▼
🌍 Internet 🏢 Oracle Object 🏗️ Warehouse Office
(OS patches, Storage (Inventory System via
Docker images) (Product images, IPSec VPN — private
Order backups) and encrypted)
Let's Follow a Customer's Order Request — Step by Step! 🛒
A customer clicks "Buy Now" on your website. Here's the complete journey:
- Step 1 — Internet Gateway: The customer's browser sends an HTTPS request to your load balancer's public IP. The request enters through the Internet Gateway (the front door).
- Step 2 — NSG-LB check: The NSG-LB rule asks: "Is this port 443 from the internet? Yes." → Request is allowed through ✅
- Step 3 — Load Balancer: The Load Balancer distributes the request to one of the healthy App Servers on port 8080.
- Step 4 — NSG-App check: The NSG-App rule asks: "Is this coming from a resource with the NSG-LB badge? Yes." → Allowed ✅
- Step 5 — App Server processing: The App Server processes the order and needs to check inventory — it queries the database on port 5432.
- Step 6 — NSG-DB check: The NSG-DB rule asks: "Is this coming from a resource with the NSG-App badge? Yes." → Allowed ✅
- Step 7 — Database: The database retrieves inventory data and sends it back to the App Server.
- Step 8 — Service Gateway: The App Server saves the order receipt image to Oracle Object Storage — via the Service Gateway. Fast, free, never touches public internet. ✅
- Step 9 — DRG + VPN: The App Server sends the order details to the Warehouse Management System in your physical office — through the DRG and the encrypted IPSec VPN tunnel. Private and secure. ✅
- Step 10 — Response: The "Order Confirmed!" page travels back through App Server → Load Balancer → Internet Gateway → Customer's browser. 🎉
Every single component we learned plays its exact role in this journey. This is how real, production-grade OCI architectures work!
🚨 Common Beginner Mistakes to Avoid
After teaching hundreds of beginners, here are the mistakes that come up again and again. Study these — each one represents real pain you can avoid!
You create an Internet Gateway but your server can't reach the internet. Confused? The fix: Go to your subnet's Route Table and add:
Destination: 0.0.0.0/0 → Target: Internet Gateway.
Remember: a gateway is just a door. The Route Table is the road sign telling traffic to use that door.
Both must exist!
Within minutes of launching a server with port 22 open to the whole internet, automated attack bots will find it and try thousands of username/password combinations per second. The fix: Restrict SSH to your specific office IP (e.g.,
203.0.113.50/32).
Even better: use OCI Bastion Service — it creates temporary, audited access without any open ports at all!
It's tempting to put everything in one public subnet for simplicity. A database in a public subnet with a public IP is a disaster waiting to happen. The fix: Always use separate public and private subnets. Web servers and load balancers go in Public Subnets. Databases and app servers go in Private Subnets. Always.
You try to set up an LPG between two VCNs and it fails because both use
10.0.0.0/16.
The fix: Plan your entire IP address scheme BEFORE creating your first VCN.
Draw a table: VCN-A → 10.0.0.0/16, VCN-B → 172.16.0.0/16, On-premises → 192.168.0.0/16.
Once VCNs are created with the wrong ranges, fixing it often requires rebuilding from scratch!
You haven't set up a Service Gateway, so all outbound traffic (including calls to Object Storage) goes through NAT Gateway and the public internet. The fix: Create a Service Gateway, add the route rule in your Private Subnet's Route Table, and immediately start getting: faster speed, zero data transfer cost, and higher security.
You carefully set up all your Ingress rules but forget Egress. Your server can receive requests — but can't send responses back! The fix: Add a broad egress rule as a default:
All Protocols → All Ports → Destination: 0.0.0.0/0.
Unless you have a very specific reason to restrict outbound traffic (like a high-security environment), allow all egress.
📝 Quick Cheat Sheet — Everything at a Glance
All 10 OCI networking concepts summarised:
- 🏡 VCN → Your private city in OCI. All resources live inside it. Always the first thing to create.
- 📦 Subnet → Rooms inside the VCN. Public = front yard (internet-facing). Private = bedroom (hidden). Divide by security level!
- 🛡️ Security List → Firewall rules for the entire subnet. All resources in the subnet share the same rules. Good for broad defaults. Deny by default.
- 🔐 NSG → Smart firewall rules for individual resources. Can reference other NSGs as source/destination. The preferred approach in production.
- 🚦 Route Table → Road signs for traffic. Tells packets "to reach X, go through gateway Y". Every subnet needs one. Must be updated when you add a gateway!
- 🌐 Internet Gateway → Two-way front door. Internet can reach your Public Subnet resources (inbound AND outbound). One per VCN. Free.
- 🕵️ NAT Gateway → One-way exit for Private Subnets. Your resources can call the internet; internet CANNOT initiate connections back in. Use for OS patches, Docker pulls, external APIs.
- 🏢 Service Gateway → Private shortcut to Oracle services. Faster, free data transfer within region, never touches public internet. Always use this for Oracle services!
- 🔗 LPG → Private bridge between two VCNs in the same OCI region. No internet. Requires non-overlapping CIDRs and Route Table rules on both sides.
- 🌍 DRG → The superhighway hub. Connects VCN to on-premises (via VPN or FastConnect), other OCI regions (Remote Peering), and multiple VCNs (transit routing). Foundation of enterprise hybrid cloud.
❓ Frequently Asked Questions
Written for engineers who already know the basics — the kind of questions that come up in a real design-review meeting.
Q: Security Lists and NSGs are both "stateful" — what does that actually mean for how I write my rules?
Stateful means OCI automatically tracks an established connection and allows the matching return traffic, even if you didn't write an explicit rule for it. If a client connects inbound on port 443, the response traffic going back out doesn't need a separate egress rule to match it — it's recognised as part of the same session. This is why the article's egress rule for the web server (allow all outbound) is about new outbound connections your server initiates, not about replies to inbound requests.
Q: Can one VNIC belong to multiple NSGs at the same time, and how do conflicting rules get resolved?
Yes — a single VM's VNIC can be attached to more than one NSG simultaneously (OCI documents a maximum per VNIC, so check current service limits before designing around it). When multiple NSGs are attached, OCI takes the union of all their rules — if ANY attached NSG allows the traffic, it's allowed. There's no "deny wins" conflict resolution the way some other firewall systems work, so avoid assuming one NSG can override another's allow rule.
Q: In a hub-and-spoke DRG design, how do I actually stop two spoke VCNs from talking directly to each other and bypassing the hub?
This is controlled through DRG route tables (a separate concept from VCN route tables), using route distributions and import/export rules per attachment. By default, DRG v2 can propagate routes between all attachments, so isolation isn't automatic — you deliberately configure the DRG's route table so each spoke only learns a route to the hub, not to other spokes. This is a common review point in enterprise landing-zone designs, so it's worth validating against Oracle's current DRG route table documentation before go-live.
Q: We're migrating from a flat Security-List-only design to NSG-based microsegmentation. What's the safest rollout approach?
Run them in parallel rather than cutting over in one step. Since Security Lists and NSGs are additive (traffic is allowed if either permits it), you can attach the new, tighter NSGs to resources while the existing Security List rules are still active, verify application behaviour and logs show no unexpected drops, and only then progressively tighten or remove the broader Security List rules. This avoids an outage caused by an incomplete NSG rule set going live before it's fully tested.
Q: Does Service Gateway traffic ever incur cross-region egress costs, or is it always free?
It's free specifically for traffic to OCI services within the same region as your VCN. If your application calls an OCI service endpoint in a different region, that traffic does not qualify for the same-region Service Gateway benefit and standard data transfer pricing can apply. This is a subtle point worth flagging in cost-review discussions for multi-region architectures — always confirm current pricing on Oracle's official cost pages for your specific scenario.
Q: Can a Local Peering Gateway connect VCNs that live in different tenancies, or is it strictly intra-tenancy?
LPG is primarily designed for VCNs within the same region — cross-tenancy peering support and the exact IAM policy requirements have evolved over time, so this is one area where it's worth verifying against Oracle's current networking documentation rather than assuming based on older guidance. If cross-tenancy or cross-region connectivity is a hard requirement, a Remote Peering Connection through the DRG is generally the more future-proof pattern to design around.
Q: If a NAT Gateway hides my private IP behind its own public IP, how do I attribute outbound traffic back to a specific instance for security auditing?
Address translation at the NAT Gateway obscures the source IP from the destination's point of view, but OCI's VCN Flow Logs capture the original private IP, port, and instance-level metadata for each flow before translation happens. For audit and forensic purposes, correlate flow logs (or VCN-level network visibility tooling) rather than relying on the external-facing NAT IP alone — the NAT IP alone won't tell you which of your ten app servers made a given request.
Q: For a regulated workload (say, PCI-DSS or a banking client), is FastConnect mandatory, or is IPSec VPN over the DRG considered acceptable?
IPSec VPN is encrypted end-to-end and is commonly accepted for regulated workloads precisely because it's a well-understood, auditable encryption standard — the "public internet" concern is mitigated by the encryption itself, not eliminated by avoiding the internet. FastConnect is chosen more for bandwidth guarantees, latency consistency, and reduced dependency on public internet reliability than for encryption per se (FastConnect traffic itself isn't automatically encrypted unless you layer IPSec on top of it). The right choice is usually driven by your specific compliance framework and SLA requirements — worth a direct conversation with your compliance and network architecture teams rather than a one-size-fits-all answer.
Comments
Post a Comment