Hub and spoke using IP Masquerading in OCI aka Oracle Cloud Infrastructure

 In Oracle Cloud Infrastructure (OCI), the "hub and spoke" architecture is a common networking design used to connect multiple Virtual Cloud Networks (VCNs) in a centralized manner. This architecture is often implemented using Dynamic Routing Gateway (DRG) attachments and Transit Routing. Let me break down how it works:

Hub VCN: In the hub-and-spoke model, one VCN serves as the central hub where shared services or resources are located. This hub VCN typically hosts core services such as DNS, Active Directory, or shared databases.

Spoke VCNs: Spoke VCNs are additional VCNs that are connected to the hub VCN. Each spoke VCN usually contains resources specific to a particular department, application, or environment.

Dynamic Routing Gateway (DRG): The DRG serves as the central routing hub for connecting the hub VCN to other VCNs or on-premises networks. It facilitates the exchange of routing information between the hub VCN and the spoke VCNs.

DRG Attachments: Each spoke VCN is connected to the hub VCN via a DRG attachment. A DRG attachment establishes a logical link between the spoke VCN and the DRG, enabling traffic to flow between them.

Transit Routing: Transit Routing is a feature in OCI that allows you to route traffic between different VCNs using the hub-and-spoke architecture. With Transit Routing, you can configure route tables in the hub VCN to direct traffic between spoke VCNs through the hub VCN.

Route Tables: Each VCN has its own route table that determines how traffic is routed within the VCN. In the hub-and-spoke model, route tables in the hub VCN are configured to route traffic between spoke VCNs.

Security: Security within the hub-and-spoke architecture is typically managed using Security Lists, Network Security Groups (NSGs), and other OCI security features. Access control can be enforced at the subnet level to restrict traffic between different environments.

By implementing a hub-and-spoke architecture using DRG attachments and Transit Routing in OCI, organizations can achieve centralized network management, simplified connectivity between VCNs, and improved security and compliance. This architecture is well-suited for scenarios where multiple VCNs need to communicate with each other while maintaining isolation and security boundaries.

Now, the objective of this post is to explain, how leveraging DRG attachments and VCN Route tables we can make the communication between hub and spoke. And also, using transit route, how we can enable the resources provisioned inside spoke VCN to reach the internet using Hub VCN.

 

Present Architecture:-

Hub:-

Spoke1 VCN:-

Spoke2 VCN:-

The security list at this moment has ingress from spoke1 vcn cidr to spoke2 and vice versa.

I will now try to ping spoke2 instance from spoke1.

As expected, it is not working

Create a DRG:-

  

next, i am going to attach the 2 spokes

Now, under the route table for spokes VCN, we are going to add a new route

Ping is now working on both the side of spokes

The next requirement of this post, is that from spoke VCN, we want to reach to internet via Hub VCN. This will be done via transit route.

In the hub machine compute instance, i'll add a secondary vnic in the same subnet as primary vnic. The subnet is of public type and IGW is attached to it.

Under DRG, create anew distribution list for hub-vcn attachment

Create a new DRG route table for hub-vcn

 Attach the hub-vcn to DRG

Now create a VCN DRG route table and point it to private IP address of secondary vnic

Add a security list for this public subnet to receive request from spoke VCNs.

Security list for the spoke VCN. Add a ingress rule to receive request from hub vcn

Add the transit route to DRG

Now, make the nating on the hub-vcn compute instance

sysctl -w net.ipv4.ip_forward=1

firewall-cmd --permanent --direct --add-rule ipv4 nat POSTROUTING 0 \

  -o enp0s6 -j MASQUERADE

 

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-interface enp0s6

The interface is under control of NetworkManager, setting zone to 'public'.

success

[root@primary-vnic opc]# firewall-cmd --permanent --zone public --add-masquerade

 

[root@primary-vnic opc]# systemctl restart firewalld

[root@primary-vnic opc]# firewall-cmd --reload

success

[root@primary-vnic opc]#

sysctl -w net.ipv4.conf.all.rp_filter=2

added the route for secondary vnic

[root@primary-vnic opc]# ip route

default via 192.168.0.1 dev enp0s6

default via 192.168.0.1 dev enp0s6 proto dhcp src 192.168.0.49 metric 100

169.254.0.0/16 dev enp0s6 scope link

169.254.0.0/16 dev enp0s6 proto dhcp scope link src 192.168.0.49 metric 100

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49

192.168.0.0/26 dev enp1s0 proto kernel scope link src 192.168.0.57

192.168.0.0/26 dev enp0s6 proto kernel scope link src 192.168.0.49 metric 100

[root@primary-vnic opc]# ip route add 10.10.0.0/26 via 192.168.0.1 dev enp1s0

 

10.10.0.0/26 is the CIDR for spoke1 private subnet

 

Now, if I try to ping google.com from spoke1 vcn

Through this post, i just wanted to show how using IP Masquerading feature we can reach to the internet from the spoke VCN private subnet. Also, how this can be achieved under Hub & Spoke Model. I hope this post will help someone.