3.2 OCI Network Gateways & Hybrid Connectivity

3.2 OCI Network Gateways & Hybrid Connectivity

[!NOTE] Core Exam Requirement: Understanding the specific use cases, traffic directionality, and routing targets of OCI's network gateways is essential for passing the 1Z0-1085-26 exam. Questions frequently present a business scenario (such as downloading patches without exposure, private database backups, or dedicated hybrid interconnects) and ask candidates to identify the correct gateway or connectivity method.

A Virtual Cloud Network (VCN) is isolated by default. To send traffic outside the VCN—whether to the public internet, internal Oracle Cloud platform services, other VCNs, or an on-premises enterprise datacenter—you must attach one or more specialized software-defined Network Gateways.

Gateways in OCI are completely virtualized, highly available, and managed by Oracle. They do not represent single physical servers or virtual appliances that you need to patch, scale, or manage for high availability.

---

The Five Essential OCI Network Gateways

Every OCI Foundations candidate must memorize the distinct role, traffic flow direction, and use case of each of the five core OCI gateways:

+--------------------------------------------------------------------------------+
|                       OCI Virtual Cloud Network Gateways                       |
+--------------------------------------------------------------------------------+
| Gateway Name             | Directionality      | Destination                   |
+--------------------------------------------------------------------------------+
| Internet Gateway (IGW)   | Inbound & Outbound  | Public Internet               |
| NAT Gateway              | Outbound-Only       | Public Internet               |
| Service Gateway (SGW)    | Outbound-Only       | Oracle Services Network       |
| Dynamic Routing GW (DRG) | Bidirectional       | On-Premises & Remote VCNs     |
| Local Peering GW (LPG)   | Bidirectional       | Peer VCN in SAME Region       |
+--------------------------------------------------------------------------------+

1. Internet Gateway (IGW)

• Functionality: An Internet Gateway (IGW) provides bidirectional (two-way) public internet connectivity.
• Subnet Relationship: Attached to the VCN and referenced exclusively by route tables associated with Public Subnets.
• Routing Rule: The route table specifies a default route target destination of 0.0.0.0/0 with the next hop set to the Internet Gateway.
• Requirements: For an instance to communicate via an IGW, it must reside in a public subnet, possess a public IP address (ephemeral or reserved), and have security list or Network Security Group (NSG) rules permitting the traffic.
• Typical Workloads: Public-facing websites, web application load balancers, and external API gateways.

2. Network Address Translation (NAT) Gateway

• Functionality: A NAT Gateway provides unidirectional, outbound-only internet connectivity for resources residing in Private Subnets.
• Inbound Blocking: The NAT Gateway strictly blocks all incoming network connections initiated from the public internet. External hosts cannot initiate any connection to private instances behind a NAT Gateway.
• Core Use Case (High-Frequency Exam Question): When backend database or application servers in a private subnet need to download operating system patches, pull software repository updates, or invoke third-party public web APIs, but enterprise policy forbids direct inbound internet exposure.
• Operational Feature: Administrators can temporarily toggle traffic on a NAT gateway to block all outbound traffic during an active security incident without deleting the gateway.

3. Service Gateway (SGW)

• Functionality: A Service Gateway (SGW) establishes a direct, private network path between your VCN and supported public OCI services—collectively known as the Oracle Services Network (OSN).
• Supported Services: OCI Object Storage, Autonomous Database, Container Registry (OCIR), Key Management Service (Vault), Streaming, and OCI Monitoring.
• No Public Internet Traversal: Traffic traversing a Service Gateway never leaves Oracle's internal network backbone fabric. It does not traverse the public internet.
• VCN-Initiated Only: Oracle documents that connections can be initiated only from the subnet. The Oracle service on the far side cannot open a connection back into your VCN through the Service Gateway, which is why the gateway is classified as outbound-only rather than bidirectional.
• No Public IPs or NAT Required: Compute instances in private subnets can interact with Object Storage buckets or Autonomous Databases without needing public IP addresses, an Internet Gateway, or a NAT Gateway.
• Service CIDR Labels: In the private subnet's route table, the destination is defined using a convenient service CIDR label instead of an IP range:
  • All <Region> Services In Oracle Services Network (allows access to all supported OCI public services in the region).
  • OCI <Region> Object Storage (restricts access strictly to OCI Object Storage).

4. Dynamic Routing Gateway (DRG)

• Functionality: A Dynamic Routing Gateway (DRG) is a virtual router that serves as the central hub for private hybrid cloud connectivity and inter-VCN peering.
• Hybrid Connectivity Hub: Connects a VCN to an on-premises datacenter or corporate branch office via:
  • Site-to-Site VPN (IPsec VPN)
  • OCI FastConnect
• Cross-VCN Peering Hub: Connects VCNs located in different regions (Remote VCN Peering) or multiple VCNs within the same region.
• DRG v2 Enhancements: Modern DRG capabilities support multi-attachment route tables and route distribution policies, allowing organizations to build sophisticated transit hub-and-spoke network architectures spanning dozens of VCNs and hybrid links.

5. Local Peering Gateway (LPG)

• Functionality: A Local Peering Gateway (LPG) enables two VCNs in the same OCI region to communicate directly using private IPv4/IPv6 addresses.
• Privacy and Isolation: Traffic flows entirely over the local OCI network infrastructure; packets do not traverse the public internet or pass through an on-premises router.
• Core Pre-Requisite: The two peered VCNs must not have overlapping CIDR blocks. If VCN A uses 10.0.0.0/16 and VCN B uses 10.0.0.0/16, peering cannot be established.
• Peering Mechanism: A peering relationship requires an LPG in each VCN, where one gateway acts as the requestor and the other as the acceptor. Both VCNs must update their respective route tables pointing to the peer LPG.

---

The Non-Transitive Routing Rule in OCI

A critical networking principle tested on OCI examinations is the non-transitive routing rule:

[!IMPORTANT] Non-Transitive Peering Principle: By default, peering connections in OCI are strictly non-transitive. Traffic cannot "hop" through an intermediate VCN to reach another network destination unless explicit hub-and-spoke transit routing is configured via a Dynamic Routing Gateway (DRG).

Non-Transitive Scenario Breakdown

1. VCN-to-VCN Peering: If VCN A is peered with VCN B via an LPG, and VCN B is peered with VCN C via an LPG, VCN A cannot communicate with VCN C through VCN B. To allow communication, a direct LPG peering must be established between VCN A and VCN C, or both must connect through a DRG hub.
2. Hybrid Transit Peering: If an on-premises datacenter connects to VCN A via a DRG, and VCN A is locally peered to VCN B via an LPG, on-premises traffic cannot traverse VCN A to reach VCN B by default. To achieve this transit routing, both VCN A and VCN B should attach directly to the DRG utilizing DRG route distribution tables.

---

Hybrid Cloud Connectivity: Site-to-Site VPN vs. FastConnect

When connecting an enterprise on-premises datacenter to OCI, organizations select between two primary technologies, both terminating on an OCI Dynamic Routing Gateway (DRG):

1. Site-to-Site VPN (IPsec VPN)

• Transport Medium: Carried over the public internet.
• Security: Traffic is encrypted using standard IPsec (Internet Protocol Security) tunnels, ensuring confidentiality and integrity across public network hops.
• High Availability by Default: For every Site-to-Site VPN connection, OCI automatically provisions two redundant IPsec tunnels with distinct OCI endpoint IP addresses on physically separated router infrastructure.
• Customer-Premises Equipment (CPE): In OCI, a CPE is a logical object representing the customer's on-premises physical router or virtual firewall device.
• Routing Options: Supports both BGP (Border Gateway Protocol) dynamic routing and static routing.
• Trade-Offs: Cost-effective and fast to deploy (minutes), but network throughput, jitter, and latency depend on unpredictable public internet traffic conditions.

2. OCI FastConnect

• Transport Medium: A dedicated, private physical network circuit connecting an on-premises network directly to OCI through a FastConnect telecommunications partner (e.g., Equinix, Megaport, AT&T) or direct cross-connect.
• Bypasses Public Internet: Traffic travels strictly across private fiber paths and never touches the public internet.
• Performance & Reliability: Delivers deterministic, consistent throughput, sub-millisecond latencies, and is backed by financially supported OCI Service Level Agreements (SLAs).
• Bandwidth Options: Standard port speeds of 1 Gbps, 10 Gbps, or multiples thereof up to 100 Gbps.
• Trade-Offs: Requires higher financial investment and longer lead times for telco provisioning, but essential for latency-sensitive transactional systems, massive database transfers, and core ERP integrations.

---

Comprehensive Gateway Comparison Reference

[!TIP] Quick Memory Hook for the Exam:

• Need instances in private subnets to download patches from the web? -> NAT Gateway
• Need instances to access Object Storage without internet/NAT? -> Service Gateway
• Need to connect on-premises via VPN or FastConnect? -> Dynamic Routing Gateway (DRG)
• Need two VCNs in the same region to talk privately? -> Local Peering Gateway (LPG)
• Need two-way public traffic for web users? -> Internet Gateway (IGW)