Article 14 – Advanced Routing: Transit Hub VCNs and Next-Gen Firewall Insertion

1. Introduction to Centralized Transit Security Architecture

Enterprise security compliance often mandates that all network traffic—whether moving between internal cloud subnets (East-West traffic) or between cloud workloads and the internet/on-premises (North-South traffic)—must undergo deep packet inspection (DPI) through Third-Party Next-Generation Firewalls (NGFWs) such as Palo Alto Networks, Fortinet FortiGate, or Check Point CloudGuard.

In Oracle Cloud Infrastructure (OCI), deploying virtual firewalls centrally without sacrificing high availability or creating routing loops is achieved using Transit Hub VCN Architecture paired with DRG v2 Route Tables and Network Load Balancers (NLBs).

2. Core Architectural Challenges: Asymmetric Routing

When deploying multiple active virtual firewalls behind a load balancer, the primary threat to connectivity is Asymmetric Routing:

• The Problem: A client request packet routes through Firewall-01 (which logs the active TCP connection state in its state table). The return response packet from the server routes through Firewall-02. Because Firewall-02 has no record of the initial TCP handshake, it drops the return packet as an invalid state violation.
• The Solution in OCI:
• Symmetric Hashing on NLB: OCI NLB enforces 3-tuple or 5-tuple symmetric hashing, guaranteeing matching bidirectional flows hit the same firewall instance.
• Source NAT (SNAT) at Firewall: Virtual firewalls rewrite the source IP of inspected packets to the firewall’s internal interface IP, forcing return traffic to return back to the initiating firewall instance.

3. Transit Routing Components in DRG v2

Building an inspection hub relies on 3 specific DRG v2 routing features:

1. VCN Ingress Route Table (VCN Attachment Route Table): Attached directly to the Hub VCN DRG attachment. Overrides standard routing by forcing incoming packets entering the DRG to route directly to the Firewall Inspection NLB IP address.
2. DRG Transit Route Table: Forces all spoke-to-spoke and spoke-to-premises traffic to route into the Hub VCN attachment before reaching its final destination.
3. Implicit VCN Route Override: Subnet route tables inside spoke VCNs point default egress (0.0.0.0/0) to the DRG v2.

4. Operational Inspection Patterns

Pattern A: Spoke-to-Internet (North-South Inspection)

Spoke VM (10.1.1.5) $\rightarrow$ Spoke Subnet Route Table (0.0.0.0/0) $\rightarrow$ DRG v2 $\rightarrow$ Hub Ingress Route Table $\rightarrow$ Hub Ingress NLB $\rightarrow$ Firewall VM (Inspect) $\rightarrow$ Hub Internet Gateway $\rightarrow$ Internet.

Pattern B: Spoke-to-Spoke (East-West Inspection)

Spoke-Dev (10.1.1.5) $\rightarrow$ DRG v2 $\rightarrow$ Hub Ingress NLB $\rightarrow$ Firewall VM (Inspect) $\rightarrow$ DRG v2 $\rightarrow$ Spoke-Prod (10.2.1.50).

5. OCI Web Console (GUI) Step-by-Step Walkthrough

Follow these operational steps to build a Transit Hub Inspection VCN routing pipeline.

Step 1: Configuring the Ingress Route Table on Hub VCN

1. Open Navigation Menu (≡) ➔ Networking ➔ Virtual Cloud Networks ➔ Select VCN-Hub-Security.
2. Under Resources, click Route Tables ➔ Click Create Route Table.
3. Name: RT-Hub-Ingress-From-DRG
4. Compartment: Network-Compartment
5. Add Route Rule:
6. Target Type: Private IP
7. Destination CIDR Block: 0.0.0.0/0
8. Target Private IP: Enter private IP of NLB-Firewall-Ingress (10.0.1.50).
9. Click Create Route Table.

Console Path: [≡ Main Menu] ➔ [Networking] ➔ [VCNs] ➔ [Hub VCN] ➔ [Route Tables]

Step 2: Binding Ingress Route Table to DRG Attachment

1. Navigate to Dynamic Routing Gateways ➔ Select DRG-Hub-Ashburn.
2. Under Resources, click VCN Attachments.
3. Select the attachment for VCN-Hub-Security ➔ Click Edit.
4. Under VCN Ingress Route Table, select RT-Hub-Ingress-From-DRG.
5. Click Save Changes. All traffic entering the DRG destined for any spoke is immediately redirected to the firewall NLB.

Step 3: Configuring DRG Route Table for Spoke Inspection

1. Under Resources inside DRG-Hub-Ashburn, click DRG Route Tables.
2. Click Create DRG Route Table:
3. Name: DRG-RT-Spoke-Traffic
4. Add Static Route Rule:
5. Destination CIDR: 0.0.0.0/0
6. Next-Hop Attachment: Select VCN-Hub-Security.
7. Associate DRG-RT-Spoke-Traffic with all Spoke VCN Attachments.

6. Common Architectural Misconceptions & Pitfalls

Misconception 1: “Virtual Firewalls Can Route Traffic Without Enabling IP Forwarding”

• Reality: By default, Linux OS kernels and firewall VM shapes drop packets where the destination IP address does not match local interface IPs. You must enable IP Forwarding on the firewall instance’s primary and secondary VNICs inside the OCI Console (and set net.ipv4.ip_forward = 1 inside OS kernel settings).

Misconception 2: “Transit Routing Can Be Configured Using Local Peering Gateways (LPGs)”

• Reality: As detailed in Article 07, LPGs are strictly non-transitive. You cannot route spoke-to-spoke traffic through a central firewall hub using LPGs; attempting to do so will result in dropped packets. DRG v2 must be used for transit routing.

7. OCI Transit Routing vs. Other Cloud Platforms