The objective of this lab was to establish secure connectivity between Hub and Spoke VCNs using a Dynamic Routing Gateway (DRG), validate communication between instances, and verify that software installed on a hardened source VM was successfully inherited by a new private instance created from a Custom Image.

Local Peering Gateway (LPG) was used to connect two VCNs within the same OCI region.

• Connects VCNs in the same region.
• Private communication between VCNs.
• No internet traffic involved.
• Simple VCN-to-VCN connectivity.

• Works only within the same region.
• Requires separate LPGs in each VCN.
• Not suitable for large-scale hub-and-spoke architectures.

VCN-A  <-- LPG -->  VCN-B

Dynamic Routing Gateway (DRG) is a virtual router used to connect VCNs with other OCI networks.

DRG supports:

• Hub-and-Spoke Architecture
• Remote Peering
• Site-to-Site VPN
• FastConnect
• Cross-region connectivity

• Supported Remote Peering Connections (RPC).
• Supported connectivity with on-premises networks.
• Limited routing capabilities.
• Less flexible route management.

• No advanced route distribution.
• No centralized routing design.
• Not ideal for complex architectures.

DRG Version 2 introduced advanced routing and route distribution capabilities.

• Supports same-region VCN connectivity.
• Supports cross-region VCN connectivity.
• Supports Hub-and-Spoke architecture.
• Multiple Route Tables.
• Route Distribution.
• Centralized network management.
• Better scalability.

Instead of using LPGs for same-region connectivity and RPCs for cross-region connectivity, a single DRG can now be used for both.

                 DRG
                  |
    --------------------------------
    |              |              |
 Hub VCN       Spoke VCN-1    Spoke VCN-2

• Public Subnet
• Bastion / Jump Server
• Public IP + Private IP
• Hardened Source Instance

• Private App Subnet
• Application Server
• No Public IP
• Created using Custom Image

                         Internet
                             |
                        Bastion VM
                       (Hub VCN)
                             |
                             |
                            DRG
                             |
                             |
                  -----------------------
                  |                     |
             Spoke VCN             App Subnet
                                       |
                               spoke-swiggy-vm-01

Created a Hub VCN containing:

• Public Subnet
• Bastion Jump Server
• Internet Access

Created a separate Spoke VCN containing:

• Private App Subnet
• No Public IP

Installed required software on the Bastion Server.

sudo dnf install -y httpd

sudo dnf install -y zip

sudo dnf install -y unzip

Created a custom image from the hardened Bastion Server.

Navigation:

Compute
→ Bastion Server
→ More Actions
→ Create Custom Image

Image Name:

bastion-jump-server-image

📸 Screenshot:

• Custom Image Creation

Hub VCN (10.0.0.0/24)
│
├── Public Subnet (10.0.0.0/25)
│      └── Bastion Jump Server
│
└── Private Subnet (10.0.0.128/25)

                │
                │
               DRG
                │
                │

Dev Spoke VCN (10.0.1.0/24)
│
├── App Subnet (10.0.1.0/26)
│      └── spoke-swiggy-vm-01
│
├── Future Subnet 1 (10.0.1.64/27)
│
└── Future Subnet 2 (10.0.1.96/27)

Allow communication to Spoke VCN:

Note: SSH access to the Bastion Server is restricted to a specific public IP (193.122.143.52/32) instead of allowing access from the entire internet (0.0.0.0/0).

Allow communication from Hub VCN:

Step 1: Create DRG Networking → Dynamic Routing Gateways→ Create DRG

Step 2: Attach Hub VCN to DRG

select the DRG that you have created by selecting the right compartment

Step 3: Attach Spoke VCN to DRG

Now if we go to Networking-> Customer connectivity->DRG-> select my DRG i.e Hub-Spoke-DRG-> Attachements

if we select the hub-network-compartment we can see the hub-vcn-attachment

if we select swiggy-dev-network-compartment we can see the spoke-swiggy-vcn-attachment

now we can say that the DRG has two VCN attachments: one attached to the Hub VCN and another attached to the Spoke VCN."

click on hub-public-subnet

click on hub-route-table

select DRG and in destination CIDR block give the CIDR of spoke app-subnet(select the CIDR of spoke app subnet from the network visualizer)

select DRG and in destination CIDR block give the CIDR of hub-public-subnet(select the CIDR of hub-public-subnet from the network visualizer)

Hub App Subnet Security List or in NSG : egress rule in hub public subnet security rule give the CIDR of app-subnet for ICMP

now ingress rule in app subnet security list give the CIDR of hub public subnet

ping is working fine

The Network Path Analyzer reported "Ingress access control: Security not applicable" because the traffic was already blocked at the source (Hub) egress security rules and never reached the destination security evaluation stage.

getting the below error

change the permission and it worked and I successfully logged in to spoke vm

chmod 600 newprivatekey.pem

Telnet is also working

Reverse Ping Validation from Spoke VM to Hub VM

Reverse ICMP connectivity from the Spoke VM to the Hub VM is not working and requires further troubleshooting.

now we have to check the incoming (Ingress) security list of hub public subnet

adding the private app subnet CIDR and protocol ICMP

now ping is working fine

To validate bidirectional communication, ICMP connectivity was also tested from the Spoke VM to the Hub Bastion Server.

ping 10.0.0.54

Result:

31 packets transmitted, 31 received, 0% packet loss

Validation Successful

This confirmed that routing and security rules were correctly configured in both directions between the Hub and Spoke VCNs.

unzip -v

zip -v

sudo systemctl status httpd

The validation confirms that all required software packages were successfully inherited from the source custom image to the Spoke VM.

While attempting SSH connectivity from the Bastion Server to the private Spoke VM, the session continuously hung and never established a connection.

Used OCI Network Path Analyzer to trace the network path.

Navigation:

Networking
→ Network Path Analyzer

Missing TCP egress rule in the Security List.

Added the required TCP egress rule and re-tested connectivity.

• Network Path Analyzer Result
• Security List Update

After fixing the routing and security issue, SSH still failed.

Error:

Permission denied (publickey)

Incorrect private key was being used.

Created a new PEM file and copied the correct private key content.

mkdir keys
cd keys
vi newprivatekey.pem
chmod 600 newprivatekey.pem

Successfully connected using:

ssh -i newprivatekey.pem [email protected]

• Successful SSH Login

From Bastion Server:

ping 10.0.1.30

Result:

0% Packet Loss

✅ Successful

ssh -i newprivatekey.pem [email protected]

Result:

[opc@spoke-swiggy-vm-01 ~]$

✅ Successful

A new private instance was launched using the custom image created from the hardened Bastion Server.

Instance Name:

spoke-swiggy-vm-01

rpm -qa | grep httpd

Result:

httpd
httpd-core
httpd-tools
httpd-filesystem

✅ Successful

zip -v

✅ Successful

unzip -v

✅ Successful

rpm -qa | egrep 'httpd|zip|unzip'

Result:

httpd packages found
zip package found
unzip package found

✅ Software successfully inherited from Custom Image

Bidirectional connectivity between the Hub and Spoke VCNs was successfully established and validated using ICMP (Ping), TCP (Telnet), and SSH connectivity tests through the DRG." 🚀

✅ Spoke VM → Hub VM ICMP Working ✅ Hub VM → Spoke VM ICMP Working ✅ DRG Routing Working in Both Directions ✅ Security Lists Correctly Configured ✅ Bidirectional Connectivity Verified

Successfully implemented a Hub-and-Spoke architecture using OCI DRG Version 2. Established secure connectivity between Hub and Spoke VCNs, validated routing and security configurations, resolved connectivity issues using Network Path Analyzer, and verified successful software inheritance by creating a Custom Image from a hardened Bastion Server and deploying a private application server from that image.

This implementation demonstrates OCI networking, routing, DRG connectivity, custom image management, troubleshooting, and validation of software inheritance in a secure private environment.