I recently needed an application running in one Oracle Cloud Infrastructure tenancy to reach MongoDB running privately in another tenancy. Both environments were in the Mumbai region, but they were isolated in separate Virtual Cloud Networks (VCNs).

The goal was straightforward:

Allow workloads in the main tenancy to reach MongoDB in the second tenancy over private IP addresses—without exposing MongoDB to the public internet.

The intended design uses OCI Local Peering Gateways (LPGs), cross-tenancy IAM policies, route rules in both directions, and a narrowly scoped MongoDB security rule.

This article records the architecture, the implementation order, and the networking lessons behind it.

Why Two Tenancy?

The practical reason was to separate the main ModusFocus application environment from the MongoDB host while working within the capacity and operational boundaries of the OCI setup.

This separation provides several useful boundaries:

• Independent ownership and lifecycle for the database network.
• Reduced blast radius between application and database infrastructure.
• Separate IAM administration and Terraform state.
• Private communication without assigning MongoDB a public IP address.

Cross-tenancy design does add coordination. Each tenancy owns its own routes, security rules, and LPG, and both must explicitly authorize the connection.

Understanding Local Peering Gateway

A simple real-life example

Imagine two secure office buildings owned by different companies. An employee in Building 1 needs a document stored in Building 2.

First, both companies sign an agreement allowing their buildings to connect—this is IAM authorization. A private corridor is then created between their gates—these are the two LPGs.

The employee’s parcel can leave only if the exit guard allows it—the Security List or NSG. The route table provides directions to the correct gate. At Building 2, another guard—the MongoDB NSG—accepts only approved parcels marked for port 27017. The parcel enters through MongoDB’s network door—the VNIC—and reaches MongoDB.

MongoDB’s reply uses the return route and travels back through the same private corridor.

In the diagram, the employee is the OKE application, the parcel is the database request, and Building 2 is the private MongoDB network. No traffic needs to use the public internet.

Implementation

LPG requirements and constraints

• Same region: both VCNs must be in the same OCI region. This setup uses
  ap-mumbai-1.
• No overlapping CIDRs: 10.0.0.0/16 and 10.20.0.0/16 do not overlap.
• One LPG on each VCN: a peering needs an LPG on each side.
• One relationship per LPG: an LPG cannot be reused for a second peering.
• Not automatically transitive: connecting VCN A to VCN B does not turn
  VCN B into a general route to other networks or the internet. Any advanced
  transit design requires its own explicit design.

Main Tenancy(Requestor) Infra and Resources

What each resource does

Resource	Simple purpose
Main VCN 10.0.0.0/16	The main tenancy’s private network.
OKE workload CIDR 10.0.10.0/24	Where application pods receive private IP addresses.
Main route table	Recognizes that 10.20.0.0/16 belongs to MongoDB’s VCN.
Main LPG	The private exit point from the main VCN towards the MongoDB VCN.
Requester IAM policy	Gives main-tenancy administrators permission to initiate the LPG connection.

In plain language:

1. An application pod wants to connect to MongoDB at 10.20.10.X:27017.
2. The pod sends the packet to its subnet’s route table.
3. The route table sees that 10.20.10.X belongs to 10.20.0.0/16.
4. It forwards the packet to the main LPG.
5. The LPG sends it over the private peering connection to the MongoDB tenancy.

The main tenancy does not open MongoDB directly. Its responsibility ends at sending the packet to the main LPG. The MongoDB tenancy must have its own return route and NSG rule before the connection can work end-to-end.

Policies

MongoDB Tenancy (Acceptor) Infra and Resources

Resource	What it does
Acceptor IAM policy	Gives the main-tenancy administrators permission to connect their LPG to this tenancy’s LPG.
Tenancy-2 LPG	Receives private traffic from the main tenancy and sends private response traffic back.
MongoDB private subnet	The private network area where the MongoDB compute instance runs.
Mongo NSG	The MongoDB server’s security gate. It allows only approved application traffic to the MongoDB port.
Mongo compute VNIC	The MongoDB server’s virtual network card—the network entry point to the server.
MongoDB service	The actual database process that receives application requests.
Return route table	Tells response packets how to travel back to the main tenancy through the tenancy-2 LPG.

Traffic flow

Main tenancy application
↓
Main LPG
↓
Tenancy-2 LPG
↓
Mongo NSG checks:
“Is this source allowed to use the MongoDB port?”
↓
Mongo compute VNIC
↓
MongoDB service

Simple way to remember the acceptor side

Think of the MongoDB tenancy as a secured office building:

Tenancy-2 LPG       = the building entrance
Mongo NSG            = the security guard
Mongo compute VNIC   = the office door
MongoDB service      = the database inside the office
Return route table   = the sign showing the way back out

Policies

Verification and Peering Establishment

Once the policies, security list are in place the VCN will be in peered state as shown below for both tenancy.

Requestor Main Tenancy

Acceptor Mongo Tenancy