4.1 Network Security Controls, Route Tables & FastConnect

4.1 Network Security Controls, Route Tables & FastConnect

[!NOTE] Exam Blueprint Scope: In the OCI Foundations Associate (1Z0-1085-26) examination, network security and routing constitute vital elements of Domain 2 (Core OCI Services). Candidates must master virtual route tables, the operational distinctions between subnet-level Security Lists and VNIC-level Network Security Groups (NSGs), stateful versus stateless packet filtering, and dedicated enterprise connectivity via OCI FastConnect.

A well-architected cloud infrastructure requires fine-grained traffic routing and defense-in-depth packet inspection. Within Oracle Cloud Infrastructure (OCI), traffic flow is orchestrated through software-defined Route Tables, while network traffic security is enforced at two distinct virtualization layers: Security Lists (at the subnet boundary) and Network Security Groups (at the individual VNIC boundary). For enterprise hybrid architectures requiring dedicated, private physical connectivity that bypasses the public internet, OCI provides FastConnect.

---

Virtual Route Tables & Packet Routing Mechanics

In an OCI Virtual Cloud Network (VCN), packet routing is governed by software-defined Route Tables. While physical networks rely on distributed hardware switches and physical routers exchanging routing protocols, an OCI VCN utilizes virtual routing tables that intercept and evaluate all outbound traffic originating from attached compute instances, database nodes, and load balancers.

How Route Tables Operate

• Outbound Traffic Interception: Route tables control traffic leaving subnets. When an instance transmits a packet to a destination outside its immediate subnet, the OCI virtual network fabric consults the route table associated with that subnet.
• Route Rule Anatomy: Each route rule in a route table consists of two core attributes:
  1. Destination CIDR Block: The destination IP address range or service CIDR label (e.g., 0.0.0.0/0 for the default internet route, 192.168.0.0/16 for an on-premises datacenter, or All <Region> Services in Oracle Services Network).
  2. Target (Next Hop): The specific software-defined gateway or virtual network entity configured to forward the traffic. Supported targets include:
     • Internet Gateway (IGW): For public internet access from public subnets.
     • NAT Gateway: For outbound-only internet traffic from private subnets.
     • Service Gateway (SGW): For private communication to Oracle Services Network (e.g., Object Storage).
     • Dynamic Routing Gateway (DRG): For hybrid routing to on-premises networks (VPN/FastConnect) and remote VCN peering.
     • Local Peering Gateway (LPG): For private routing to another VCN within the same region.
     • Private IP: For routing traffic through a network virtual appliance (NVA) or third-party firewall.
• Longest Prefix Match (Most Specific Rule): If multiple route rules in a table match a packet's destination IP address, OCI strictly evaluates and applies the rule with the longest prefix match (the most specific CIDR mask). For example, if a route table contains 0.0.0.0/0 pointing to an Internet Gateway and 10.2.0.0/16 pointing to a Local Peering Gateway, traffic destined for 10.2.5.20 is routed to the Local Peering Gateway because /16 is more specific than /0.
• Subnet Association Rules:
  • Each subnet in a VCN can be associated with exactly one route table at any given time.
  • A single route table can be associated with multiple subnets.
  • Default Route Table vs. Custom Route Tables: Every newly created VCN includes a Default Route Table. If an administrator creates a subnet without explicitly specifying a custom route table, the subnet is automatically bound to the Default Route Table. In production architectures, best practice dictates creating dedicated custom route tables for public subnets (routing default traffic to an IGW) and private subnets (routing traffic to NAT and Service Gateways).

---

Subnet-Level Virtual Firewalls: Security Lists

A Security List functions as a virtual firewall deployed at the subnet level. It controls network traffic entering and exiting all compute instances and resources provisioned within that subnet.

Core Attributes of Security Lists

• Subnet-Wide Enforcement: When a security list is associated with a subnet, its firewall rules apply universally and automatically to every Virtual Network Interface Card (VNIC) in that subnet.
• Multiple Security Lists: A subnet can be associated with up to five security lists. When multiple security lists are attached, OCI combines their rules into a single logical union; if any rule across any attached list permits traffic, that traffic is allowed.
• Ingress and Egress Rules: Administrators define Ingress Rules (filtering inbound traffic by source CIDR, protocol, and destination port) and Egress Rules (filtering outbound traffic by destination CIDR, protocol, and destination port).
• Default Security List: Every VCN comes with a Default Security List that contains basic permissive rules: inbound SSH (TCP port 22) for Linux, RDP (TCP port 3389) for Windows, essential ICMP troubleshooting codes, and an egress rule permitting all outbound traffic (0.0.0.0/0).

Stateful vs. Stateless Security Rules

OCI Security Lists allow administrators to designate individual rules as either Stateful or Stateless:

+-----------------------------------------------------------------------------------------+
|                  Stateful vs. Stateless Packet Inspection in OCI                        |
+-----------------------------------------------------------------------------------------+
| Feature                     | Stateful Rules (Default)      | Stateless Rules           |
+-----------------------------------------------------------------------------------------+
| Connection Tracking         | Enabled in hypervisor         | Disabled entirely         |
| Return Traffic Handling     | Automatically allowed         | Must be explicitly defined|
| Egress Rule Required?       | No (for inbound requests)     | Yes (matching return rule)|
| Throughput / Scale          | High (standard enterprise)    | Extreme / Line-Rate       |
| Primary Workloads           | Web servers, DBs, APIs        | Big Data, HPC, Video/UDP  |
+-----------------------------------------------------------------------------------------+

1. Stateful Rules (Default):

   • When a rule is stateful, OCI's virtualization layer tracks the active connection state in memory.
   • When an inbound packet matches a stateful ingress rule, the response traffic sent back to the client is automatically permitted, regardless of any egress rules in place.
   • Conversely, when an outbound connection is initiated matching a stateful egress rule, the returning response packets are automatically admitted.
   • Stateful rules are the standard default and simplify firewall rule management for web servers, application servers, and relational databases.

2. Stateless Rules:

   • When a rule is marked stateless, connection tracking is completely bypassed.
   • Return traffic is never automatically permitted. To allow bidirectional communication, an administrator must explicitly configure an ingress rule for incoming packets AND a corresponding egress rule for the return response (specifying appropriate ephemeral source/destination ports).
   • Because no connection state is stored in memory, stateless rules eliminate connection table overhead in the virtual network layer.
   • Stateless rules are suited for ultra-high throughput, big data processing, high-performance computing (HPC) clusters, and low-latency UDP workloads (such as media streaming or high-frequency trading) that generate massive packet volumes capable of exhausting connection tracking tables.

---

VNIC-Level Virtual Firewalls: Network Security Groups (NSGs)

While Security Lists operate at the coarse boundary of an entire subnet, Network Security Groups (NSGs) represent OCI's modern, recommended approach to virtual firewall management by enforcing security directly at the VNIC level.

Decoupling Network Architecture from Security Posture

In traditional subnet-level security (Security Lists), all instances placed inside a subnet share identical firewall rules. If a public subnet contains both a public web server (requiring ports 80 and 443) and an administrative jump host (requiring SSH port 22), a Security List applied to that subnet exposes port 22 and ports 80/443 to both instances, violating least privilege.

Network Security Groups solve this architectural challenge by decoupling the VCN's subnet topology from its security posture:

• Administrators can assign different NSGs to different VNICs residing in the exact same subnet. The web server VNIC is associated with a "Web-NSG" permitting ports 80 and 443, while the jump host VNIC is associated with a "Bastion-NSG" permitting port 22.
• Conversely, VNICs located across different subnets (or even different VCNs) can be assigned to the same NSG.

Key Capabilities of Network Security Groups

• Direct VNIC Attachment: An NSG attaches directly to individual VNICs (or supported cloud resources such as Autonomous Databases, load balancers, and mount targets).
• Multiple NSGs per VNIC: A single VNIC can belong to up to five NSGs simultaneously.
• Self-Referential and Cross-NSG Rules: An NSG rule can specify another NSG as its source or destination rather than an IP CIDR block. For example, an administrator can define an ingress rule on a "Database-NSG" stating: Allow TCP port 1521 where Source = App-Tier-NSG. As application servers scale dynamically, their VNICs automatically inherit database access without updating IP address lists.
• Rule Coexistence (Defense-in-Depth): NSGs and Security Lists are not mutually exclusive; they can be used together. When both are applied to a VNIC, OCI evaluates the union of all rules across both mechanisms. If any rule in any attached Security List or NSG permits a packet, the packet is allowed.

---

Security Lists vs. Network Security Groups: Comprehensive Comparison

---

Dedicated Enterprise Interconnect: OCI FastConnect

When enterprise workloads require high-speed, dedicated hybrid connectivity between an on-premises datacenter and OCI that completely bypasses the public internet, organizations deploy OCI FastConnect.

Core Architecture and Benefits of FastConnect

• Private Physical Circuit: FastConnect establishes a direct, dedicated telecommunications circuit between an enterprise on-premises network and an OCI Dynamic Routing Gateway (DRG).
• Bypasses the Public Internet: Unlike Site-to-Site VPN, which encrypts traffic across unpredictable public internet routes, FastConnect traffic travels entirely across private physical fiber. Packets never touch the internet.
• Deterministic Performance & Low Latency: Because FastConnect avoids public routing hops and network congestion, it provides consistent, predictable, sub-millisecond latencies and high throughput.
• High Port Speeds: Organizations can order FastConnect in standard port speeds of 1 Gbps, 10 Gbps, or 100 Gbps increments.
• Financially Backed SLA: OCI backs FastConnect with an industry-leading 99.9% availability Service Level Agreement (SLA) covering availability, performance, and manageability.

FastConnect Connectivity Models

1. FastConnect via an Oracle Partner:
   • The customer connects to OCI through an authorized FastConnect telecommunications partner (such as Equinix, Megaport, AT&T, Verizon, or Lumen).
   • The partner already maintains redundant, high-capacity physical cross-connects into Oracle's cloud datacenters, enabling rapid provisioning (often within hours or days).
2. FastConnect Direct / Colocation:
   • The enterprise colocates their own routing hardware within the same physical datacenter facility as an OCI FastConnect location.
   • The customer orders a physical cross-connect fiber patch cable linking their router directly to Oracle's edge routing infrastructure.

FastConnect vs. Site-to-Site VPN Comparison