OCI Networking Series – Part 6: Advanced Security in OCI Networking

Modern cloud architectures demand security that is proactive, identity-aware, and deeply embedded within the network fabric. In Oracle Cloud Infrastructure (OCI), networking security is not limited to simple port restrictions—it spans intelligent firewalls, zero trust access, automated remediation, encryption lifecycle management, and deep traffic inspection.

In this blog, we explore the advanced security controls in OCI Networking, including NSGs vs Security Lists, OCI Network Firewall, WAF, Bastion, Zero Trust, Vault integration, and advanced capabilities like Cloud Guard, Threat Intelligence, and Flow Logs.

1. NSGs vs Security Lists – When to Use Which

Security Lists (SLs)

Security Lists are stateful virtual firewalls applied at the subnet level. All VMs in the subnet receive the same rules. This means each subnet can have different security list and it works at the subnet level. If you open the port 443 in the security list then all the servers or any OCI components can have the incoming traffic on port 443. 

They’re ideal for broad, subnet-wide policies such as:

• Allowing port 22 internally
• Permitting egress to the internet
• Allowing VCN-to-VCN traffic within a private zone

v Use SLs when you need consistent security behavior for all resources in a subnet.

Network Security Groups (NSGs)

NSGs are stateful virtual firewalls attached directly to VNICs. They allow resource-level micro-segmentation and are more flexible than Security Lists. so if you create NSG and open port 1521 in it and attach it to the database then port 1521 will only accessible on the database.

Use NSGs when:

• You need granular control for individual compute, load balancers, databases, etc.
• You want different rules for different resources in the same subnet
• You want application tiers (web, app, DB) isolated without creating multiple subnets

v Use NSGs for fine-grained control and Security Lists only for baseline subnet rules.

2. OCI Network Firewall – Enterprise-Grade Threat Prevention

OCI Network Firewall (powered by Palo Alto Networks) delivers deep packet inspection (DPI), intrusion prevention, URL filtering, malware detection, and SSL inspection capabilities directly inside OCI. But the real power of the Network Firewall comes from where you place it.

Network Firewall in Hub-and-Spoke Architecture

For large deployments, OCI recommends a centralized transit (hub) VCN connected to multiple spoke VCNs through a DRG. The OCI network firewall can reside into the HUB VCN which is attached to the DRG via HUB VCN DRG attachment and all other VCN act as a spoke.

Whenever traffic comes to the DRG, A VCN route table attach to the DRG send all the traffic to the private IP of the OCI network firewall which inspect the traffic and sends to the destination. The traffic goes back to the DRG and check the spoke VCN for which it is send to and divert the same to that spoke VCN attachments.

By placing the Network Firewall in the hub VCN, it becomes the inspection point for:

• North–South traffic

            Internet ↔ VCN
            On-prem ↔ VCN (via IPSec/FastConnect)

• East–West traffic

        VCN ↔ VCN within a region
        VCN ↔ VCN across regions via RPC

This ensures all traffic passes through a single firewall, improving governance, policy consistency, and auditability. 

Key Network Firewall Capabilities

• Intrusion Prevention (IPS)
• Threat Intelligence–based filtering
• URL and application filtering
• SSL forward proxy and inspection
• Custom policy creation
• High availability
• Logging and analytics

Use Cases:

- Enforced inspection for hybrid traffic

- Secure DMZ architectures

- Segmentation between sensitive workloads

- Preventing lateral movement inside the cloud

3. OCI Web Application Firewall (WAF)

OCI WAF protects public-facing applications from common web threats. The OCI Web Application Firewall provides an intelligent security layer that shields web applications from threats before they reach your infrastructure. It protects against OWASP Top 10 vulnerabilities, malicious bots, DDoS-style traffic spikes, and unwanted geographic access. 

WAF policies can be applied globally at the edge or directly to load balancers, ensuring consistent protection for websites, APIs, and modern microservices. With custom rules, threat intelligence, and rate-limiting, WAF becomes a critical frontline defense for any internet-facing workload.

Key Features

• OWASP Top 10 protection
• Bot management & rate limiting
• Custom access control rules
• Geo-blocking
• Integration with OCI Load Balancer & API Gateway
• Edge protection (CDN + WAF)
• WAF is essential for frontend applications, APIs, and any service exposed to the public.

4. Bastion Service – Secure Access into Private Networks

Bastion Service eliminates the need for public SSH/RDP access to servers. Instead of opening ports or using jump hosts, Bastion provides identity-driven, time-limited secure access.

When a user needs access:

1. They request a Bastion session.
2. Bastion generates a short-lived SSH key.
3. A secure tunnel is created to the private target.
4. Default sessions last 180 minutes (TTL) and then automatically terminate.
5. All access is logged in OCI Audit.

Why Bastion Is Critical for Zero Trust

• Servers never require public IPs
• NSGs/Security Lists remain locked down
• No long-lived SSH keys
• Fine-grained IAM control
• Fully auditable access

Bastion is ideal for administrators, DBAs, break-glass operations, or emergency troubleshooting.

5. Zero Trust in OCI Networking

Zero Trust in OCI goes beyond simple security rules and embraces the principle of “never trust, always verify.” Every request—whether internal or external—must be authenticated, authorized, and continuously monitored. 

OCI implements Zero Trust through identity-driven access, micro-segmentation using NSGs, encrypted communications, short-lived credentials (like Bastion sessions), and automated compliance enforcement via Cloud Guard. This model ensures that no network path or user is inherently trusted, reducing attack surfaces dramatically.

OCI’s Zero Trust framework is built around:

• Identity-based access
• Least-privilege networking (NSGs, SLs)
• Encrypted communications
• No implicit trust between networks
• Continuous monitoring (Cloud Guard)
• Short-lived credentials (Bastion, Vault)

Zero Trust ensures that no traffic or user is trusted by default—every request must be authenticated, authorized, and logged.

6. Oracle Cloud Guard – Cloud Security Posture Management

I know cloud guard is not related with the network security topics and it come under security posture management but it worth to mention because it helps detecting public exposure of subnets, VNICs, load balancers, alerting when NSG/SL rules are overly permissive and Identifying risky network configurations. Oracle Cloud Guard acts as the central security watchdog for your entire OCI tenancy, continuously scanning configurations, network paths, identity policies, and resource behavior for vulnerabilities or misconfigurations. 

When it detects risks—such as exposed ports, overly permissive NSGs, insecure storage buckets, or abnormal API activity—it not only alerts administrators but can automatically remediate them using responder recipes. Cloud Guard transforms cloud security posture management from reactive monitoring into proactive, automated governance.

Cloud Guard is OCI’s unified engine for monitoring, detecting, and remediating risky configurations across the entire cloud footprint.

Cloud Guard as a Security Brain

Cloud Guard continuously analyzes:

• Network configurations (open ports, NSGs, SLs)
• Public endpoints
• IAM privileges
• Object Storage exposure
• Logging/Audit anomalies
• Suspicious API activity

Automated Remediation

Using responder recipes, Cloud Guard can automatically:

• Remove dangerous security rules
• Close exposed ports
• Disable risky network paths
• Remove public access from buckets
• Quarantine compromised resources

Cloud Guard enforces global governance across multi-VCN and multi-region deployments.

7. OCI Vault – Keys, Secrets & Certificates

Again OCI vaults comes under security but it can be consumed by network-facing services (e.g., Load Balancer SSL termination, API Gateway certificates).

OCI Vault provides secure, centralized storage for encryption keys, credentials, API tokens, SSL certificates, and other sensitive secrets that applications depend on. With strong lifecycle management, automated secret rotation, versioning, and fine-grained IAM access control, 

Vault ensures secrets never appear in code or on servers. Integrations with services like Load Balancer, OKE, Functions, and Databases enable a fully encrypted, identity-driven, Zero Trust environment where sensitive data is always protected both at rest and in transit.

OCI Vault handles:

• Encryption keys (KMS)
• Secrets (passwords, tokens, API keys, private keys)
• Certificates (TLS/SSL)

Vault integrates with:

• Load Balancer
• API Gateway
• OKE
• Functions
• Compute
• Autonomous & DB Systems

Secrets Management

Vault lets you securely store:

• App passwords
• DB credentials
• SSH keys
• Cloud API tokens
• Application secrets

Secrets can be automatically rotated, versioned, and retrieved only through IAM-controlled API calls, implementing true Zero Trust security.

8. Additional Advanced Security Features You Should Not Ignore

OCI includes several advanced networking security capabilities that enhance visibility and threat detection across cloud deployments. Services like Flow Logs allow deep traffic analysis, while Threat Intelligence integrates global reputation data to block known malicious sources. Traffic Mirroring enables packet-level inspection for forensic investigations, and Security Zones enforce secure-by-default policies across sensitive compartments. 

Together, these features create a comprehensive defense strategy tailored for modern cloud environments.

Flow Logs -> Capture VCN-level traffic patterns for analysis and anomaly detection.

Threat Intelligence Service -> Aggregates global threat sources and provides reputation-based filtering.

VCN Traffic Mirroring -> Clone live network traffic to analysis tools for forensic or security inspection.

Security Zones -> Hard enforcement of “secure-by-default” rules (no public subnets, no open ports, no disabled logs, etc.).

Conclusion

OCI provides a rich suite of networking security tools—from foundational firewalls to Zero Trust frameworks, encryption vaults, cloud firewalls, and intelligent automated remediation. Whether securing a small application or designing a global-scale, multi-region enterprise architecture, these tools enable deep protection for workloads and data.

Adopting NSGs for micro-segmentation, deploying Network Firewall in a hub, enabling Cloud Guard across the tenancy, storing secrets in Vault, and using Bastion for secure access together create a layered security model aligned with modern Zero Trust principles.

OCI Networking Series – Part 5: Load Balancing in OCI – Ensuring Scalable, Secure & Intelligent Traffic Distribution

In modern cloud architectures, application performance and availability depend heavily on how efficiently incoming traffic is distributed across backend servers. Oracle Cloud Infrastructure (OCI) offers a robust suite of load balancing capabilities that allow enterprises to build scalable, secure, and resilient applications. Whether you're hosting a simple web application or a multi-tier enterprise workload, understanding OCI’s load balancing services is essential for designing high-performance architectures.

Understanding Load Balancing in OCI

OCI Load Balancing is a fully managed service that automatically distributes incoming traffic across multiple compute instances or endpoints. What sets OCI apart is the flexibility to choose between Public and Private Load Balancers, and between different traffic-processing layers depending on your application needs.

A Public Load Balancer provides an internet-facing endpoint, suitable for web applications or APIs accessed globally. In contrast, a Private Load Balancer exposes only a private IP address within your VCN, making it ideal for internal applications, back-office services, or secure inter-tier communication in multi-tier architectures. Ensuring High Availability, Scalability & Intelligent Traffic Management

Public vs Private Load Balancer

Public Load Balancer

• Exposed to the internet with a public IP.
• Ideal for web applications, APIs, customer-facing portals.
• Supports L4 (TCP) and L7 (HTTP/HTTPS) traffic.

Private Load Balancer

• Only accessible inside a VCN.
• Used for internal apps, microservices, backend tiers, and database access.
• Enhances security by removing public exposure.

Layer 4 vs Layer 7 Load Balancing

OCI supports both L4 (TCP/UDP) and L7 (HTTP/HTTPS) traffic handling:

Layer 4 Load Balancing works at the transport layer and is ideal for TCP-intensive applications like databases, custom protocols, or microservices requiring raw transport-level routing.

Suitable for:

• Database connections
• Custom TCP-based apps
• High-performance workloads

Layer 7 Load Balancing, on the other hand, understands HTTP/HTTPS semantics, enabling advanced capabilities like URL-based routing, host-based routing, cookie persistence, 

and application-aware health checks. Applications that rely on browser traffic, REST APIs, or web-based interactions typically benefit from L7 features, while backend systems often use L4 for simplicity and performance.

Enables intelligent routing based on:

• URL paths
• Hostname
• Headers
• Cookies
• Query parameters

Supports:

• SSL termination
• Redirects
• URL rewrites
• Session persistence

Introducing Network Load Balancer (NLB) in OCI

For applications requiring extremely high throughput, ultra-low latency, or millions of concurrent connections, OCI provides the Network Load Balancer (NLB). Unlike the standard load balancer that operates at Layer 7, NLB works at Layer 3/4 and uses pass-through forwarding.

NLB is the preferred choice for performance-sensitive workloads like VoIP, gaming, real-time data processing, and high-volume financial applications because it introduces minimal overhead and supports static IP addresses. Additionally, NLB comes with source IP preservation, which is often required by backend systems for security or logging purposes.

Traffic Distribution & Health Checks

OCI employs several traffic distribution algorithms, including round robin, IP hash, and least connections, based on how you expect the application to behave under different workloads. These algorithms work in combination with sophisticated active health checks to ensure traffic is always directed to healthy backend instances.

OCI Load Balancer supports multiple algorithms for distributing traffic.

1. Round Robin (default) :- Sequential traffic distribution across all servers.
2. Least Connections :- Routes new traffic to backend with fewest active connections. Ideal for apps with uneven request sizes.
3. IP Hash :-  Same client IP goes to same backend. Used for session affinity use cases.
4. Weighted Distribution :- Assign heavier weights to more powerful servers. Useful for hybrid deployments (old vs new hardware).

Health checks monitor endpoints at configurable intervals and verify that only reachable, responsive, and stable servers receive traffic. This plays a crucial role in auto-scaling setups where backends join or leave dynamically.

SSL Termination & Certificate Management

A major advantage of OCI Load Balancer is its ability to handle SSL termination, offloading the computational burden of cryptographic processing from backend servers. This frees your application servers to focus purely on serving application logic.

SSL Termination :- 

• Load balancer decrypts SSL and sends traffic to backend in plain HTTP.
• Reduces CPU load on backend servers.

Allows:

• WAF inspection
• L7 routing rules
• Improved performance
• End-to-End SSL
• Client → Load Balancer → Backend server
• Required for compliance-heavy workloads.
• SSL Certificate Renewal

OCI Load Balancer supports:

• Manual upload of PEM certificates
• OCI Vault-managed certificates
• Auto-renewal when integrated with OCI Certificate Service

OCI also simplifies SSL certificate renewal by integrating with Oracle Certificates service and allowing you to upload, rotate, and manage certificates seamlessly. Automatic renewals minimize the risk of sudden downtime due to expired certificates—a common operational issue in global deployments.

Advanced Layer 7 Routing Policies

With the rise of microservices and API-driven architectures, routing intelligence at Layer 7 has become essential. OCI Load Balancer supports rich, dynamic routing policies that allow traffic to be directed based on:

• Hostname (Host-based routing) – e.g., directing api.example.com to one backend set and app.example.com to another.

            app.company.com, billing.company.com → unique backend pools.

• Path-based routing – useful for separating frontend, backend, or admin interfaces.

        /api/*, /images/* → different backend sets.

• Header-based routing – powerful for A/B testing, versioning, or custom enterprise policies. Different device types or A/B test traffic.

• Method or Parameter-based routing – for advanced request filtering.

These capabilities enable architects to streamline application design without relying on external gateway appliances.

Multiple Listeners on a Single Load Balancer

OCI allows you to configure multiple listeners on the same load balancer, each handling different protocols, ports, or routing rules.

For example:

Port 80 → HTTP listener redirecting to HTTPS

Port 443 → HTTPS listener terminating SSL

Port 8443 → Internal admin console routing

Port 22 → SSH routing to bastion-backed private instances (secured appropriately)

Each listener can attach:

• Different backend sets
• Different SSL certificates
• Different routing rules

This flexibility allows you to consolidate infrastructure, reduce costs, and simplify management, especially when hosting multi-service applications.

Security with OCI WAF Integration

Security is a core element of modern application delivery. OCI Load Balancers integrate seamlessly with OCI Web Application Firewall (WAF), 

providing protection from OWASP Top 10 vulnerabilities, bots, SQL injection attempts, and cross-site scripting attacks.

By placing WAF in front of the load balancer—or integrating it directly at the edge—you ensure a robust, multi-layered defense across your application stack.

OCI WAF enhances security by providing:

OWASP Top 10 protection

• Rate limiting
• Bot mitigation
• Access control rules
• Geo-blocking

WAF → Load Balancer → Applications

This is the recommended best-practice deployment.

Conclusion

Load balancing in OCI is not just about distributing traffic — it's about building resilient, scalable, and intelligent application architectures. With Public/Private LBs, NLB, Layer 7 routing, SSL offload, and WAF protection, OCI delivers complete control for modern cloud deployments.

OCI Networking Series Part 4 – Advanced DRG & Multi-VCN Architectures Explained

Objective:  Scaling Networking in Large Deployments

As enterprises adopt Oracle Cloud Infrastructure (OCI) for mission-critical workloads, networking design must scale to handle multi-VCN, multi-region, and hybrid connectivity requirements. At the core of such architectures lies the Dynamic Routing Gateway (DRG) — a powerful, software-defined router that enables seamless communication between Virtual Cloud Networks (VCNs), on-premises networks, and even other cloud providers.

In this blog, we’ll explore advanced DRG use cases and multi-VCN architectures including attachments, Remote Peering, DRG attachments, Hub-and-Spoke design, and transit routing.

What is DRG, Enhanced DRG

The Dynamic Routing Gateway (DRG) in Oracle Cloud Infrastructure (OCI) is a regional virtual router that serves as the backbone for hybrid and multi-VCN connectivity. It provides a central point of control, enabling communication between Virtual Cloud Networks (VCNs), on-premises environments through IPSec VPN or FastConnect, and even cross-region VCNs using remote peering.

With the introduction of the Enhanced DRG (DRGv2), OCI has greatly simplified and strengthened network design. The enhanced DRG supports multiple types of attachments (VCNs, FastConnect, VPN, Local and Remote Peering), allows per-attachment route tables for fine-grained traffic control, and delivers greater scalability to support complex topologies such as hub-and-spoke architectures. This makes it easier for enterprises to design secure, flexible, and highly available hybrid cloud networks.

DRG Attachments

A DRG (Dynamic Routing Gateway) acts as the central connectivity hub in OCI. It supports multiple attachments that define the type of connection.

VCN Attachments → Connect a VCN to the DRG for routing traffic in/out of that VCN.

Remote Peering Connection (RPC) → Connects VCNs across different OCI regions securely over the OCI backbone.

FastConnect & IPsec VPN Attachments → Hybrid connectivity options linking on-premises datacenters or third-party clouds to OCI.

Each attachments has its own set of rules or import route distribution attached to it which controls the flow of the traffic. By default, there are 2 DRG route tables, one for for VCN attachment and other one for IPsec and fastconnect attachments.

In the above diagram, all the VCN attachments s are shown. Each attachment can have same or different route table. Keeping separate route table would be easy to manage, isolate and setup different routes for different attachments. If the setup is small and everything is allowed from each attachment to all then default route table makes more sense. But as a best practice, keeping separate RT helps in long run.

Remote Peering Connections (RPC)

When enterprises expand across regions, Remote Peering Connections (RPC) provide secure, low-latency connectivity between two VCNs in different OCI regions.

• Uses OCI’s private backbone network (not public internet).
• Supports east-west traffic flow across regions.
• Useful for DR setups (e.g., replicating databases from Mumbai region to Hyderabad region).

Each region has its own DRG and both DRG are connected through RPC connection at each side. A VM in a VCN from primary region can reach out to a VM to other region VCN compute. The connection goes through VM -> DRG -> RPC-1 -> RPC-2 -> DRG -> Compute.

Above diagram shows, the Remote peering connection is enabled between primary and secondary region and mentioned all the components required for its setup. Route table and security list controls the routes to the destination and security list restrict the ports.

🕸️ Hub-and-Spoke Architecture Design

Enterprises often manage dozens of VCNs across departments, projects, or business units. Connecting all VCNs in a mesh would be complex and unscalable. A dynamic routing gateway (DRG) allows you to connect up to 300 virtual cloud networks (VCNs) and helps to simplify the overall architecture, security list and route table configuration, and to simplify security policy management by advertising Oracle cloud identifiers (OCIDs) through the DRG. Instead, OCI recommends a Hub-and-Spoke model:

Hub VCN → Contains the DRG, shared services (DNS, logging, monitoring).

Spoke VCNs → Application-specific or environment specific VCNs.

Traffic between spokes flows via the hub DRG. 

Advantages:

✔ Centralized control

✔ Simplified routing

✔ Cost-efficient scaling

The below diagram, shows Hub VCN has network firewall and a load balancer, so each traffic from on-premises first goes to the Hub VCN as firewall inspect the traffic in HUB VCN subnet. Then it will go through the respective VCN. Even the reverse traffic follows the same route.

🔀 Transit Routing with DRG

Transit routing is a network architecture pattern that uses a central "hub" Virtual Cloud Network (VCN) to connect an on-premises network to multiple other VCNs, or to services, enabling traffic to "transit" through the hub to its final destination.

• Transit Routing enables one network connection (like FastConnect or VPN) to be shared across multiple VCNs via the hub DRG.
• Reduces redundant FastConnect/VPN setups.
• Ensures centralized hybrid connectivity.
• Simplified administration
• scalability (Easier to add more VCNs)

As mentioned in above diagram as well, each traffic form on-premises going through the HUB-VCN so its a central point for the traffic entering to the OCI tenancy and then forward the traffic to its respective destination.

✅ Best Practices for Advanced DRG & Multi-VCN Architectures

When designing OCI DRG and multi-VCN architectures, a few guiding principles can make your network both resilient and scalable. Start with a hub-and-spoke model, positioning the DRG at the center to simplify connectivity across environments. Use separate VCNs to clearly segment workloads—applications, databases, or testing—and keep shared services such as DNS, firewalls, and monitoring in the hub VCN for easier management. Take advantage of DRG route tables to fine-tune how traffic moves between networks, and enable BGP peering to gain dynamic routing, faster failover, and better bandwidth utilization. 

Strengthen your security posture with a Zero Trust mindset, applying Security Lists and Network Security Groups (NSGs) for precise traffic control. Finally, don’t overlook monitoring and logging, which provide the visibility needed to maintain both performance and protection in complex deployments.

• Use Hub-and-Spoke with Transit Routing for multi-VCN, multi-region scaling.
• For intra-region VCN connectivity, use DRG attachments (enhanced DRG); for cross-region, use RPC.
• Deploy redundant FastConnect or VPN tunnels for HA.
• Keep routing policies simple and centralized at the DRG.
• Apply security lists or NSGs carefully to control cross-VCN traffic.

Hands-On Practices to follow:- 

To gain the understanding of the above concepts, best approach is to try creating those architectures in free tier tenancy.

1. Create a Hub-and-Spoke Network with a DRG :- 

Provision one Hub VCN (10.0.0.0/16) and two Spoke VCNs (10.1.0.0/16 and 10.2.0.0/16).

Attach the Hub VCN and both Spoke VCNs to a DRG.

Configure DRG route tables so that traffic from Spoke-1 can reach Spoke-2 via the Hub.

Test: Launch a compute instance in each Spoke VCN and verify connectivity (ping/ssh).

2. Remote Peering Connection (RPC) – Cross-Region Connectivity

Create two VCNs in different regions (e.g., Ashburn and Phoenix).
Set up Remote Peering Gateways (RPGs) in both VCNs.
Establish a Remote Peering Connection.
Test: Deploy compute instances in both regions and verify private IP-to-private IP connectivity.

📌 Conclusion

Advanced DRG and Multi-VCN architectures provide the backbone for scalable, resilient, and hybrid OCI deployments. With features like VCN attachments,  DRG attachments, RPC, Hub-and-Spoke, and Transit Routing, enterprises can securely connect workloads across regions, projects, and even other clouds — all while keeping routing centralized and efficient.

 

OCI Networking Series – Part 3: Hybrid Networking with IPSec & FastConnect

 Objective:

In this blog, we take a deep dive into hybrid networking in Oracle Cloud Infrastructure (OCI), focusing on how enterprises securely and reliably connect their on-premises data centers to OCI. We’ll explore IPSec VPN, FastConnect, Dynamic Routing Gateway (DRG), customer edge router considerations, and real-world architectures — including how OCI integrates with other cloud providers like Azure, AWS, and Google Cloud Platform (GCP).

Why Hybrid Networking is Critical in OCI

Hybrid networking enables enterprises to extend their existing on-premises infrastructure into the cloud while ensuring business continuity, data security, and scalability. Enterprises often face scenarios such as:

✔ Gradual migration of workloads
✔ Disaster recovery and backup strategies
✔ Secure communication across cloud and on-prem environments
✔ Regulatory compliance and data sovereignty needs
✔ Multi-cloud deployments for performance optimization

OCI’s networking services empower to design secure, high-performance, and cost-effective hybrid architectures while maintaining control over traffic flow, encryption, and routing.

The Role of DRG in Hybrid Networking

The Dynamic Routing Gateway (DRG) is the central virtual router that connects your OCI VCN with on-premises networks through IPSec VPN or FastConnect.

Key Functions

✔ Route propagation between OCI and customer networks
✔ Central management of hybrid traffic flows
✔ Integration with route tables and security controls
✔ Support for multiple attachments — VPN, FastConnect, and VCN peering

Customer Edge Router – Essential Configuration Considerations

The on-premises router must meet certain standards to establish and maintain reliable hybrid connections.

Must-Have Features

✔ Support for IPSec and IKEv2 protocols
✔ Dual tunnel configuration for high availability
✔ Sufficient encryption processing capacity
✔ BGP (Border Gateway Protocol) support for dynamic route exchange
✔ Compatibility with provider-specific interfaces for FastConnect
✔ Security configurations to meet enterprise requirements

Example Use Case – Accessing OCI Databases from On-Premises

A common hybrid architecture scenario:

• An on-premises ERP system requires secure access to OCI’s Autonomous Database
• Dual IPSec VPN tunnels ensure redundancy during business hours
• A FastConnect circuit handles scheduled data replication and high-volume transfers
• DRG manages route propagation between on-prem and OCI
• Security rules restrict traffic to necessary ports and addresses
• Monitoring ensures availability, performance, and fault detection

This setup guarantees secure, high-performance communication while minimizing downtime and complexity.

IPSec VPN – Secure Internet-Based Connection Without Additional Charges

IPSec VPN provides encrypted communication over the public internet between your on-premises network and OCI’s Virtual Cloud Network (VCN) through the Dynamic Routing Gateway (DRG).

Key Features

✔ Uses industry-standard IPSec protocols and IKEv2 for secure tunnel establishment
✔ Supports dual tunnels for high availability (HA)
✔ No additional VPN charges — only bandwidth usage is billed
✔ Best suited for small offices, backup connections, or moderate workloads
✔ Provides encrypted communication without complex infrastructure changes

Limitations

✔ Internet variability can affect latency and throughput
✔ Not recommended for large-scale data transfers
✔ Encryption overhead may impact performance in compute-intensive environments

Setup Highlights

1. Attach a DRG to your OCI VCN
2. Create an IPSec connection in the OCI Console
3. Configure customer edge routers with matching encryption settings
4. Establish two tunnels for redundancy
5. Monitor and troubleshoot using OCI’s tools

There are 2 tunnels Tunnel1 and tunnel 2 for redundancy purpose. you can configure the parameters accordingly for both the tunnels. First create the CPE device which has the public IP from on-prem and then attach the CPE device to the IPSec connection.

As shown in above image there 3 routing type - BGP Dynamic routing, Static routing and Policy Based routing.

BGP Dynamic Routing: Uses Border Gateway Protocol (BGP) to automatically exchange and update routes between OCI (via DRG) and customer edge routers, enabling scalable and resilient connectivity.

Static Routing: Administrator manually defines fixed routes between on-premises and OCI; simple but less flexible as changes require manual updates.

Policy-Based Routing (PBR): Routes traffic based on policies such as source, destination, or application type, allowing granular control beyond just destination IPs.

FastConnect – High-Speed Private Connectivity for Mission-Critical Workloads

FastConnect provides a private, high-bandwidth, and low-latency connection between your on-premises network and OCI, bypassing the public internet. It is ideal for performance-sensitive workloads requiring consistent bandwidth and secure communication.

Peering Types

• Private Peering: Access OCI services like compute, block storage, or databases via private IP addresses.

• Public Peering: Access public OCI services like Object Storage or APIs securely over Oracle’s network.

Key Benefits

✔ Dedicated link with guaranteed bandwidth
✔ Predictable, low-latency connections
✔ Supports multiple circuits and failover strategies
✔ Enables large data transfers, replication, and analytics pipelines

Configuring FastConnect in OCI begins with creating a Dynamic Routing Gateway (DRG) and attaching it to your target VCN. Next, you set up a FastConnect connection, choosing either a FastConnect Partner (via an Oracle-approved provider) or FastConnect Direct (physical cross-connect at an Oracle colocation). 

For partner connections, you configure a virtual circuit, which can be single (basic) or redundant (for high availability). With FastConnect Direct, you establish physical connectivity and map it to a virtual circuit in OCI. After provisioning, configure BGP peering between your customer edge router and the OCI router to dynamically exchange routes. 

Redundancy can be added at the device, location, or configuration level to ensure resilience. 

Finally, validate the setup with connectivity tests and monitor the circuit using OCI’s monitoring tools.

FastConnect Partner: Connect through an Oracle-approved network provider.

Single Virtual Circuit: One dedicated connection through the partner (no redundancy).

Redundant Virtual Circuits: Two independent partner circuits for high availability.

FastConnect Direct: Direct physical cross-connect to Oracle at a colocation facility. Provides maximum control, lower latency, and is ideal for enterprises with existing colocation presence.

Redundancy Models:

Location Redundancy: Two FastConnect links from different physical sites.

Single FastConnect: One connection only (entry-level, no failover).

Device Redundancy: Dual edge devices at the same location for failover.

Configuration Redundancy: Dual circuits with BGP routing policies for seamless failover.

Below table shows the comparison between IPSec VPN and Fastconnect.

Hybrid Connectivity with Other Cloud Providers

For enterprises leveraging multi-cloud strategies, OCI’s hybrid networking solutions integrate seamlessly with equivalent offerings from other major cloud providers. Currently Oracle database facility is available in all major cloud providers like Azure, Google and AWS, there are many scenario's which has database in OCI and application setup is in the other cloud provider.  

🔗 OCI + Azure

OCI FastConnect ↔ Azure ExpressRoute

Enables private, high-bandwidth links between OCI and Azure, allowing workloads such as analytics, disaster recovery, and secure API access across clouds.

🔗 OCI + AWS

OCI FastConnect ↔ AWS Direct Connect

Provides private links for data replication, backup, and distributed applications between OCI and AWS regions.

🔗 OCI + GCP

OCI FastConnect ↔ Google Cloud Interconnect

Offers scalable, secure connectivity between OCI and Google Cloud services, supporting data pipelines, machine learning workflows, and cross-cloud architecture.

 Multi-Cloud Use Cases

✔ Disaster recovery across clouds
✔ Secure data pipelines for analytics
✔ Low-latency connections between cloud-native services
✔ Compliance-driven architectures
✔ Cost-effective multi-cloud resource optimization

Summary

In this part of the OCI Networking Series, we explored how hybrid networking enables secure, high-performance communication between on-premises environments and Oracle Cloud Infrastructure. We covered:

✔ IPSec VPN’s role in secure, internet-based connections without additional VPN charges
✔ FastConnect’s high-bandwidth, low-latency private connectivity for mission-critical workloads
✔ DRG’s routing capabilities in managing hybrid traffic
✔ Customer edge router requirements for encryption, redundancy, and dynamic routing
✔ Practical scenarios like accessing OCI databases from on-premises
✔ A comparison of IPSec VPN vs FastConnect
✔ Multi-cloud hybrid architectures using Azure ExpressRoute, AWS Direct Connect, and Google Cloud Interconnect

By implementing these best practices, organizations can confidently extend their networks into OCI, optimize performance, and ensure business continuity.

🌐 OCI Networking Series: Part 2 – Designing and Managing VCNs

 

Objective: Deep dive into VCN architecture 

Here, will see practical guidance for creating/managing VCNs, choosing public vs private subnets, working with route tables & security lists/NSGs, CIDR sizing and planning, plus subnetting best practices.

Quick primer — what a VCN is (Virtual Cloud Network)

A Virtual Cloud Network (VCN) is your private network inside OCI — think of it as a virtual datacenter where you define IP ranges, subnets, route rules and gateways that control traffic for your cloud workloads. You can create VCNs from the Console, CLI or via IaC (Terraform/Pulumi). 

Creating & managing VCNs :- 

Console (VCN Wizard) :

The easiest way for hands-on learning is the VCN Wizard (Console) — it can create a VCN with public + private subnets, route tables, internet/NAT/service 

gateways and default security lists in a few clicks.

CLI / API / IaC :

You can create VCNs using oci network vcn create, the REST API, or via Terraform / Pulumi providers (all documented). Use CLI for automation or scripts; 

use Terraform for reproducible deployments. 

You can also use quick wizard for automated VCN deployment but its not recommnded for actual production grade purpose. Its ok for learning purpose. The above describe 2 methods mostly used for deploying network in the OCI tenancy.

Important facts to keep in mind

• A VCN can include multiple non-overlapping IPv4 CIDR blocks. 
• You can update a VCN to add CIDR blocks (subject to limits and constraints) but CIDR changes must follow rules (no overlap, must not include addresses used by existing subnets.

Public vs Private Subnets — when & why

Public Subnet :- 

Resources in a public subnet typically have a public IP (or assigned public IP on the VNIC) and route outbound/inbound traffic via an Internet Gateway (IGW).  Public subnets are used for load balancers, bastion hosts, public-facing web servers, etc. Only one IGW is needed per VCN (but access still depends on route rules + security rules).

Private Subnet :-

Resources in private subnets do not have public IPs. If they need outbound internet access (patching, updates), use a NAT Gateway to provide outbound-only access while blocking inbound connections from the internet. This is the recommended pattern for backend servers/databases. 

Design rules of thumb

• Place edge-facing services (web tier, bastion) in public subnets and backend tiers (app, DB, caches) in private subnets. 
• Control egress for private subnets via NAT or through a proxy/firewall appliance. This pattern simplifies security posture and auditing.

Route Tables: Default vs Custom (how routing works)

Default route table :- 

Each VCN automatically has a default route table. Subnets inherit the VCN’s default route table unless you explicitly assign a custom one. 

Custom route tables :- 

Use custom route tables when you need different outbound targets for different subnets (for example: public subnet → IGW; private subnet → NAT or firewall; hybrid subnet → DRG).  Create a route rule with destination CIDR and target (IGW, NAT, DRG, Service Gateway, local peering, etc.).

Best practices

Give each logical tier (web, app, db) its own route table where it makes sense — this improves clarity and reduces risk of accidental route changes affecting multiple tiers. 

In the above diagram, There are 3 subnets - one public and 2 private subnets. Each subnets have their own route table and security list. Public subnet is reaching to the internet via internet gateway, whereas private subnet B is reaching internet via NAT gateway. 

Both subnets have different purpose and different routes so better to have separate route table for each subnets. The 3rd private subnet is reaching to the object storage - it may be for backup and it get there via service gateway.

Security: Security Lists vs Network Security Groups (NSGs)

Security Lists :-

Security lists are applied at subnet level — every VNIC in the subnet is subject to the security-list rules. The default security list comes with initial stateful rules to enable things like SSH by default; you should tighten these for production.

Network Security Groups (NSGs) :-

NSGs are applied to VNICs (instance-level micro-segmentation). They act like a virtual firewall for a group of resources that share the same security posture. Use NSGs when you want finer-grained control without segregating into separate subnets.

Stateful vs Stateless

Individual security rules can be stateful (default) or stateless. Stateful rules use connection tracking so responses are automatically allowed; stateless rules require you

to allow both directions explicitly.

When to use which

• Use security lists for broad, subnet-wide rules and NSGs for dynamic, instance-level or micro-segmentation use cases (e.g., allow only specific app servers to reach DB). 
• You can use both — they are additive. 

    

Each security rule have the option of stateless or stateful as highlighted in above diagram. Each have separate use cases on when to use what. 

CIDR block sizing & planning strategies (do this before you launch)

VCN IPv4 CIDR block size must be in the range /16 through /30; a VCN can contain multiple non-overlapping IPv4 CIDR blocks. Regardless of number of CIDR blocks, Oracle documents an upper bound on the number of private IPs (for many tenancy configs the practical limit is ~64K addresses per VCN. Plan accordingly. 

CIDR blocks must not overlap with on-premises network CIDRs or with peered VCNs. When you add/remove CIDR blocks, follow the documented CLI/API constraints 

(order, non-overlapping, work request state).

Practical planning tips

• Start with a /16 (10.0.0.0/16) if you anticipate many subnets/hosts; break it into /24s for tiers (10.0.1.0/24 for web, 10.0.2.0/24 for app, 10.0.3.0/24 for db). 
• If you expect lots of VCN peering or large-scale Kubernetes/containers, plan larger or multiple VCN CIDRs.
• Avoid RFC1918 overlap with on-prem: Coordinate with network team and reserve ranges for future peering/FastConnect/IPSec. 
• Leave headroom: Don’t allocate every available /24 right away — leave spare subnets for scaling and for service-specific needs (monitoring, jump hosts, analytics). 

The above table shows how many addresses comes with specific CIDR notation. All IP's are not usable for the subnet as first 2 and last IP address is used for internal networking purpose per subnet.

Subnetting best practices specific to OCI

• Use regional subnets (recommended by Oracle) — they are more flexible than AD-specific subnets and simplify distributing compute across ADs for HA. 
• Name and tag subnets and route tables consistently: <env>-<tier>-<region>-<purpose> (e.g., prod-app-mum-private). Good naming helps automation and audits. 
• Separate route tables for private vs public subnets — easier to reason about and reduces blast radius when updating routes. 
• Prefer NSGs for micro-segmentation if your environment is dynamic (auto-scaling, ephemeral VMs) — NSGs move with the VNIC. Use security lists for stable, static network tiers. 

Example quick checklist before you create your production VCN

• Confirm your CIDR plan and avoid overlap with on-prem or other VCNs. 
• Decide regional vs AD-specific subnet strategy (Oracle recommends regional subnets for flexibility). 
• Prepare security policy: NSGs vs Security Lists and stateful/stateless rules. 
• Plan route tables per tier (public vs private vs hybrid). 
• Create tagging + naming conventions so automation & audits are simple.

What's Next :- 

Hands-on: Use the OCI Free Tier to spin up a VCN via the Console wizard, create one public + one private subnet, attach an IGW and NAT, launch a compute instance in each, 

and test connectivity. 

See you in the next one!!!

How to Securely Access OCI Object Storage Using Private Endpoints

 ✍ Introduction

When using Oracle Cloud Infrastructure (OCI), securing your data and controlling how it’s accessed is essential. One way to achieve this is by using OCI Object Storage private endpoints, which ensure that your data stays within OCI’s private network without using the public internet. 

This blog explains what private endpoints are, their benefits, and how to set them up using the OCI Console. We’ll also explain how access was handled before and how private endpoints offer improved security and control.

✅ How Access Was Handled Before Using Private Endpoints

Before private endpoints were available, OCI users could access Object Storage in one of two ways:

Through a Service Gateway

A Service Gateway allows resources inside your VCN to access OCI services like Object Storage without going through the public internet. Even though the traffic doesn’t leave OCI’s cloud, it’s still routed through OCI’s shared infrastructure.

Public Buckets via the Internet

If the bucket was public or the network didn’t have a service gateway configured, applications could access Object Storage over the internet using public endpoints. This method exposes your storage to broader access risks and internet traffic.

✅ What’s Different with OCI Object Storage Private Endpoints

Private endpoints build on the idea of private access but go further by giving you full control over where traffic flows and who can access it:

• Traffic stays within your VCN’s subnet, not OCI’s shared service infrastructure.

• You can create custom endpoints with your own DNS prefix and namespace for easy access.

• You decide which buckets, namespaces, and compartments are accessible, making it more secure than both service gateways and public endpoints.

• Private endpoints offer dedicated bandwidth up to 25 Gbps, ensuring faster data transfers.

This makes private endpoints the preferred choice for organizations that want secure object storage access, cloud data privacy, and performance optimization in OCI.

In the above diagram, whoever wants to access the Object storage can access it via the vnic in the private subnet. The vnic will receive one IP from the subnet 10.3.0.0/24

✅ Limits You Should Know About Private Endpoints

OCI imposes some limits to ensure efficient management and scalability:

• Up to 10 private endpoints per tenancy.

• Up to 10 access targets per private endpoint.

• Maximum bandwidth of 25 Gbps per endpoint.

These limits help maintain performance while giving you flexibility to structure your network access.

✅ How Private Endpoints Work

When you create a private endpoint, OCI:

1. Creates a virtual network interface (VNIC) inside the chosen subnet.

2. Sets up a custom endpoint URL using the DNS prefix and namespace you specify.

3. Resolves the endpoint to the private IP if your DNS resolver is within the VCN or to a public IP if resolved from outside.

This ensures that your application’s access to Object Storage stays secure and under your control.

✅ How to Create a Private Endpoint (Step-by-Step)

🔹 Step 1 – Create the Private Endpoint

Enter a name, choose a unique DNS prefix, select the correct VCN and subnet.

🔹 Step 2 – Add Access Targets

Specify the namespace, compartment, and bucket. Use wildcards only when necessary.

🔹 Final Setup

OCI will create a VNIC and a custom endpoint for your Object Storage access.

 Testing the Setup

Launch a compute instance in the private subnet and test uploading/downloading files to Object Storage via the private endpoint.

✅ Best Practices

• Use specific access targets instead of wildcards where possible.
• Limit the number of endpoints and targets according to business needs.
• Regularly monitor access and permissions.
• Use OCI’s private DNS resolver for consistent private routing.
• Follow cloud security best practices for storage networking.

✅ Conclusion

With OCI Object Storage private endpoints, you get the highest level of security and control over how data is accessed and transferred. Compared to service gateways and public buckets, private endpoints offer better isolation, performance, and compliance support. This solution aligns with modern cloud security strategies and helps organizations keep their data safe while optimizing network efficiency.