Home / OCI

OCIHow-toAdvanced

OCI Network Firewall in a hub VCN: DRG and route table design for north-south and east-west inspection

Route spoke-to-spoke, on-prem and internet traffic through an OCI Network Firewall in a hub VCN. DRG route tables and import distributions, VCN ingress route tables, symmetric return paths and the checks that prove traffic is really inspected.

Deepak Bhardwaj4 min read

Applies toOCI Network Firewall, Dynamic Routing Gateway (DRG v2), VCN route tables (including DRG attachment and gateway ingress route tables), OCI CLI 3.x

Deploying the firewall takes minutes. Getting every flow to pass through it, in both directions, is the real work. A missed route means traffic that bypasses inspection; an asymmetric route means traffic that silently drops.

Target topology

            on-prem (FastConnect / IPSec)
                     |
                  [ DRG ]  ----------------- spoke VCN A (10.1.0.0/16)
                     |    \---------------- spoke VCN B (10.2.0.0/16)
                hub VCN (10.0.0.0/16)
          firewall subnet 10.0.1.0/24  -> Network Firewall (10.0.1.10)
          NAT/IGW for internet egress

All spokes and on-prem attach to one DRG. The hub VCN attachment is where traffic is sent for inspection.

Step 1: DRG route tables

Create two DRG route tables:

DRG route table Attached to Routes
rt-drg-spokes Spoke VCN attachments and the on-prem attachment(s) 0.0.0.0/0 -> hub VCN attachment (static)
rt-drg-hub Hub VCN attachment Imported routes for spokes and on-prem (import distribution) 
oci network drg-route-table create --drg-id $DRG --display-name rt-drg-spokes
oci network drg-route-rule add --drg-route-table-id $RT_SPOKES --route-rules \
  '[{"destination":"0.0.0.0/0","destinationType":"CIDR_BLOCK","nextHopDrgAttachmentId":"'"$HUB_ATTACH"'"}]'

For the hub table, an import route distribution that accepts routes from VCN and virtual circuit / IPSec attachments lets it learn spoke and on-prem prefixes dynamically.

Warning

If the spoke DRG route table also imports spoke routes, the DRG will prefer the more specific spoke prefix and send spoke-to-spoke traffic directly, bypassing the firewall. Keep rt-drg-spokes static with only the default route to the hub (plus anything deliberately uninspected).

Step 2: hub VCN ingress routing

Traffic arriving at the hub from the DRG must go to the firewall first. Use a VCN route table associated with the DRG attachment of the hub (a transit routing table):

rt-hub-drg-ingress (associated with hub VCN's DRG attachment)
  10.1.0.0/16 -> private IP 10.0.1.10 (firewall)
  10.2.0.0/16 -> private IP 10.0.1.10
  on-prem CIDRs -> private IP 10.0.1.10
  0.0.0.0/0   -> private IP 10.0.1.10

oci network drg-attachment update --drg-attachment-id $HUB_ATTACH \
  --network-details '{"type":"VCN","id":"'"$HUB_VCN"'","routeTableId":"'"$RT_HUB_INGRESS"'"}'

Get the firewall's private IP OCID for route targets:

oci network private-ip list --subnet-id $FW_SUBNET --ip-address 10.0.1.10 --query 'data[0].id' --raw-output

Step 3: the firewall subnet route table

After inspection, the firewall forwards to the real next hop:

rt-fw-subnet
  10.1.0.0/16 -> DRG
  10.2.0.0/16 -> DRG
  on-prem     -> DRG
  0.0.0.0/0   -> NAT gateway (or internet gateway for public egress)

Step 4: return path for internet traffic

Return traffic from the internet arrives at the NAT or internet gateway. Associate a gateway ingress route table with that gateway so replies go back through the firewall instead of straight to the DRG:

rt-igw-ingress (associated with the internet gateway)
  10.1.0.0/16 -> firewall private IP
  10.2.0.0/16 -> firewall private IP

Without it, outbound traffic is inspected but replies bypass the firewall, which a stateful firewall drops.

Step 5: firewall policy basics

  • Start with an allow-and-log policy for the address ranges you route, confirm flows appear, then tighten.
  • Use address lists for spokes and on-prem, application lists for ports.
  • Enable traffic and threat logs to the Logging service.
oci network-firewall network-firewall list --compartment-id $COMP --output table

Prove inspection

  1. Generate traffic from spoke A to spoke B (curl, nc -vz 10.2.1.5 443).
  2. Search firewall traffic logs for the flow:
search "<compartment-ocid>/<log-group-ocid>/<log-ocid>" | where data.src = '10.1.1.20' and data.dst = '10.2.1.5'
  1. Run Network Path Analyzer from source to destination and confirm the path shows the firewall private IP as a hop.

If the flow works but is not in the logs, it is bypassing the firewall: check the spoke DRG route table first.

Common problems

Symptom Cause Fix
Spoke-to-spoke works, no firewall logs Spoke DRG table imports spoke routes Static default route to hub only
One direction works, the other times out Asymmetric routing: only one side sent via firewall Both spokes use rt-drg-spokes; check hub ingress table covers both CIDRs
Internet egress drops replies No gateway ingress route table Associate one with the NAT/IGW
On-prem cannot reach spokes after change On-prem attachment uses the hub table, not spokes table Associate the correct DRG route table
Throughput lower than expected Firewall sizing or inspection profile Check firewall metrics and current throughput limits

Prevent it next time

  • Draw the four route tables (DRG spokes, DRG hub, hub ingress, firewall subnet, gateway ingress) in your design doc with every CIDR.
  • Automate with Terraform so a new spoke gets the right DRG table association by default.
  • Alert on DRG attachment route table changes through OCI Events.

Related fixes