Mastering OCI — DRG v2: Next-Level Networking for Cloud Environments (Scenario 2-Network Isolation)
In my previous blog post, we explored the configuration of Dynamic Routing Gateway (DRG v2), Hub and Spoke VCN route-tables to enable traffic inspection through OCI Network Firewall. Building upon that, in this article, we delve into a use case that demands network isolation.
Network Isolation for varied Use Cases:
Certain organizations, Independent Software Vendors (ISVs) hosting their solutions in OCI, often necessitate segregated or isolated networks for their clients within OCI. Similarly, large enterprises frequently aim to segregate their production and pre-production workloads. These requirements can quickly become complex, particularly when there is a need to connect additional networks, such as an on-premises data center or another VCN that hosts shared resources like an antivirus management server, DNS, or AD servers. In the following sections, we will explore how DRG v2 can effectively fulfill these network isolation requirements.
Achieving Network Isolation with DRG v2:
Dynamic Routing Gateway (DRG v2) plays a critical role in enabling network isolation within OCI, allowing organizations to create secure and isolated networks that align with their specific use cases. With its destination-based routing capabilities, DRG v2 empowers administrators to configure route tables for various components such as VCN, Fastconnect, Ipsec, RPC, and cross-tenancy attachments. By exerting control over the destination networks these attachments can reach, network isolation can be effectively achieved. This concept can be loosely compared to the Virtual Route Forwarding (VRF) technique. Now, let’s delve into the reference architecture, and understand how to accomplish this.
Reference Architecture:
The following reference architecture outlines the key components and configuration necessary to achieve network isolation using DRG v2:
The following VCNs have been created based on the above architecture. We have two hubs, one for production and one for pre-production. Additionally, there are two spoke VCNs, one for production and one for pre-production, which are exclusively connected to their respective hubs.
Two IPsec VPN connections have been established and terminated to two on-premises data centers known as Onprem-A and Onprem-B.
Two highly available tunnels for Onprem-A is configured.
Two highly available tunnels for Onprem-B is configured.
Assumption: Please note that I assume you are familiar with provisioning VCNs, subnets, Highly available IPsec VPN, 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.
Before understanding the required configuration, let us understand the network flows.
North — South access flow
Ingress internet access to both prod and pre-prod application hosted in spoke VCN’s
East — West access flow
Access from on-prem data-centers to prod and pre-prod application.
In this particular scenario, which builds upon the concepts discussed in my previous blog post titled “Mastering OCI — DRG v2: Next-Level Networking for Cloud Environments (Scenario 1 — Hub and Spoke with OCI Native Firewall)” both North-South and East-West access flows exhibit similarities.
Below are the differences:
- In this use case, we encounter multiple hubs within the network architecture. Each spoke is permitted to send traffic exclusively through its respective hub.
- It is important to note that these hubs remain unaware of the presence of other hub and spoke networks within the environment.
- In certain scenarios, you might have a VCN, such as a Management VCN, or On-premises Fastconnect links that require access to all spokes through their respective hubs.
- There are also cases where both the VCN (e.g., Management VCN) and On-premises Fastconnect connections are segregated and allowed access its respective workloads (be it Prod / Pre-prod)
The flow for this specific scenario is also elaborated in the above East — West access flow video.
Now, let’s examine the necessary configuration steps with DRG v2 to achieve the desired flow. It’s important to note that the Hub VCN requires a transit routing table for its DRG Attachment and NAT Gateway. Additionally, the subnet routing tables of the Hub VCN need to be appropriately configured. Similarly, the spoke VCNs should have a default route pointing to the DRG. These specific configuration steps were covered in the scenario-1 blog post, and thus, I am not repeating them in this post.
DRG v2 Configuration:
- Below are the VCN attachments.
- Production (Prod) Hub VCN
- Pre-Production (Pre-Prod) Hub VCN
- Prod Spoke VCN
- Pre-Prod Spoke VCN
2. Below are the IPsec attachments.
- Onprem A Datacenter
- Onprem B Datacenter
3. Below are the DRG route tables
IPsec_RT
This route table is associated with the IPsec attachments. It routes traffic originating from the Onprem datacenters to the destination network based on the specified route entries. When Onprem traffic reaches the DRG, this route table determines the destination network and forwards it to the next hop, which is either the Prod or Non-Prod hub attachment.
Non_Prod_Hub_Rt
This route table is associated with the Non-Prod Hub VCN attachment. It routes traffic coming from the Non-Prod Hub to the destination network based on its entries. The route table imports a distribution list, without any static route entries.
Let’s take a closer look at the “Non-Prod” Import route distribution. This import distribution policy ensures that the Non-Prod Hub route table learns networks behind the Ipsec attachment and the Non-Prod Spoke VCN attachment exclusively.
Prod_Hub_Rt
This route table is associated with the Prod Hub VCN attachment. It routes traffic originating from the Prod Hub to the destination network based on its entries. Similar to the Non-Prod Hub route table, it only imports a distribution list without any static route entries.
Let’s examine the “Prod-Hub” Import route distribution. This import distribution policy allows the Prod Hub route table to learn networks behind the Ipsec attachment and the Prod Spoke VCN attachment exclusively.
Non_Prod_Spoke_Rt
This route table is associated with the Non-Prod Spoke VCN attachment. It routes traffic coming from the Non-Prod Spoke VCN to the destination network based on its entries. It includes a single default route pointing to the Non-Prod Hub VCN attachment.
Therefore, any traffic originating from the Non-Prod spoke attachment will be routed to the Non-Prod Hub VCN attachment.
Prod_Spoke_Rt
This route table is associated with the Prod Spoke VCN attachment. It routes traffic originating from the Prod Spoke VCN to the destination network based on its entries. Similar to the Non-Prod Spoke route table, it contains a default route pointed to the Prod Hub VCN attachment.
This means that any traffic originating from the Prod spoke attachment will be routed to the Prod Hub VCN attachment.
Let’s consider the scenario where Onprem-A should have access only to the Prod environment, and Onprem-B should have access only to the Pre-Prod environment.
Please note that achieving workload separation for different on-premises networks necessitates the use of multiple paths to connect to the on-premises environment. It is not possible to rely on a single onramp network, such as FastConnect or IPsec, to provide segregated access. To ensure proper segregation, organizations must establish distinct and independent connections for each on-premises network they wish to separate.
To achieve this, the following routing changes are required in DRG v2:
- Create a DRG route table for IPsec attachments. Associate the Onprem-A attachments with a route table containing the following entries:
Onprem-A route entries: By configuring the routes as shown above, Onprem-A attachments will only route traffic destined for the Prod hub and its associated spokes. Non-Prod networks will be hidden from Onprem-A.
2. Similarly, create a DRG route table for Onprem-B attachments. Associate the Onprem-B attachments with a route table containing the following entries:
Onprem-B route entries: Onprem-B attachments will not learn routes to the Prod networks. They will only accept traffic destined for the Non-Prod hub and its associated spokes.
3. Update the Non-Prod Hub and Prod-Hub route tables to use a different import distribution group:
Non-Prod-Hub-v2 distribution group: Configure this group to accept only Onprem-B tunnels and Non-Prod VCN spokes.
Prod-Hub-v2 distribution group: Configure this group to accept Onprem-A tunnels and Prod VCN spokes.
4. Finally, associate the IPsec attachments with their respective DRG route tables, as depicted in the provided screenshot.
Additionally, update the route import distribution policy for the Prod and Non-Prod Hub routing tables, as shown in the provided screenshot.
With these routing changes, Onprem-A will only have access to the Prod applications, while Onprem-B will only have access to the Non-Prod servers.
To see these changes in action, you can also refer to the video demo.
Thanks James George for his valuable peer review. I highly recommend following him for interesting posts.
