Mastering OCI — DRG v2: Next-Level Networking for Cloud Environments (Scenario 1 — Hub and Spoke with OCI Native Firewall)
DRG version 2 provides the flexibility to create multiple route tables based on your complex networking requirements. In this post, I will guide you through the configuration steps required for a specific scenario.
A quick recap of the service:
Dynamic Routing Gateway (DRG) is a virtual router that allows you to connect your VCN (Virtual Cloud Network) to other networks, such as on-premises networks or other VCNs in OCI. The DRG provides a highly available and scalable solution for routing traffic between different networks.
If you would like to know more about dynamic routing gateways, refer to the documentation.
Also note that any new DRG provisioned will be of version 2. If you encounter an older version DRG, your OCI console will prompt you to upgrade it. Once you have provisioned DRG v2, it should appear as follows:
Your DRG attachments (i.e) networks connected to your router can be one of below.
- VCNs
- Virtual Circuits (Of Fastconnect)
- IPsec Tunnels
- Remote peering connections
- Cross tenancy attachments (For VCNs from a different tenancy)
Below are the default routes created automatically when DRG v2 is provisioned.
The DRG employs destination-based routing, meaning that ingress traffic from any attachment uses its associated route table within the DRG to reach its destination network.
- Autogenerated Drg Route Table for RPC, VC, and IPSec attachments — As the name suggests, this route table is intended for RPC, VC, and IPSec networks. It will only contain the CIDR addresses imported from VCNs.
- Autogenerated Drg Route Table for VCN attachments — This route table is meant for VCN attachments. It will import the network CIDR from all attachments.
These two routing tables are attached to RPC, VC, IPSec attachments, and VCN attachments, respectively, as shown in the diagram below.
By default, IPsec, FastConnect, and RPC attachments will learn all VCN routes. Additionally, VCN attachments will learn all IPsec, FastConnect, RPC, and other VCN CIDR ranges
Referring to the example:
Route Table 1: This route table will include all VCN CIDR ranges.
- 172.16.0.0/24 — VCN A
- 172.16.1.0/24 — VCN B
- 172.16.2.0/24 — VCN C
Route Table 2: This route table will include all CIDR ranges from all attachments.
- 172.16.0.0/24 — VCN A
- 172.16.1.0/24 — VCN B
- 172.16.2.0/24 — VCN C
- 10.0.0.0/16 — IPsec and FastConnect
Deep Dive — Complex routing scenarios
Scenario 1 (Hub & Spoke with OCI Network Firewall):
VCN A serves as a hub VCN, augmented by an OCI Network Firewall deployment. This firewall is responsible for inspecting the following types of traffic:
- North-South Traffic (Internet Bound): The firewall examines and monitors traffic flowing between the VCN and the internet. This includes inbound and outbound traffic to and from external networks, ensuring security measures are in place.
- East-West Traffic (Inter-VCN and On-Premises Datacenter): The firewall actively inspects and assesses the traffic within VCN A, as well as traffic between VCN A and other VCNs or an on-premises datacenter. This scrutiny safeguards the communication and data exchange between these interconnected environments.
Below is a reference architecture diagram.
Please watch the explanatory video below to understand how OCI’s native OCI Network Firewall inspects the mentioned flows within OCI.
Now that you have understood the flows, let’s explore the configuration process in the OCI console.
Assumption: Please note that I assume you are familiar with provisioning VCNs, subnets, IPsec, OCI Network Firewall, security lists, and network security groups. The instructions provided below are specifically for configuring the DRG routing table and the routing tables of the hub and spoke VCNs to create the architecture diagram mentioned above in the OCI console.
- DRG Routing tables:
Route Table -1 is associated to Ipsec and FastConnect (Virtual Circuit) attachments. The expected configuration for the route table is as follows.
Route Table — 2 is associated with VCN-B and VCN-C (spoke VCNs).
Route Table — 3 is associated with VCN-A (Hub VCN).
To enable automatic route downloads from all attachments except its own, this route table requires an import route distribution group. Please create an import route distribution group as illustrated below.
Then create route table -3, use above import distribution group policy.
2. Modifying Attachments:
Associate Route Table — 3 , created above to VCN-A (Hub VCN Attachment).
Associate Route Table — 2 , to both VCN-B and VCN-C (Spoke VCN Attachments)
Associate Route Table — 1, to IPsec attachments or Fastconnect — Virtual Circuits attachments.
Following the modification, the VCN Attachments and their associated DRG route tables will be presented as depicted below.
The IPsec Attachment and its associated DRG route table will be displayed as depicted below.
3. VCN- A (HUB VCN) Routing
Create a Transit RT (Routing Table) that directs incoming traffic to the OCI Firewall. For reference, please see the screenshot provided below.
Please take note that the default route (0.0.0.0/0) directs all incoming traffic to the OCI firewall. In order for LBaaS traffic to also pass through the OCI firewall, a second route (172.16.0.128/25) is added. It’s important to include this second route; otherwise, the return traffic to LBaaS will bypass the OCI firewall using its implicit route table.
Associate this Transit RT, to the DRG Attachment as depicted below.
Create a NAT Transit route to ensure that reverse internet traffic from the Spoke VCNs (VCN-B and VCN-C) is directed back to the firewall. This route will facilitate the proper routing of traffic.
Associate the above routing table to the NAT Gateway, of the VCN-A (Hub VCN).
Create a Public subnet route table, with following route entries.
Associate the Public-RT to Hub VCN public subnet.
Create a Private subnet — route table, as depicted below.
Associate the Private-RT to Hub VCN Private subnet.
4. Spoke VCN Routing.
The spoke VCNs (VCN-B and VCN-C) will only have one route table, that will get associated to all its subnets.
Note: A default route is pointed to DRG. However, if you prefer to bypass services gateway traffic from the firewall, you can choose to add an additional route pointing to the SGW (Service Gateway). This configuration will remain the same for other spoke VCNs.
Assuming that the firewall policies, VCN security lists, and Network Security Groups have been properly configured, you should now have an OCI Firewall capable of inspecting traffic from all four directions, thanks to the assistance of DRG v2.
You may also watch this video demo to see it in action!
Credit:
Special thanks to James George for his review, and feedback :)
