OCINetworkingintermediate

OCI VCN Networking Deep Dive

Design OCI virtual cloud networks with subnets, security lists, NSGs, gateways, and FastConnect.

CloudToolStack Team25 min readPublished Mar 14, 2026

Prerequisites

Understanding of IP addressing and CIDR notation
OCI account with networking permissions

Networking in Oracle Cloud Infrastructure

OCI's networking architecture is one of its strongest differentiators. Unlike first-generation cloud providers that use overlay networks on shared physical infrastructure, OCI usesoff-box network virtualization. This means network processing happens on dedicated SmartNICs (custom hardware) rather than the host CPU, delivering consistent bandwidth and latency that is not affected by noisy neighbors. Every bare-metal and VM instance gets predictable, non-oversubscribed network performance.

The Virtual Cloud Network (VCN) is the foundation of OCI networking. A VCN is a software-defined network that you configure and control, providing isolation, segmentation, and connectivity options similar to a traditional on-premises network. This guide covers VCN architecture in depth, including subnets, gateways, security rules, route tables, DRG (Dynamic Routing Gateway) for inter-VCN and hybrid connectivity, and FastConnect for dedicated private connections.

OCI Flat Network Architecture

OCI's flat network provides consistent 1-microsecond latency between instances in the same VCN, regardless of which physical host they run on. This is a significant advantage for latency-sensitive workloads like databases, high-frequency trading, and HPC clusters. Combined with RDMA (Remote Direct Memory Access) support on certain shapes, OCI networking can match or exceed on-premises performance.

VCN Architecture

A VCN exists within a single region but spans all Availability Domains (ADs) in that region. When you create a VCN, you assign it a CIDR block (or multiple CIDR blocks) that defines the IP address range. OCI supports VCN CIDR blocks from /16 to /30, and you can add up to five CIDR blocks to a single VCN.

Each VCN comes with default resources: a default route table, a default security list, and a default set of DHCP options. You can use the defaults or create custom versions for different subnets.

bash

# Create a VCN with a primary CIDR block
oci network vcn create \
  --compartment-id $C \
  --cidr-blocks '["10.0.0.0/16"]' \
  --display-name "production-vcn" \
  --dns-label "prodvcn"

# Add a secondary CIDR block to an existing VCN
oci network vcn add-cidr \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.1.0.0/16"

# List VCNs in a compartment
oci network vcn list \
  --compartment-id $C \
  --query 'data[].{name:"display-name", cidr:"cidr-blocks", state:"lifecycle-state"}' \
  --output table

# Get VCN details
oci network vcn get \
  --vcn-id <vcn-ocid>

Subnets

Subnets divide a VCN into smaller network segments. Each subnet exists in a single Availability Domain (AD-specific) or spans all ADs in a region (regional). Regional subnets are the recommended approach because they simplify management and provide flexibility in instance placement. Each subnet has its own route table, security lists, and DHCP options.

Subnets can be public (instances can have public IP addresses and be directly reachable from the internet via an Internet Gateway) or private(instances have only private IPs and access the internet via a NAT Gateway or not at all).

bash

# Create a public subnet (regional)
oci network subnet create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24" \
  --display-name "public-subnet" \
  --dns-label "pubsub" \
  --prohibit-public-ip-on-vnic false \
  --route-table-id <public-route-table-ocid> \
  --security-list-ids '["<public-security-list-ocid>"]'

# Create a private subnet (regional)
oci network subnet create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.2.0/24" \
  --display-name "private-subnet" \
  --dns-label "privsub" \
  --prohibit-public-ip-on-vnic true \
  --route-table-id <private-route-table-ocid> \
  --security-list-ids '["<private-security-list-ocid>"]'

# Create an AD-specific subnet (less common, use for specific requirements)
oci network subnet create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --availability-domain "AD-1" \
  --cidr-block "10.0.10.0/24" \
  --display-name "ad1-specific-subnet"

# List subnets
oci network subnet list \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --query 'data[].{name:"display-name", cidr:"cidr-block", public:"prohibit-public-ip-on-vnic", ad:"availability-domain"}' \
  --output table

Gateways

Gateways connect your VCN to external networks. OCI provides several gateway types, each serving a specific connectivity purpose. Choosing the right gateway for each traffic flow is critical for security, performance, and cost optimization.

Gateway Types

Gateway	Purpose	Direction	Cost
Internet Gateway (IGW)	Bidirectional internet access for public subnets	Inbound + Outbound	Free (pay for data transfer)
NAT Gateway	Outbound-only internet access for private subnets	Outbound only	Free (pay for data transfer)
Service Gateway (SGW)	Access OCI services without internet traversal	Outbound to OCI services	Free
Dynamic Routing Gateway (DRG)	Connect VCNs, on-premises, and other clouds	Bidirectional	Free (pay for FastConnect/VPN)
Local Peering Gateway (LPG)	Connect two VCNs in the same region	Bidirectional	Free

bash

# Create an Internet Gateway
oci network internet-gateway create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "production-igw" \
  --is-enabled true

# Create a NAT Gateway
oci network nat-gateway create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "production-nat-gw"

# Create a Service Gateway (access Oracle Services Network)
# First, get the service CIDR label
oci network service list \
  --query 'data[].{name:name, cidr:"cidr-block", id:id}' \
  --output table

oci network service-gateway create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "production-sgw" \
  --services '[{"serviceId": "<all-services-ocid>"}]'

# Create a DRG (Dynamic Routing Gateway)
oci network drg create \
  --compartment-id $C \
  --display-name "hub-drg"

# Attach DRG to a VCN
oci network drg-attachment create \
  --drg-id <drg-ocid> \
  --vcn-id <vcn-ocid> \
  --display-name "prod-vcn-attachment"

Service Gateway for Free Data Transfer

The Service Gateway allows your private subnet resources to access OCI services (like Object Storage, Autonomous Database, and Container Registry) without going through the internet or NAT Gateway. This is not only more secure but also free: data transfer through the Service Gateway does not incur egress charges. Always use a Service Gateway for OCI service access from private subnets.

Route Tables

Route tables define how traffic flows out of a subnet. Each subnet is associated with one route table, and the route table contains rules that direct traffic to specific gateways based on the destination CIDR. Traffic within the VCN is automatically routed locally and does not need explicit route rules.

bash

# Create a route table for public subnets
oci network route-table create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "public-rt" \
  --route-rules '[{
    "destination": "0.0.0.0/0",
    "destinationType": "CIDR_BLOCK",
    "networkEntityId": "<igw-ocid>"
  }]'

# Create a route table for private subnets
oci network route-table create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "private-rt" \
  --route-rules '[
    {
      "destination": "0.0.0.0/0",
      "destinationType": "CIDR_BLOCK",
      "networkEntityId": "<nat-gw-ocid>"
    },
    {
      "destination": "all-iad-services-in-oracle-services-network",
      "destinationType": "SERVICE_CIDR_BLOCK",
      "networkEntityId": "<sgw-ocid>"
    },
    {
      "destination": "10.1.0.0/16",
      "destinationType": "CIDR_BLOCK",
      "networkEntityId": "<drg-ocid>"
    }
  ]'

# List route rules in a route table
oci network route-table get \
  --rt-id <route-table-ocid> \
  --query 'data."route-rules"[].{destination:destination, type:"destination-type", target:"network-entity-id"}' \
  --output table

Security Lists vs Network Security Groups

OCI provides two mechanisms for controlling network traffic: Security Listsand Network Security Groups (NSGs). Security Lists are associated with subnets and apply to all VNICs in the subnet. NSGs are associated with individual VNICs (network interfaces) and provide more granular control. You can use both simultaneously; traffic must be allowed by both the security list and the NSG to pass.

Security Lists vs NSGs Comparison

Feature	Security Lists	Network Security Groups
Scope	Subnet level (all VNICs)	VNIC level (individual resources)
Attachment	Associated with subnets	Associated with VNICs
Source/Destination	CIDR blocks, service CIDRs	CIDR blocks, service CIDRs, other NSGs
Limit	5 per subnet, 200 rules each	5 per VNIC, 120 rules each
Recommended for	Broad subnet-level rules	Application-specific micro-segmentation

bash

# Create a Security List
oci network security-list create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "web-tier-sl" \
  --ingress-security-rules '[
    {
      "source": "0.0.0.0/0",
      "protocol": "6",
      "tcpOptions": {"destinationPortRange": {"min": 443, "max": 443}},
      "description": "Allow HTTPS from anywhere"
    },
    {
      "source": "10.0.0.0/16",
      "protocol": "6",
      "tcpOptions": {"destinationPortRange": {"min": 22, "max": 22}},
      "description": "Allow SSH from VCN"
    }
  ]' \
  --egress-security-rules '[
    {
      "destination": "0.0.0.0/0",
      "protocol": "all",
      "description": "Allow all outbound"
    }
  ]'

# Create a Network Security Group
oci network nsg create \
  --compartment-id $C \
  --vcn-id <vcn-ocid> \
  --display-name "web-server-nsg"

# Add ingress rules to the NSG
oci network nsg rules add \
  --nsg-id <nsg-ocid> \
  --security-rules '[
    {
      "direction": "INGRESS",
      "protocol": "6",
      "source": "0.0.0.0/0",
      "sourceType": "CIDR_BLOCK",
      "tcpOptions": {"destinationPortRange": {"min": 80, "max": 80}},
      "description": "Allow HTTP"
    },
    {
      "direction": "INGRESS",
      "protocol": "6",
      "source": "0.0.0.0/0",
      "sourceType": "CIDR_BLOCK",
      "tcpOptions": {"destinationPortRange": {"min": 443, "max": 443}},
      "description": "Allow HTTPS"
    },
    {
      "direction": "INGRESS",
      "protocol": "6",
      "source": "<app-nsg-ocid>",
      "sourceType": "NETWORK_SECURITY_GROUP",
      "tcpOptions": {"destinationPortRange": {"min": 8080, "max": 8080}},
      "description": "Allow app traffic from app-tier NSG"
    },
    {
      "direction": "EGRESS",
      "protocol": "all",
      "destination": "0.0.0.0/0",
      "destinationType": "CIDR_BLOCK",
      "description": "Allow all outbound"
    }
  ]'

# List NSG rules
oci network nsg rules list \
  --nsg-id <nsg-ocid> \
  --query 'data[].{direction:direction, protocol:protocol, source:source, description:description}' \
  --output table

Default Security List Allows All Egress

The default security list created with every VCN allows all outbound traffic and allows inbound traffic only from within the VCN (ICMP) and SSH from 0.0.0.0/0. Review and tighten these defaults for production workloads. Best practice is to use NSGs for application-specific rules and minimize security list rules to broad baseline controls. Remember that security lists are stateful by default: if you allow inbound traffic, the corresponding reply traffic is automatically allowed.

VCN Peering and DRG

When you need to connect multiple VCNs, OCI provides two options: Local Peering Gateways (LPGs) for same-region peering and the Dynamic Routing Gateway (DRG) for cross-region peering, VPN, and FastConnect connectivity. The DRG v2 is a hub-and-spoke router that can connect multiple VCNs, on-premises networks, and other cloud providers through a single gateway.

bash

# Hub-and-Spoke architecture with DRG v2
# Create the hub DRG
DRG_ID=$(oci network drg create \
  --compartment-id $C \
  --display-name "hub-drg" \
  --query 'data.id' --raw-output)

# Attach spoke VCNs to the DRG
oci network drg-attachment create \
  --drg-id $DRG_ID \
  --vcn-id <spoke1-vcn-ocid> \
  --display-name "spoke1-attachment"

oci network drg-attachment create \
  --drg-id $DRG_ID \
  --vcn-id <spoke2-vcn-ocid> \
  --display-name "spoke2-attachment"

# Create an import route distribution for transit routing
oci network drg-route-distribution create \
  --drg-id $DRG_ID \
  --display-name "import-all-routes" \
  --distribution-type "IMPORT"

# Create a DRG route table
oci network drg-route-table create \
  --drg-id $DRG_ID \
  --display-name "spoke-route-table" \
  --import-drg-route-distribution-id <distribution-ocid>

# List DRG attachments
oci network drg-attachment list \
  --compartment-id $C \
  --drg-id $DRG_ID \
  --query 'data[].{name:"display-name", "vcn-id":"vcn-id", state:"lifecycle-state"}' \
  --output table

FastConnect

FastConnect provides a dedicated, private connection between your on-premises data center and OCI. Unlike a VPN that traverses the public internet, FastConnect offers consistent bandwidth (1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps, or 100 Gbps), lower latency, and higher reliability. FastConnect connects to your DRG, enabling access to all VCNs attached to that DRG.

OCI supports three FastConnect models: partner-based (through providers like Equinix, Megaport, or AT&T), colocation (if you are in the same data center as OCI), and third-party (connect through your own network provider). For most organizations, the partner model is the easiest to set up.

bash

# List available FastConnect providers in a region
oci network fast-connect-provider-service list \
  --compartment-id $C \
  --query 'data[].{name:"provider-name", type:type, "bandwidths":"supported-virtual-circuit-types"}' \
  --output table

# Create a FastConnect virtual circuit (partner model)
oci network virtual-circuit create \
  --compartment-id $C \
  --type "PRIVATE" \
  --display-name "prod-fastconnect" \
  --bandwidth-shape-name "1 Gbps" \
  --gateway-id <drg-ocid> \
  --provider-service-id <provider-ocid> \
  --cross-connect-mappings '[{
    "bgpMd5AuthKey": "your-bgp-key",
    "customerBgpPeeringIp": "169.254.0.2/30",
    "oracleBgpPeeringIp": "169.254.0.1/30",
    "vlan": 100
  }]' \
  --customer-bgp-asn 65000

# Check virtual circuit status
oci network virtual-circuit get \
  --virtual-circuit-id <vc-ocid> \
  --query 'data.{state:"lifecycle-state", "bgp-state":"bgp-session-state", bandwidth:"bandwidth-shape-name"}'

VPN Connect

For organizations that do not need dedicated bandwidth, OCI VPN Connect provides IPSec VPN tunnels over the public internet. Each VPN connection includes two redundant tunnels for high availability. VPN Connect is significantly cheaper than FastConnect and suitable for development environments, backup connectivity, or workloads that can tolerate variable internet latency.

bash

# Create a CPE (Customer Premises Equipment) object
oci network cpe create \
  --compartment-id $C \
  --ip-address "203.0.113.1" \
  --display-name "on-prem-firewall"

# Create an IPSec VPN connection
oci network ip-sec-connection create \
  --compartment-id $C \
  --cpe-id <cpe-ocid> \
  --drg-id <drg-ocid> \
  --static-routes '["192.168.0.0/16"]' \
  --display-name "on-prem-vpn"

# Get IPSec tunnel details (two tunnels per connection)
oci network ip-sec-connection-tunnel list \
  --ipsc-id <ipsec-ocid> \
  --query 'data[].{status:status, "vpn-ip":"vpn-ip", routing:routing, "bgp-state":"bgp-session-info"}' \
  --output table

Use DRG for Hub-and-Spoke Topology

The DRG v2 supports transit routing, enabling a hub-and-spoke architecture where all inter-VCN traffic flows through a central DRG. This simplifies management by centralizing route tables and security controls. Combined with a network firewall appliance in a hub VCN, this pattern enables centralized traffic inspection and logging. This is the recommended architecture for enterprise deployments with multiple VCNs and hybrid connectivity.

DNS in OCI

OCI provides both internal DNS (for VCN-internal name resolution) and a public DNS service for managing domain names. Internal DNS is automatic: every instance in a VCN gets a hostname that resolves to its private IP within the VCN. The public DNS service supports DNSSEC, traffic management policies, and health checks.

bash

# Internal DNS: hostname format
# <hostname>.<subnet-dns-label>.<vcn-dns-label>.oraclevcn.com
# Example: web-server.pubsub.prodvcn.oraclevcn.com

# Create a public DNS zone
oci dns zone create \
  --compartment-id $C \
  --name "example.com" \
  --zone-type "PRIMARY"

# Add DNS records
oci dns record domain patch \
  --zone-name-or-id "example.com" \
  --domain "www.example.com" \
  --items '[{
    "domain": "www.example.com",
    "rdata": "10.0.1.50",
    "rtype": "A",
    "ttl": 300
  }]'

# List DNS records
oci dns record zone get \
  --zone-name-or-id "example.com" \
  --query 'data.items[].{domain:domain, rtype:rtype, rdata:rdata, ttl:ttl}' \
  --output table

Network Architecture Best Practices

Practice	Recommendation
Subnet Design	Use regional subnets. Separate public and private subnets. Size CIDR blocks for growth.
Security	Use NSGs for app-level rules. Minimize security list rules. Never allow 0.0.0.0/0 SSH in production.
Connectivity	Use DRG v2 for hub-and-spoke. Use Service Gateway for OCI service access.
High Availability	Deploy across multiple ADs and fault domains. Use regional subnets for flexibility.
Monitoring	Enable VCN flow logs. Use Network Visualizer for topology views.
Cost	Use Service Gateway (free) instead of NAT Gateway for OCI service traffic.

OCI Security Best Practices OCI Compute Shapes & Instances Terraform on OCI

Key Takeaways

1VCNs support multiple CIDR blocks and subnets can be regional or AD-specific.
2NSGs are preferred over security lists for stateful, resource-level firewall rules.
3OCI provides Internet, NAT, Service, and DRG gateways for different traffic patterns.
4FastConnect provides dedicated private connectivity with 1 Gbps to 100 Gbps options.

Frequently Asked Questions

What is the difference between security lists and NSGs in OCI?

Security lists are applied at the subnet level and affect all resources in the subnet. NSGs (Network Security Groups) are applied to individual VNICs (network interfaces) and offer more granular, resource-level control. Oracle recommends NSGs for most use cases because they are easier to manage and allow security rules to follow the resource rather than the subnet.

How does OCI networking differ from AWS VPC?

OCI VCNs support regional subnets (spanning all ADs in a region) by default, while AWS subnets are AZ-specific. OCI uses Service Gateways for private access to Oracle services (similar to AWS Gateway Endpoints). OCI also has a unique DRG (Dynamic Routing Gateway) that serves as a central hub for VCN peering, VPN, and FastConnect.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.