Oracle Cloud Network Firewall Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, Identity, and Compliance

1. Introduction

Oracle Cloud Network Firewall is a managed, inline network security service for Oracle Cloud Infrastructure (OCI) virtual networks. It is designed to inspect traffic flows (north-south and/or east-west), apply centrally managed firewall policies, and help organizations enforce consistent network security controls across environments.

In simple terms: you place Network Firewall in the path of network traffic, then define what should be allowed or denied. Instead of relying only on subnet-level allowlists (security lists) or instance-level rules (NSGs), you can add deeper, policy-driven inspection and enforce consistent controls.

Technically, Network Firewall is deployed into an OCI VCN (Virtual Cloud Network) and is attached to one or more subnets via endpoints (implementation details vary by service design; confirm in your region’s docs). You steer traffic to it using route tables, and the firewall enforces an explicit Network Firewall Policy (rules and profiles). It integrates with OCI Logging and Audit to support operations and governance.

What problem it solves: security lists and NSGs are essential but are mainly L3/L4 constructs. Network Firewall adds a centrally managed, inline enforcement point that better supports standardized security controls, policy lifecycle management, and (in supported configurations) next-generation inspection capabilities. It helps reduce misconfigurations, improves auditability, and provides a scalable pattern for “service insertion” in OCI networking.

Service status note: As of this writing, Network Firewall is an active OCI service. Always verify naming and current capabilities in the official OCI documentation because security services evolve and feature availability can vary by region.

2. What is Network Firewall?

Official purpose

Oracle Cloud Network Firewall is a managed firewall service that enables inline traffic inspection and policy-based allow/deny decisions for traffic traversing OCI networks. It is commonly used as a centralized enforcement point for VCN traffic.

Core capabilities (high-level)

Network Firewall typically provides:

Stateful traffic inspection for allowed flows (connection tracking)
Policy-based enforcement using a dedicated firewall policy object
Traffic steering via OCI route tables (service insertion)
Logging and visibility by integrating with OCI Logging/Audit (exact log types vary; verify supported log categories in docs)
Segmentation and control for traffic between subnets/tiers (east-west) and to/from internet/on-prem (north-south) when routed through the firewall

Depending on the specific OCI Network Firewall implementation and your region/tenancy settings, the service may also support more advanced inspection constructs (for example, application-aware controls, threat prevention profiles, or URL filtering). Verify supported “next-generation” features for your region in official docs before designing around them.

Major components

In OCI, you typically work with the following conceptual building blocks:

Network Firewall (the firewall instance/resource): The inline enforcement point deployed into your VCN.
Network Firewall Policy: The configuration object that defines what the firewall should do (rule sets, matching criteria, and actions).
Rules / Rule collections: How you express what traffic is allowed/denied. Terminology and rule hierarchy should be validated in current OCI docs.
Networking constructs that steer traffic: VCN subnets, route tables, and (often) NSGs/security lists that still play an important role for baseline access control.
Logging/monitoring integrations: OCI Logging, Metrics/Monitoring, and Audit.

Service type

Managed network security service (inline firewall) within Security, Identity, and Compliance, tightly integrated with OCI Networking.

Scope (regional vs global)

Network Firewall is generally a regional resource: you create and operate it in a specific OCI region and attach it to a VCN that exists in that region.
It is also compartment-scoped (OCI IAM compartments), meaning policies and access controls are applied at the compartment level.

How it fits into the Oracle Cloud ecosystem

Network Firewall sits at the intersection of:

OCI Networking: VCNs, subnets, route tables, gateways, DRG (Dynamic Routing Gateway)
OCI Security, Identity, and Compliance: IAM policies, Audit, Logging, Cloud Guard/Security Zones (adjacent governance services)
OCI Compute and PaaS services: Protecting traffic to/from compute instances, Kubernetes clusters, and private endpoints.

3. Why use Network Firewall?

Business reasons

Standardize security controls across teams and environments (dev/test/prod) using centrally managed policies.
Reduce risk of misconfiguration by consolidating enforcement logic into a single managed control plane.
Improve audit readiness with consistent policy artifacts and centralized logging.
Speed up delivery by providing reusable security patterns (validated architectures) instead of repeating bespoke firewall setups.

Technical reasons

Inline enforcement: You can force traffic through the firewall using routing, rather than relying solely on distributed allowlists.
Segmentation at scale: A shared inspection layer for multi-tier apps and shared services.
Clear security boundaries: Especially useful in hub-and-spoke architectures where a central hub enforces security controls.

Operational reasons

Centralized policy management rather than managing rules on dozens of NSGs/security lists.
Visibility: Firewall logging provides an operational record of allowed/blocked flows (log availability varies by configuration—verify in docs).
Change management: Firewall policies are a clear unit of change that can be reviewed, versioned (process-driven), and applied consistently.

Security/compliance reasons

Supports stronger controls for regulated environments (PCI, HIPAA, ISO 27001, SOC 2), especially around:
Segmentation
Controlled egress
Documented network policy
Monitoring and audit trails

Scalability/performance reasons

A managed firewall service avoids running and scaling your own firewall appliances (patching, failover design, capacity management).
Performance characteristics depend on firewall shape/throughput model (pricing and throughput details vary—verify in official pricing/docs).

When teams should choose it

Choose Network Firewall when you need one or more of the following:

Central, inline inspection for east-west traffic between app tiers/subnets
Central enforcement for north-south traffic to/from internet or on-prem (via DRG) with controlled routing
A firewall policy object that is separate from application workloads and can be governed by a security team
Higher-confidence segmentation and standardized security patterns

When teams should not choose it

Avoid or defer Network Firewall if:

You only need basic L3/L4 filtering and NSGs/security lists already meet your requirements.
Your traffic patterns cannot tolerate inline inspection latency (or you cannot architect for it).
Your design cannot maintain symmetric routing (a common requirement for stateful firewalls).
You need features not supported by OCI Network Firewall in your region; don’t design based on assumptions—verify supported features first.

4. Where is Network Firewall used?

Industries

Financial services and fintech (segmentation, egress control, audit)
Healthcare (regulated data flows, segmentation)
E-commerce and SaaS (multi-tier applications, shared services)
Public sector (policy control, centralized security)
Manufacturing/IoT platforms (hub-and-spoke patterns, controlled connectivity)

Team types

Platform engineering teams building shared VCN landing zones
Security engineering teams enforcing guardrails
Network engineering teams implementing hub-and-spoke OCI network topologies
SRE/operations teams responsible for uptime and incident response
DevOps teams integrating routing + policy changes into IaC pipelines

Workloads

Multi-tier web applications (web → app → database)
Microservices across multiple subnets or VCNs
OCI Kubernetes Engine (OKE) with controlled ingress/egress patterns
Shared services VCNs (jump hosts, CI/CD runners, artifact repos)
Hybrid connectivity (on-prem ↔ OCI) through a DRG, with inspection

Architectures

Single VCN with segmented subnets and a centralized inspection subnet
Hub-and-spoke with centralized firewalling in a hub VCN
Hybrid architectures using DRG attachments and routed inspection paths

Real-world deployment contexts

Enforcing outbound access to approved destinations (controlled egress)
Blocking lateral movement between subnets except approved ports
Inspecting partner/vendor connectivity (B2B integrations)

Production vs dev/test usage

Production: Use with high governance, logging, change management, and tested routing symmetry/failover.
Dev/test: Useful for validating policy and traffic patterns early, but cost and complexity may not be necessary for small ephemeral environments. Many teams use NSGs/security lists in dev and enforce Network Firewall in staging/prod—if that matches your risk model.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Network Firewall is commonly used.

1) East-west segmentation between app tiers

Problem: Subnets can talk too freely, enabling lateral movement if one tier is compromised.
Why Network Firewall fits: Central policy point to strictly allow only required inter-tier traffic.
Scenario: Web subnet can reach app subnet on TCP/8443 only; app subnet can reach DB subnet on TCP/1521 only; everything else denied.

2) Centralized egress control (approved outbound)

Problem: Workloads can exfiltrate data or download malware via unrestricted outbound access.
Why it fits: Route all outbound traffic through the firewall and allow only approved destinations/ports.
Scenario: App servers can reach OS package repos and SaaS endpoints, but all other outbound is blocked and logged.

3) Hub-and-spoke shared inspection

Problem: Multiple VCNs need consistent enforcement without duplicating rules everywhere.
Why it fits: A centralized firewall policy in the hub, with traffic steered through the hub.
Scenario: Spoke VCNs route to shared services and internet via hub; hub contains Network Firewall enforcement.

4) Hybrid connectivity inspection (on-prem ↔ OCI)

Problem: On-prem users/services access OCI workloads, but you need inspection and segmentation.
Why it fits: Route DRG traffic through Network Firewall before it reaches workload subnets.
Scenario: Only specific on-prem CIDRs can reach OCI app endpoints; all other attempts are blocked and logged.

5) Protecting admin paths (jump hosts to private workloads)

Problem: Administrative SSH/RDP access is risky and often overly permissive.
Why it fits: Explicit policy controls for admin flows and strong logging for forensics.
Scenario: Only bastion subnet can reach private instances on SSH; all admin sessions are logged.

6) Partner/vendor network access control

Problem: Partners require access, but scope must be tightly constrained.
Why it fits: Granular policies for partner CIDRs and defined app ports.
Scenario: Vendor CIDR can reach API gateway/private endpoint only; no access to databases.

7) Controlled ingress path to internal services

Problem: Even internal ingress (from load balancers or gateways) should be inspected and segmented.
Why it fits: Inspect traffic between ingress tier and internal tiers.
Scenario: Public LB in one subnet forwards to app tier; route that flow through Network Firewall for policy enforcement (architecture-dependent; verify supported insertion pattern).

8) “Default deny” posture for shared services

Problem: Shared services (CI/CD, artifact registries, monitoring) are sensitive.
Why it fits: Default deny with explicit allow rules.
Scenario: Only CI runners can reach artifact registry; developers can only reach via approved ports.

9) Incident response containment

Problem: You need to quickly quarantine suspicious traffic without redeploying workloads.
Why it fits: Update firewall policy to block specific destinations or subnet-to-subnet flows.
Scenario: Block outbound traffic to a suspected C2 domain/IP range and immediately reduce blast radius.

10) Compliance-driven segmentation and audit trails

Problem: Auditors require demonstrable segmentation controls and evidence.
Why it fits: Central policies + logging provide easier compliance artifacts.
Scenario: PCI cardholder data environment (CDE) subnets are isolated; only approved flows exist and are logged for audit review.

11) “Service insertion” for platform landing zones

Problem: Platform teams need a repeatable secure network baseline.
Why it fits: Network Firewall becomes part of the reference landing zone pattern.
Scenario: New application VCNs attach to a hub that enforces baseline controls via Network Firewall.

12) Reducing reliance on host firewalls

Problem: Host-level firewall drift and misconfiguration increases operational risk.
Why it fits: Network-layer enforcement reduces dependence on every VM being configured correctly.
Scenario: Teams still use host firewalls for defense-in-depth, but Network Firewall enforces baseline segmentation.

6. Core Features

Note: OCI security services evolve. Treat the items below as the common “core” capabilities. Verify feature availability and exact terminology in official OCI Network Firewall documentation for your region.

1) Inline, stateful inspection

What it does: Tracks connection state and enforces policy across the lifecycle of flows.
Why it matters: Reduces false positives and enables consistent allow/deny behavior for established connections.
Practical benefit: Easier to express policies like “allow outbound HTTPS and allow return traffic.”
Caveat: Stateful inspection typically requires symmetric routing (traffic must pass through the firewall in both directions).

2) Central firewall policy object (Network Firewall Policy)

What it does: Separates policy definition from the firewall resource.
Why it matters: Supports reuse, governance, and controlled updates.
Practical benefit: Apply consistent policies across environments or firewalls.
Caveat: Policy changes can have immediate impact; implement change control and staged rollout.

3) Traffic steering using OCI route tables

What it does: Lets you insert the firewall into traffic paths by routing destination CIDRs to the firewall.
Why it matters: Enables service insertion patterns without changing application IPs.
Practical benefit: Centralizes enforcement for multi-subnet architectures.
Caveat: Routing mistakes can cause outages (blackholes, asymmetric paths, loops). Validate carefully.

4) Layered security with NSGs/security lists

What it does: Works alongside OCI NSGs and security lists.
Why it matters: Defense-in-depth and clear responsibilities (baseline vs deep inspection).
Practical benefit: Use NSGs for “who can talk,” firewall for “what is allowed” across broader policy.
Caveat: Overlapping rules can complicate troubleshooting; document precedence and intent.

5) Logging integration

What it does: Produces logs related to traffic and/or policy decisions (exact log categories depend on configuration).
Why it matters: Audit trails, troubleshooting, detection engineering.
Practical benefit: Send logs to OCI Logging; export to SIEM.
Caveat: Logging can incur cost (log ingestion/storage) and must be protected (PII considerations).

6) Compartment-based governance and tagging

What it does: Uses OCI compartments, IAM policies, and tags for access control and cost allocation.
Why it matters: Aligns with OCI enterprise governance.
Practical benefit: Separate network/security admin duties; track costs per environment.
Caveat: Poor compartment design can lead to over-privileged access or operational friction.

7) High-availability design patterns (service-managed)

What it does: Managed service aims to reduce operational overhead for availability (exact HA behavior is service-specific).
Why it matters: You want consistent policy enforcement without managing appliance failover.
Practical benefit: Simplifies production operations compared to self-managed firewall appliances.
Caveat: You still must design routing and dependencies (DRG, subnets, gateways) for resilience.

8) Automation support (Console, API, SDK, CLI/IaC)

What it does: Supports infrastructure-as-code patterns via OCI APIs and common tooling (Terraform is widely used on OCI).
Why it matters: Repeatability and drift control.
Practical benefit: CI/CD-driven policy updates with review gates.
Caveat: Ensure you implement safeguards to prevent accidental lockouts.

7. Architecture and How It Works

High-level architecture

Network Firewall is deployed into an OCI VCN and used as an inline hop. You update subnet route tables so that traffic destined to certain CIDRs is routed to the firewall rather than directly to the destination.

Typical flow:

A client workload sends traffic to a destination (another subnet, internet via NAT/IGW, on-prem via DRG).
The subnet’s route table matches the destination CIDR.
The next hop is set to Network Firewall (or its endpoint, depending on OCI implementation).
Network Firewall evaluates the packet/flow against its policy.
Allowed traffic is forwarded; denied traffic is dropped (and may be logged).

Control plane vs data plane

Control plane: You create firewall resources, policies, and logging configuration via OCI Console/API. IAM governs who can change what.
Data plane: Actual packets/flows traverse the firewall inline.

Integrations with related OCI services

VCN, subnets, route tables: Service insertion and segmentation
NSGs and security lists: Baseline access control
Logging: Central log collection (and optional export to SIEM)
Audit: Tracks API calls and configuration changes
DRG: Hybrid connectivity inspection patterns
Compartments and tagging: Governance and cost allocation

Dependency services

OCI Networking (VCN and routing) is the primary dependency.
OCI IAM, Audit, and Logging for governance and operations.

Security/authentication model

Authentication and authorization are handled via OCI IAM.
Fine-grained permissions should be applied using compartments and least privilege.
Use Audit logs for traceability of changes.

Networking model considerations

Symmetric routing: Most stateful inline firewalls require traffic in both directions to pass through the same inspection point.
Route specificity: Use careful CIDR matching and avoid ambiguous routes.
Avoid single points of failure: Design with multiple availability domains/fault domains as appropriate to your region and service support (verify what OCI Network Firewall supports for HA).

Monitoring/logging/governance

Enable logs to support:
Troubleshooting (“why is traffic blocked?”)
Threat hunting
Compliance evidence
Use OCI Audit to record firewall and policy changes.
Use tagging standards (environment, owner, cost center).

Simple architecture diagram (Mermaid)

flowchart LR
  A[Client VM\nPublic Subnet] -->|Route to 10.0.2.0/24 via Network Firewall| F[Network Firewall\nInspection Subnet]
  F -->|Allowed| B[Server VM\nPrivate Subnet]
  B -->|Return path via Network Firewall| F
  F --> A

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph SpokeVCN["Spoke VCNs (Apps)"]
    S1[App Subnet A]
    S2[App Subnet B]
  end

  subgraph HubVCN["Hub VCN (Shared Security)"]
    FW[Network Firewall\nInspection Subnet]
    NAT[NAT Gateway]
    IGW[Internet Gateway]
    LOG[OCI Logging]
  end

  subgraph OnPrem["On-Premises"]
    DC[Data Center Network]
  end

  DRG[DRG]

  S1 -->|Routes to shared services / internet| FW
  S2 -->|Routes to shared services / internet| FW

  FW --> NAT --> IGW
  DC --> DRG --> FW

  FW --> LOG

The exact hub-and-spoke attachment and routing model depends on DRG attachments and VCN connectivity design. Validate with OCI reference architectures and your organization’s network standards.

8. Prerequisites

OCI account/tenancy requirements

An active Oracle Cloud tenancy with permissions to create networking and security resources.
A compartment where you can create:
VCN/subnets/route tables
Compute instances (for the lab)
Network Firewall and its policy
Logging resources (optional but recommended)

Permissions (IAM)

You need permissions for: – Networking (VCN, subnets, route tables) – Compute (instances, VNICs) – Network Firewall resources and firewall policies – Logging and Audit viewing

OCI IAM policy syntax and resource-type names can be service-specific. If you write policies manually, verify the exact policy resource types for Network Firewall in the OCI IAM Policy Reference.

Practical approach: – Use the OCI Console Policy Builder and select the Network Firewall service to generate correct statements. – Apply least privilege: – Network team: manage VCN/routing – Security team: manage firewall policies – App team: read-only visibility into firewall decisions/logs

Billing requirements

Network Firewall is a paid managed security service in most cases.
The tutorial is designed to be small, but it may still incur hourly and traffic-based charges.
Ensure you have billing enabled and understand cost before running production-like tests.

Tools needed

OCI Console access
Optional: OCI Cloud Shell (recommended) or a local terminal with SSH client
Optional: OCI CLI (only if you prefer CLI workflows; verify service-specific CLI commands in current CLI docs)
Basic Linux command knowledge

Region availability

Network Firewall availability can vary by OCI region. Confirm in the OCI Console (service list) and official documentation.

Quotas/limits

Service limits (number of firewalls, policies, endpoints, throughput) may apply.
Check Service Limits in the OCI Console for your tenancy and region.

Prerequisite services

For the lab, you need: – VCN – Subnets – Route tables – Compute instances (one public “client”, one private “server”)

9. Pricing / Cost

Pricing changes over time and differs by region and commercial agreement. Use the official pricing page and the OCI Cost Estimator for current rates.

Current pricing model (common dimensions)

OCI Network Firewall pricing commonly includes dimensions such as:

Firewall instance-hours (time-based cost while the firewall is provisioned)
Data processed (GB inspected/processed by the firewall)
Potential additional dimensions depending on features enabled (for example, advanced threat profiles), if offered—verify in official pricing.

Free tier

OCI Free Tier usually covers select services (compute, networking basics). Network Firewall is generally not part of Always Free, but confirm current Free Tier inclusions.

Cost drivers

Direct drivers: – Number of firewalls provisioned (hours) – Traffic volume routed through the firewall (GB) – Log volume (if sending detailed logs to OCI Logging)

Indirect drivers: – Additional NAT Gateways, Load Balancers, or DRG traffic patterns – Data egress to the internet (OCI has specific egress pricing rules; verify) – Operational tooling (SIEM ingestion costs)

Hidden/indirect costs to watch

Routing changes can increase traffic through centralized points (hairpinning), increasing processed GB.
Verbose logging increases log ingestion/storage and SIEM costs.
Non-prod environments left running (firewall-hours) can become a steady cost.

Network/data transfer implications

Inspecting traffic does not inherently mean egress charges, but:
Internet egress from OCI is typically billable beyond any free allowances.
Inter-region traffic and certain cross-boundary transfers can be billable.
Always model traffic paths (east-west vs north-south) and understand which links are billed.

How to optimize cost

Start with the smallest number of firewalls needed; avoid “one firewall per subnet” unless required.
Keep non-prod environments scheduled/off when not in use.
Route only the required CIDRs through the firewall (avoid routing broad ranges that force unnecessary inspection).
Tune logging:
Enable the logs you actually investigate.
Use retention policies and export only necessary fields to SIEM.

Example low-cost starter estimate (no fabricated numbers)

A starter lab typically includes: – 1 Network Firewall for a short duration (hours) – Low traffic volume (a few GB at most) – Minimal logs

To estimate: 1. Open the official OCI pricing page and locate “Network Firewall”. 2. Multiply firewall hourly rate × expected hours. 3. Add data processed rate × estimated GB. 4. Add logging costs if enabled (OCI Logging ingestion/storage/export).

Example production cost considerations

In production, costs scale with: – 24/7 runtime – High throughput (GB processed) – Multiple environments/regions – Logging retention and SIEM forwarding

Best practice: treat Network Firewall as a shared platform control (hub-and-spoke) where appropriate, but weigh this against: – blast radius – operational complexity – potential throughput bottlenecks – availability requirements

Official references: – OCI Pricing: https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html
– OCI documentation landing page (search “Network Firewall”): https://docs.oracle.com/en-us/iaas/

10. Step-by-Step Hands-On Tutorial

Objective

Deploy Oracle Cloud Network Firewall inline between two subnets in a single VCN and enforce a simple policy:

Allow HTTP (TCP/80) from a “client” VM to a “server” VM
Deny a test port (TCP/8080) to demonstrate policy enforcement

This lab demonstrates east-west inspection and the operational workflow: routing → policy → validation → troubleshooting → cleanup.

Lab Overview

You will create:

1 VCN: 10.0.0.0/16
3 subnets:
Public client subnet: 10.0.1.0/24
Private server subnet: 10.0.2.0/24
Firewall (inspection) subnet: 10.0.3.0/24
1 Network Firewall Policy (allow 80, deny 8080)
1 Network Firewall instance attached to the inspection subnet
2 Compute instances:
client-vm (public IP) used to test connectivity
server-vm (no public IP) running a web server on port 80 and a test listener on 8080 (optional)

Expected outcome:
Traffic from client → server on TCP/80 succeeds. Traffic on TCP/8080 fails due to firewall policy (assuming NSGs/security lists allow it so the firewall is the deciding control).

Important: OCI security lists/NSGs and OS firewalls can also block traffic. For a clear test, you’ll configure baseline network rules to allow the traffic, then rely on Network Firewall to block it.

Step 1: Create a compartment (optional but recommended)

In the OCI Console, go to Identity & Security → Compartments.
Create a compartment named: nf-lab.
Use this compartment for all lab resources.

Expected outcome: A dedicated compartment makes cleanup and access control easier.

Step 2: Create a VCN with subnets and gateways

Go to Networking → Virtual Cloud Networks.
Click Create VCN.
Choose VCN with Internet Connectivity only if you want OCI to create an Internet Gateway automatically.
Otherwise, choose Create VCN and create components manually.
Use: – VCN name: nf-vcn – CIDR: 10.0.0.0/16
Create 3 subnets: – client-public-subnet (Public): 10.0.1.0/24 – server-private-subnet (Private): 10.0.2.0/24 – firewall-subnet (Private is fine): 10.0.3.0/24
Ensure you have an Internet Gateway (IGW) for the client subnet to allow SSH access to the client VM (or use OCI Bastion instead—more secure).
Update the client subnet’s route table to include: – Destination: 0.0.0.0/0 – Target: Internet Gateway

Expected outcome: You have a VCN with three subnets and internet access for the public client subnet.

Step 3: Create baseline security rules (NSG recommended)

Using Network Security Groups (NSGs) makes intent clearer than using subnet security lists.

Go to Networking → Network Security Groups.
Create NSG: nsg-client
Create NSG: nsg-server

Add rules:

For nsg-client (egress): – Allow TCP egress to 10.0.2.0/24 ports 80 and 8080

For nsg-server (ingress): – Allow TCP ingress from 10.0.1.0/24 ports 80 and 8080

Also allow SSH to the client VM from your IP:

For nsg-client (ingress): – Allow TCP ingress from your public IP/32 to port 22

If you use security lists instead, implement equivalent rules.
Keep the server private (no public IP) for a more realistic pattern.

Expected outcome: Baseline networking permits the test ports so the firewall policy can be the “deciding factor”.

Step 4: Create the server VM (private) with a simple web server

Go to Compute → Instances → Create instance.
Name: server-vm
Placement: choose an availability domain as appropriate.
Image: Oracle Linux (or Ubuntu) — choose a current supported image.
Networking: – VCN: nf-vcn – Subnet: server-private-subnet – Public IP: Do not assign – NSG: attach nsg-server
Add cloud-init user data to install a web server and open a simple response:

Example (Oracle Linux / Ubuntu-ish; verify package manager for your image):

#!/bin/bash
set -euxo pipefail

# Install and start a web server on port 80
if command -v dnf >/dev/null 2>&1; then
  dnf -y install nginx
  systemctl enable --now nginx
elif command -v yum >/dev/null 2>&1; then
  yum -y install nginx
  systemctl enable --now nginx
elif command -v apt-get >/dev/null 2>&1; then
  apt-get update
  apt-get -y install nginx
  systemctl enable --now nginx
fi

echo "hello from server-vm on port 80" > /usr/share/nginx/html/index.html

# Optional: start a simple listener on 8080 to test blocking
# (Uses Python if available; otherwise skip)
if command -v python3 >/dev/null 2>&1; then
  nohup python3 -m http.server 8080 --bind 0.0.0.0 >/var/log/http8080.log 2>&1 &
fi

Expected outcome: server-vm is running nginx on port 80 and (optionally) a simple HTTP server on 8080.

Step 5: Create the client VM (public) used for testing

Create another instance.
Name: client-vm
Image: Oracle Linux (or Ubuntu).
Networking: – Subnet: client-public-subnet – Assign public IP: Yes – NSG: attach nsg-client
Save the SSH private key securely and note the client VM’s public IP.

Expected outcome: You can SSH to client-vm from your workstation.

SSH example:

ssh -i /path/to/private_key opc@<CLIENT_PUBLIC_IP>

(Username varies by image: opc for Oracle Linux, ubuntu for Ubuntu.)

Step 6: Create a Network Firewall Policy

Go to Security → Network Firewall (service location may vary in the console navigation).
Create a Network Firewall Policy named: nf-policy-lab
Add rules to: – Allow: source 10.0.1.0/24 to destination 10.0.2.0/24, TCP/80 – Deny: source 10.0.1.0/24 to destination 10.0.2.0/24, TCP/8080
Set a clear default stance: – Many firewall designs recommend default deny with explicit allow rules. – If the policy supports a default action/order, configure it accordingly.

Exact UI fields and terminology vary. Follow the policy wizard and map the rule intent: source CIDR, destination CIDR, protocol/port, action, and logging.

Expected outcome: You have a firewall policy with at least one allow rule and one deny rule that can be tested.

Step 7: Create the Network Firewall instance and attach the policy

Create Network Firewall: – Name: nf-lab-fw – VCN: nf-vcn – Subnet: firewall-subnet – Policy: attach nf-policy-lab
Wait for provisioning to reach an Available/Active state.

Expected outcome: Network Firewall exists as a routable next hop in your VCN (implementation-specific).

Step 8: Insert the firewall into the traffic path using route tables

Now you force traffic between client and server to traverse the firewall.

8A) Update client subnet route table

Go to the route table used by client-public-subnet.
Add a route rule: – Destination CIDR: 10.0.2.0/24 – Target type: Network Firewall (or the appropriate next hop selection in the console) – Target: nf-lab-fw

Keep the internet route (0.0.0.0/0 → IGW) for SSH access.

8B) Update server subnet route table (return path)

Go to the route table used by server-private-subnet.
Add a route rule: – Destination CIDR: 10.0.1.0/24 – Target type: Network Firewall – Target: nf-lab-fw

This symmetric routing step is critical. Without it, return traffic may bypass the firewall, causing stateful inspection to fail.

Expected outcome: Client ↔ server flows are routed through Network Firewall in both directions.

Step 9: (Optional) Enable logging for visibility

If your OCI Network Firewall supports emitting traffic/policy logs to OCI Logging:

Create a Log Group in OCI Logging (Observability & Management → Logging → Log Groups).
Enable relevant logs for Network Firewall (traffic logs, threat logs, etc., depending on what’s supported).
Confirm logs are arriving by generating test traffic.

Expected outcome: You can observe firewall decisions and troubleshoot with evidence.

If you don’t see log options, verify region availability and the exact logging integration steps in official docs.

Validation

Perform tests from the client VM.

SSH to client-vm.
Determine the server’s private IP from the instance details (e.g., 10.0.2.x).
Test HTTP on port 80 (should be allowed):

curl -v http://<SERVER_PRIVATE_IP>/

Expected outcome: You should receive hello from server-vm on port 80.

Test port 8080 (should be denied by firewall):

curl -v http://<SERVER_PRIVATE_IP>:8080/

Expected outcome: The connection should fail (timeout or connection reset), depending on how the firewall denies traffic.

If you enabled firewall logs, confirm there is a log entry indicating: – Allow for TCP/80 – Deny for TCP/8080

Troubleshooting

Common issues and fixes:

Traffic bypasses the firewall – Symptom: Both ports work, or behavior doesn’t match policy. – Fix: Re-check route tables for both subnets. Ensure both directions route through Network Firewall (symmetric routing). – Confirm there isn’t a more specific route overriding your rule.
Both ports are blocked – Symptom: TCP/80 fails even though you allowed it in the firewall policy. – Fix checklist: – NSG/security list on server allows inbound 80 from client subnet – NSG/security list on client allows egress to server subnet port 80 – OS firewall on server (iptables/firewalld/ufw) allows 80 – Nginx service is running – Firewall policy rule order is correct (deny isn’t matching first)
Can’t SSH to client VM after route changes – Symptom: SSH times out. – Fix: Ensure 0.0.0.0/0 → Internet Gateway still exists in the client subnet route table, and NSG/security list allows SSH from your IP.
Server user-data didn’t run – Symptom: Port 80 closed; curl fails. – Fix: Check cloud-init logs on the server (requires access via a bastion/jump host). Alternatively, rebuild server-vm and ensure user-data is correctly pasted as “cloud-init”.
No firewall logs – Symptom: Traffic works/blocks but no logs appear. – Fix: Confirm logging is enabled and you’re looking in the correct log group/compartment. Verify Network Firewall log support in your region.

Cleanup

To avoid ongoing charges:

Delete compute instances: – client-vm – server-vm
Delete Network Firewall: – nf-lab-fw
Delete Network Firewall Policy: – nf-policy-lab
Delete NSGs: – nsg-client, nsg-server
Delete VCN (which deletes subnets, route tables, gateways if not shared): – nf-vcn
Delete log groups/logs if created (optional, based on retention needs).
If you created a compartment dedicated to the lab and it’s empty, delete it.

Expected outcome: No billable Network Firewall resources remain.

11. Best Practices

Architecture best practices

Design for symmetric routing: ensure return paths traverse the firewall, especially for east-west segmentation.
Use hub-and-spoke deliberately: central inspection can simplify governance, but avoid excessive hairpinning that increases latency and cost.
Segment by trust zones: group subnets into security zones (web/app/data/shared/admin) and enforce explicit allow rules.
Separate dev/test/prod: use separate compartments (and often separate VCNs) to reduce blast radius.

IAM/security best practices

Apply least privilege:
Security team manages firewall policies.
Network team manages routing and firewall placement.
App teams get read-only access to logs and policy visibility.
Use MFA and strong identity governance for administrators.
Use OCI Audit for change tracking and integrate with SIEM where required.

Cost best practices

Avoid routing broad destination ranges through the firewall if not required.
Schedule non-prod firewalls off-hours if possible (depending on operational constraints).
Control log volume with appropriate log levels and retention.

Performance best practices

Keep route tables simple and deterministic.
Avoid routing loops and overlapping CIDR rules.
Validate latency impact for critical paths (databases, synchronous APIs).

Reliability best practices

Use multi-AD patterns where applicable and supported, but confirm the Network Firewall service’s HA and placement model in your region.
Document rollback plans for policy/routing changes.
Test failure scenarios (route misconfig, policy deny, dependent gateway outages).

Operations best practices

Enable logs and define dashboards/alerts based on:
Deny spikes
Unexpected egress attempts
Policy change events (Audit)
Use consistent naming:
env-app-zone-fw
env-fw-policy-baseline
Tag resources:
Environment, Owner, CostCenter, DataClassification

Governance/tagging/naming best practices

Use compartments as the primary governance boundary (prod vs non-prod, business unit).
Use tags for cost allocation and ownership tracking.
Implement policy-as-code review practices for firewall rules (even if the UI is used, keep a structured change record).

12. Security Considerations

Identity and access model

OCI IAM controls who can:
Create/delete firewalls
Create/update firewall policies
Update route tables (critical!)
View logs and audit trails
Treat routing permissions as high-risk: an operator who can change routes can bypass security controls or cause outages.

Encryption

Network Firewall does not replace TLS encryption; it enforces network policy.
If the service supports TLS inspection/decryption in your region, treat it as a high-sensitivity feature:
Key management, certificate handling, and privacy requirements must be addressed.
Verify in official docs whether and how decryption is supported.

Network exposure

Keep the firewall in a dedicated inspection subnet.
Ensure only required administrative access exists to workloads; firewall should not become a “backdoor” path.
Use NSGs/security lists to reduce the attack surface even if the firewall is enforcing deeper policy.

Secrets handling

Avoid embedding secrets in user-data scripts or firewall policy descriptions.
If you integrate with external logging/SIEM, ensure credentials are stored in OCI Vault and accessed via instance principals/dynamic groups where possible.

Audit/logging

Enable OCI Audit and routinely review:
policy changes
firewall creation/deletion
route table changes
Protect logs:
control access (read-only for most)
define retention aligned with compliance
avoid logging sensitive payloads if that’s possible in your configuration

Compliance considerations

Network Firewall can help with: – Segmentation controls (PCI-style network zoning) – Egress restrictions and monitoring – Change traceability (Audit)

But compliance depends on: – documented processes – least privilege IAM – evidence collection (logs, audits, change approvals) – consistent deployment patterns

Common security mistakes

Asymmetric routing leading to unpredictable behavior and emergency “temporary allow all” changes.
Allowing broad “any-any” rules because initial connectivity tests were blocked.
Granting too many users permission to update route tables or firewall policies.
Turning on overly verbose logs without access controls, risking data exposure.

Secure deployment recommendations

Start with a default deny posture and add explicit allows.
Keep policy ownership with a security/platform team.
Implement staged rollouts:
dev → staging → prod
Use break-glass procedures:
documented emergency access
time-bound elevated permissions
mandatory post-incident review

13. Limitations and Gotchas

Confirm current limits and behaviors in the official Network Firewall docs and OCI Service Limits.

Common limitations and operational gotchas include:

Symmetric routing requirement: Stateful inspection commonly requires that both directions pass through the firewall.
Routing complexity: Incorrect route rules can cause:
blackholed traffic
routing loops
bypass of inspection
Overlapping controls: NSGs/security lists + firewall rules can be confusing; you may troubleshoot the wrong layer.
Regional availability: Not all OCI regions may support Network Firewall.
Service limits: Limits may exist on number of firewalls, policies, endpoints, and throughput.
Change impact: A policy update can immediately affect production traffic. Use careful change management.
Logging costs and sensitivity: High-volume logs cost money and can contain sensitive metadata.
Not a WAF: Network Firewall is not the same as a web application firewall; it typically won’t replace app-layer protections such as OWASP rule sets for HTTP payloads (use OCI WAF where appropriate).
Not a substitute for host hardening: You still need OS patching, endpoint security, and secure configuration.

14. Comparison with Alternatives

Network Firewall sits among several security options. The “best” choice depends on whether you need inline inspection, centralized policy, and what layer you’re protecting.

Options to consider

OCI Network Security Groups (NSGs) / Security Lists: Basic L3/L4 allowlists.
OCI Web Application Firewall (WAF): Protects HTTP/HTTPS applications at L7 (typically in front of web apps).
Third-party firewall appliances (self-managed NVAs): Full control, but you manage scaling, patching, HA, and lifecycle.
Other cloud equivalents: AWS Network Firewall, Azure Firewall, etc.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Network Firewall	Central inline enforcement in OCI networks	Managed service, centralized policy, routing-based insertion, integrated logging/audit	Costs (hours + traffic), routing complexity, feature set depends on region/service design	You need centralized inline controls beyond NSGs/security lists
OCI NSGs / Security Lists	Baseline segmentation and least privilege at L3/L4	Simple, low cost, native, fast to apply	Not a full firewall policy engine; distributed rule management at scale	Small/medium environments or as defense-in-depth alongside a firewall
OCI Web Application Firewall (WAF)	Public web apps and APIs	L7 protections (OWASP-style), bot controls (feature-dependent), shields apps from common web attacks	Not for generic TCP/UDP flows; not for east-west segmentation	You need HTTP(S) application protection rather than network-level segmentation
Self-managed NVA firewall (marketplace)	Highly customized firewall needs	Maximum control, feature-rich, vendor-specific capabilities	You manage HA, updates, scaling, licensing complexity	You need specific features not available in managed Network Firewall or need full appliance control
AWS Network Firewall	Inline inspection in AWS	Native AWS integration	Different platform; not applicable inside OCI	Multi-cloud standardization comparisons
Azure Firewall	Centralized firewall in Azure	Azure-native routing and policy	Different platform; not applicable inside OCI	Multi-cloud standardization comparisons

15. Real-World Example

Enterprise example: regulated hub-and-spoke with controlled egress

Problem: A financial services company runs multiple OCI workloads across business units. Auditors require segmentation and controlled egress, plus traceability of policy changes.
Proposed architecture:
Hub VCN contains Network Firewall in an inspection subnet.
Spoke VCNs attach via OCI networking connectivity (design varies; often DRG-based patterns).
All internet egress from spokes routes through hub → Network Firewall → NAT → IGW.
East-west spoke-to-shared-services traffic routes through the firewall.
Central logging to OCI Logging and export to SIEM; Audit monitored for changes.
Why Network Firewall was chosen:
Central policy enforcement
Inline traffic inspection and consistent controls
Easier compliance evidence than distributed NSG-only patterns
Expected outcomes:
Standardized segmentation and egress controls
Reduced risk of accidental open paths
Improved incident response (central block rules + logs)

Startup/small-team example: protecting a multi-tier SaaS in a single VCN

Problem: A startup has a simple SaaS stack (web/app/db) but wants stronger segmentation as they onboard enterprise customers.
Proposed architecture:
Single VCN with separate subnets for web/app/data/admin.
Network Firewall inserted between web→app and app→data paths for strict allow rules.
NSGs still used for minimal baseline restrictions.
Logging enabled at a moderate level for troubleshooting and customer audits.
Why Network Firewall was chosen:
Managed service reduces operational load compared to self-managed appliances
Central policy simplifies audits and future expansion
Expected outcomes:
Clear security boundaries
Easier to demonstrate controls to customers
Ability to scale into hub-and-spoke later if needed

16. FAQ

Is Oracle Cloud Network Firewall the same as NSGs or security lists?
No. NSGs/security lists are baseline L3/L4 allow rules at the subnet/VNIC level. Network Firewall is an inline firewall service with a centralized policy and routing-based insertion.
Do I still need NSGs/security lists if I use Network Firewall?
Yes in most designs. Use NSGs/security lists for baseline access control and least privilege. Use Network Firewall for centralized policy enforcement and inline inspection.
Does Network Firewall require symmetric routing?
Commonly yes for stateful inspection. Ensure return traffic also passes through the firewall, or flows may break.
Can Network Firewall protect internet ingress to my web app?
It can be part of an ingress path if your routing design supports it, but for HTTP(S) application attacks you typically also consider OCI WAF. Validate supported insertion patterns in the docs.
Is Network Firewall a replacement for OCI WAF?
No. WAF focuses on L7 HTTP(S) threats; Network Firewall focuses on network flows and segmentation.
Can I use Network Firewall for east-west traffic inside a VCN?
Yes—this is a common service insertion use case.
Can I route on-premises traffic through Network Firewall?
Often yes by steering DRG-attached traffic through the firewall, but the exact pattern depends on your DRG/VCN topology. Validate with OCI reference architectures.
Does Network Firewall inspect all protocols?
It can enforce policies on IP traffic routed through it; specific protocol/application inspection capabilities depend on feature support. Verify in official docs.
How do I avoid outages when updating firewall policies?
Use staged environments, peer review, change windows, and test rules with narrow scopes before broad deployment. Keep a rollback plan.
What’s the biggest operational risk with Network Firewall?
Route misconfiguration and asymmetric routing. Treat route table changes as high-risk.
How do I prove that the firewall is blocking traffic (not an NSG)?
Ensure NSGs/security lists allow the test traffic, then use firewall logs to confirm deny/allow decisions.
Does Network Firewall generate logs automatically?
Logging typically requires configuration (log groups, log enablement) and may vary by region/service capabilities. Verify the logging setup steps in docs.
How do I estimate cost?
Use OCI pricing for Network Firewall (instance-hours + traffic processed) plus logging and data transfer costs. Validate with OCI Cost Estimator.
Is Network Firewall suitable for very small deployments?
Sometimes. If NSGs/security lists meet your needs, they may be simpler and cheaper. Network Firewall becomes more valuable as governance and scale needs grow.
Can I automate Network Firewall with Terraform?
Many OCI resources are supported by Terraform via the OCI provider. Confirm current resource support for Network Firewall and policy objects in the provider documentation.
What’s the difference between “default deny” and “default allow” posture?
Default deny blocks everything not explicitly allowed, which is safer but requires more upfront rule definition. Default allow is riskier and harder to audit.
Should I centralize all traffic through one firewall?
Not always. Centralization improves governance but increases blast radius and can create bottlenecks. Balance security with availability and performance.

17. Top Online Resources to Learn Network Firewall

Because OCI documentation URLs and navigation can evolve, the safest approach is to start from OCI’s official documentation and search for “Network Firewall” within it.

Resource Type	Name	Why It Is Useful
Official documentation	OCI Documentation (start here) – https://docs.oracle.com/en-us/iaas/	Canonical entry point; search for “Network Firewall” to find the latest concepts and procedures
Official pricing	OCI Price List – https://www.oracle.com/cloud/price-list/	Authoritative pricing reference; find “Network Firewall” for current billing dimensions
Official cost tool	OCI Cost Estimator – https://www.oracle.com/cloud/costestimator.html	Helps model firewall-hours, traffic processed, and related service costs
Official architecture center	OCI Architecture Center – https://docs.oracle.com/en/solutions/	Reference architectures for hub-and-spoke, security landing zones, and routed inspection patterns
Official security guidance	OCI Security – https://www.oracle.com/security/cloud-security/	Broader OCI security portfolio context (governance, services, and patterns)
Official logging guidance	OCI Logging docs (via docs landing page) – https://docs.oracle.com/en-us/iaas/	Learn log groups, retention, export, and operational practices
Official audit guidance	OCI Audit docs (via docs landing page) – https://docs.oracle.com/en-us/iaas/	Track control-plane changes for compliance and investigations
Official networking guidance	OCI Networking docs (via docs landing page) – https://docs.oracle.com/en-us/iaas/	Required foundation: VCNs, subnets, route tables, DRG patterns
Terraform provider docs	OCI Terraform Provider – https://registry.terraform.io/providers/oracle/oci/latest/docs	Practical IaC reference (verify Network Firewall resource support and examples)
Community learning	Oracle Cloud community forums – https://community.oracle.com/	Discussions and troubleshooting tips; validate against official docs

18. Training and Certification Providers

The following training providers may offer courses relevant to Oracle Cloud security and networking. Verify course syllabi and Oracle Cloud alignment directly on their websites.

1) DevOpsSchool.com
– Suitable audience: DevOps engineers, cloud engineers, SREs, platform teams
– Likely learning focus: DevOps + cloud operations; may include OCI deployments, security basics, and automation
– Mode: Check website
– Website: https://www.devopsschool.com/

2) ScmGalaxy.com
– Suitable audience: DevOps and SCM learners, beginners to intermediate
– Likely learning focus: DevOps fundamentals, tooling, CI/CD; may include cloud modules
– Mode: Check website
– Website: https://www.scmgalaxy.com/

3) CLoudOpsNow.in
– Suitable audience: Cloud operations and platform operations learners
– Likely learning focus: CloudOps practices, monitoring, operations; verify OCI-specific coverage
– Mode: Check website
– Website: https://cloudopsnow.in/

4) SreSchool.com
– Suitable audience: SREs, operations engineers, reliability-focused teams
– Likely learning focus: Reliability engineering, incident response, observability; may complement firewall operations practices
– Mode: Check website
– Website: https://sreschool.com/

5) AiOpsSchool.com
– Suitable audience: Operations teams exploring AIOps
– Likely learning focus: AIOps concepts, event correlation, monitoring practices; verify OCI relevance
– Mode: Check website
– Website: https://aiopsschool.com/

19. Top Trainers

These sites are presented as training resources/platforms. Verify specific Oracle Cloud Network Firewall coverage and trainer credentials directly on the sites.

1) RajeshKumar.xyz
– Likely specialization: Cloud/DevOps training content (verify specific topics)
– Suitable audience: Beginners to intermediate practitioners
– Website: https://rajeshkumar.xyz/

2) devopstrainer.in
– Likely specialization: DevOps training and mentoring (verify OCI coverage)
– Suitable audience: DevOps engineers and students
– Website: https://devopstrainer.in/

3) devopsfreelancer.com
– Likely specialization: DevOps consulting/training resources (verify offerings)
– Suitable audience: Teams seeking practical DevOps guidance
– Website: https://devopsfreelancer.com/

4) devopssupport.in
– Likely specialization: DevOps support and training resources (verify topics)
– Suitable audience: Operations teams and DevOps practitioners
– Website: https://devopssupport.in/

20. Top Consulting Companies

The following companies may provide consulting services related to cloud architecture, security, and DevOps. Verify service scope, references, and qualifications directly with the provider.

1) cotocus.com
– Likely service area: Cloud/DevOps consulting and implementation (verify OCI specialization)
– Where they may help: Cloud adoption planning, network architecture, security automation
– Consulting use case examples:
– Designing OCI hub-and-spoke network topology with centralized inspection
– Implementing IaC pipelines and operational runbooks for network controls
– Website: https://cotocus.com/

2) DevOpsSchool.com
– Likely service area: DevOps consulting and corporate training; may include cloud architecture support
– Where they may help: Platform engineering enablement, operational best practices, automation
– Consulting use case examples:
– Building repeatable OCI landing zones with standardized security controls
– Creating CI/CD workflows for infrastructure and policy deployment
– Website: https://www.devopsschool.com/

3) DEVOPSCONSULTING.IN
– Likely service area: DevOps and cloud consulting (verify OCI scope)
– Where they may help: DevOps transformation, cloud operations, monitoring, and security processes
– Consulting use case examples:
– Implementing operational dashboards for firewall logs and network controls
– Establishing change management practices for route and firewall policy updates
– Website: https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Network Firewall

OCI Networking fundamentals – VCNs, subnets, CIDR planning – Route tables and routing precedence – Internet Gateway, NAT Gateway, Service Gateway – NSGs vs security lists
Security fundamentals – Least privilege – Network segmentation and threat models – Logging and audit basics
OCI IAM – Compartments – Policies and groups – Dynamic groups and instance principals (useful for automation)

What to learn after Network Firewall

OCI Web Application Firewall (WAF) for L7 protections
OCI Cloud Guard and broader security posture management
OCI Logging and SIEM pipelines
Terraform/IaC for policy-driven deployments
Hybrid networking with DRG and advanced routing
Zero Trust patterns for service-to-service authentication and authorization

Job roles that use it

Cloud Network Engineer (OCI)
Security Engineer / Cloud Security Engineer
Platform Engineer
DevOps Engineer (with network/security focus)
SRE (operational ownership of network controls)
Solutions Architect

Certification path (if available)

Oracle certification offerings change. A common approach: – Start with OCI Foundations (conceptual) – Progress to OCI Architect and OCI Security tracks (if available) – Add vendor-neutral security certs (Security+ / SSCP) or advanced (CISSP) depending on role

Always verify current Oracle certification paths here: – https://education.oracle.com/

Project ideas for practice

Build a hub-and-spoke OCI network with a centralized inspection subnet and demonstrate controlled egress.
Implement “default deny” east-west segmentation for a 3-tier application and document the policy.
Export firewall logs to a SIEM and create alert rules for unusual denies/spikes.
Create a Terraform module that deploys a VCN + Network Firewall + baseline policies with environment-specific overrides.

22. Glossary

VCN (Virtual Cloud Network): OCI’s virtual network construct where you define IP ranges, subnets, and routing.
Subnet: A CIDR range within a VCN used to place resources (compute, load balancers, etc.).
Route table: Defines how traffic from a subnet is routed to destinations via next hops (gateways, DRG, firewall insertion).
NSG (Network Security Group): Virtual firewall rules applied to VNICs (instance-level grouping).
Security list: Subnet-level ingress/egress rules.
East-west traffic: Traffic between workloads inside a cloud network (subnet-to-subnet, tier-to-tier).
North-south traffic: Traffic entering/leaving the cloud environment (internet ingress/egress, on-prem connectivity).
Inline inspection: Traffic is routed through a security device/service before reaching its destination.
Stateful firewall: Tracks session state so return traffic is automatically associated with allowed connections.
Symmetric routing: Both directions of a flow traverse the same network path/inspection point.
Compartment: OCI governance boundary for access control and resource organization.
OCI Logging: Service for collecting and storing logs from OCI services and resources.
OCI Audit: Records API calls and configuration changes for governance and forensics.
DRG (Dynamic Routing Gateway): Connects VCNs to on-prem networks and other VCNs via routing attachments.
Service insertion: Pattern of inserting a security service (firewall) into a traffic path using routing.

23. Summary

Oracle Cloud Network Firewall is a managed, inline firewall service in the Security, Identity, and Compliance category that helps you enforce centralized network security policies in Oracle Cloud VCNs. It is most valuable when you need consistent segmentation, controlled egress, and policy governance beyond what NSGs and security lists provide.

Architecturally, it works by routing traffic through the firewall and applying a Network Firewall Policy. The key operational success factors are correct routing (especially symmetric routing), clear rule ownership, and strong observability through logs and audit trails.

From a cost perspective, plan for firewall runtime charges and data processed charges, plus indirect costs like logging and internet egress. Start small, route only what you must inspect, and keep non-production environments under tight scheduling and retention controls.

Use Network Firewall when you need centralized inline enforcement and governance; rely on NSGs/security lists for baseline controls; and add OCI WAF where you need application-layer HTTP protections.

Next learning step: read the latest OCI Network Firewall documentation (via the official docs landing page) and implement the same lab using Terraform to build repeatable, reviewable, production-ready patterns.

rajeshkumar

Category