OCI Service Connector Hub: Move Logs from OCI Logging to Object Storage

Oracle Cloud Infrastructure provides centralized logging through the OCI Logging service. Logs are very useful for troubleshooting, auditing, security review, and operational analysis. However, in many real-time environments, we may need to retain logs for a longer period, store them in a centralized location, or keep them for compliance and future analysis.

The Logs could be VCN Flow Logs, Load balancer Logs, API Gateway logs, Object storage logs or any custom logs. By doing this we can store logs beyond the default log retention period. OCI Object storage is perfect location to store logs and even we can store logs in the archive storage to reduce the cost.

OCI Connector Hub helps to move data between OCI services. It can move log data from OCI Logging to targets such as Object Storage, Streaming, Logging Analytics, Monitoring, Functions, and Notifications. For this article, we will configure a connector to move logs from OCI Logging to OCI Object Storage.

Prerequisites

Before starting this activity, make sure the following resources are available:

• OCI tenancy access
• Required compartment
• OCI Logging enabled for any OCI service
• Object Storage bucket
• Permission to create Service Connector Hub connector
• Permission to read logs and write objects into Object Storage

 

Step 1: Create Object Storage Bucket

First, we will create an Object Storage bucket to store archived logs.

Open the OCI Console.

Go to:

Storage → Object Storage & Archive Storage → Buckets

Choose the correct compartment and click Create Bucket, provide a bucket name.

Example:

oci-logging-archive-bucket

Keep the default storage tier as Standard unless Archive Storage is specifically required.

Click Create.

After the bucket is created, open the bucket and confirm that it is empty.

Step 2: Identify the Source Log in OCI Logging

Now we need to identify the log that we want to move into Object Storage.

Go to:

Observability & Management → Logging → Logs

Select the correct compartment.

Review the available log groups and logs.

For this article, select the log group and log that need to be archived.

Example:

Log group : VCN_Flow_logs

Log Name: VCN_Flow_Log_1

Open the log and confirm that log records are available.

Step 3: Create Service Connector

Now we will create the Service Connector.

Go to:

Analytics & AI → Messaging → Connector Hub

Click Create Connector.

Provide a connector name.

Example:

logging-to-object-storage-connector

Select the compartment where the connector should be created. Under Configure connector, select:

Source: Logging
Target: Object Storage

 

Step 4: Configure Source Connection

In the source connection section, select the log details.

Choose:

Compartment: <compartment where log exists>
Log Group: <log group name>
Logs: <log name>

If needed, we can add multiple logs by using the Another Log option.

For this article, we are selecting one log.

Step 5: Optional Filter Configuration

Service Connector Hub also allows filtering the log data before sending it to the target. This is useful when we do not want to archive every log record.

For example, in VCN Flow Logs, we may want to move only rejected traffic logs.Example filter idea:

data.action = 'REJECT'

For this article, we will not apply any filter. We will move all selected log records to Object Storage.

Step 6: Configure Target Connection

In the target connection section, select the Object Storage bucket.

Choose:

Compartment: <bucket compartment>
Bucket: oci-logging-archive-bucket

This is where the log files will be stored.

Step 7: Create Required Policy

While creating the connector, OCI may prompt us to create the required policy.

If prompted, click Create.

This policy allows the Service Connector to read from OCI Logging and write objects into the selected Object Storage bucket. By clicking Create button a policy statement gets created with below statement.

allow any-user to manage objects in compartment id ocid1.compartment.oc1..aaaaaaaa where all {request.principal.type='serviceconnector', target.bucket.name='oci-logging-archive-bucket', request.principal.compartment.id='ocid1.compartment.oc1..aaaaaaaaj'}

If the user is part of the Administrators group, this may already be allowed. Otherwise, proper IAM policies are required.

Step 8: Verify Connector Status

After the connector is created, open the connector details page.

Verify the connector status.

The connector should show as active.

Review the following details:

Source: Logging
Target: Object Storage
Status: Active

Step 9: Generate Log Activity

Now we need to generate some log activity.

The activity depends on the source log selected.

Examples:

For VCN Flow Logs:

• Connect to a compute instance
• Run ping, SSH, curl, or any network traffic
• Generate accepted or rejected traffic based on security rules

For Load Balancer Logs:

• Access the load balancer endpoint

For Object Storage Logs:

• Upload or download an object

Wait for a few minutes for logs to be processed and delivered.

 

Step 10: Validate Logs in Object Storage

Go to:

Storage → Object Storage & Archive Storage → Buckets

Open the bucket:

oci-logging-archive-bucket

Check whether log objects are created. We should see objects created by the Service Connector.

Open the object and review the content.

The logs are usually delivered in structured format, and the object names are automatically generated.

 

Step 11: Download and Review the Log File

Download the log files from Object Storage.

Open the file in a text editor.

Review the log records.

Example fields may include:

datetime
logContent
data
source
type
oracle

 Example:

{"id":"de9bb2f0","time":"2026-05-25T17:18:56Z","oracle":{"compartmentid":"ocid1.compartment.oc1..aaaaaaaaj7vcmtjkoungbmz5x3o2di56ewryi54vcoj5e5qsas4r7h52fxiq","filterOcid:":"DEFAULT_CAPTURE_FILTER","ingestedtime":"2026-05-25T17:20:41.335Z","instanceOcid:":"VNICaaS:ocid1.vnic.oc1.iad.abuwcljtazluubqqhm7jz6vbd6ri2kz2e3jkyvqj6m6tbej2exo4znzrfohq","loggroupid":"ocid1.loggroup.oc1.iad.amaaaaaaq444raaanpcwllthfwrfc3cllmuvrqb5nbs37ahx2bbtwzjggxpq","logid":"ocid1.log.oc1.iad.amaaaaaaq444raaa5f6vthyw6ev647d4zfg367yfrkxd4susqlhr75jeidma","managed":"true","resourceId":"ocid1.privateendpoint.oc1.iad.aaaaaaaael4mvgs4m5connq4c2yfpvl7rcdkhwhdpbkovflfbs3ykkz5tpka","resourceType":"PrivateEndpoint","tenantid":"ocid1.tenancy.oc1..aaaaaaaacq5gprsqz26em4koaokcntrpey4adi7mzzgve53cm44ozbxa4z4a","vcnOcid":"ocid1.vcn.oc1.iad.amaaaaaaq444raaaffljepgvsc4dbzvq7cq4xeh7ufc76hmagrsqae4zhlvq","vniccompartmentocid":"ocid1.compartment.oc1..aaaaaaaaj7vcmtjkoungbmz5x3o2di56ewryi54vcoj5e5qsas4r7h52fxiq","vnicocid":"ocid1.vnic.oc1.iad.abuwcljtazluubqqhm7jz6vbd6ri2kz2e3jkyvqj6m6tbej2exo4znzrfohq","vnicsubnetocid":"ocid1.subnet.oc1.iad.aaaaaaaaazzsdkncfvrvco6vbt5ctxwzz22gmqfh7uwlldmxa732phlzg3ma"},"source":"-","specversion":"1.0","subject":"-","type":"com.oraclecloud.vcn.flowlogs.QualityEvent.NoData","data":{"flowid":"de9bb2f0","version":"2","status":"NODATA","startTime":1779729536,"endTime":1779729597}}

 

The exact fields depend on the OCI service log type. This confirms that logs are successfully moved from OCI Logging to Object Storage.

 

 Resolve Private DNS Hostnames Across Cross-Tenancy Peered OCI VCNs

In the previous article, we created private connectivity between two OCI tenancies using cross-tenancy VCN peering through DRG. We used this setup to allow an Autonomous Database in one tenancy to communicate privately with a VM database in another tenancy.

In this article, we will extend that setup and configure private DNS resolution across the peered VCNs. Private network connectivity allows resources to communicate using private IP addresses, but hostname resolution across VCNs or tenancies does not always work automatically. For applications and database connections, using hostnames is often better than using hardcoded private IP addresses.

In this setup, we will have instances in different tenancies. The details are as below. We have two VCNs connected using cross-tenancy VCN peering through DRG.

Component	Value
Source VCN	DBSource
Source VCN CIDR	192.168.0.0/16
Source hostname	windows-instance.sub05070237210.dbsource.oraclevcn.com
Source private IP	192.168.0.213
Destination VCN	DBVCN
Destination VCN CIDR	10.0.0.0/16
Destination hostname	db19c.sub05052324220.dbvcn.oraclevcn.com
Destination private IP	10.0.0.169
Connectivity	Cross-tenancy VCN peering through DRG

The requirement is:

windows-instance.sub05070237210.dbsource.oraclevcn.com

should be able to resolve:

db19c.sub05052324220.dbvcn.oraclevcn.com

to:

10.0.0.169

High-Level Architecture

The private DNS resolution flow will look like this:

Windows instance in DBSource VCN
        |
        | DNS query for db19c.sub05052324220.dbvcn.oraclevcn.com
        
DBSource VCN Resolver
        |
        | Resolver rule forwards dbvcn.oraclevcn.com queries
        
DBSource Forwarding Endpoint
        |
        | Cross-tenancy DRG peering
        
DBVCN Listening Endpoint
        |
        | Resolves using DBVCN private DNS view
        
db19c.sub05052324220.dbvcn.oraclevcn.com → 10.0.0.169

Prerequisites

Before configuring Private DNS, we need to make sure the following are already in place:

• Cross-tenancy VCN peering through DRG is configured between DBSource and DBVCN.

• Route tables allow traffic from 192.168.0.0/16 to 10.0.0.0/16.

• Route tables allow return traffic from 10.0.0.0/16 to 192.168.0.0/16.

• Security lists or NSGs allow DNS traffic between the resolver endpoint subnets.

For DNS communication we can allow only UDP port 53 and TCP port 53, as both protocols are required.

 Step 1: Confirm Source and Destination Hostnames

First, confirm the private hostnames and private IP addresses.

Source Instance

Source instance details:

VCN: DBSource
Hostname: windows-instance.sub05070237210.dbsource.oraclevcn.com
Private IP: 192.168.0.213

Destination Instance

Destination VM database details:

VCN: DBVCN
Hostname: db19c.sub05052324220.dbvcn.oraclevcn.com
Private IP: 10.0.0.169

Before Private DNS forwarding is configured, we may be able to reach the destination private IP if routing and security are correct:

Test-NetConnection 10.0.0.169 -Port 1521

But hostname resolution may fail:

nslookup db19c.sub05052324220.dbvcn.oraclevcn.com

Step 2: Create a Listening Endpoint in Destination VCN DBVCN

Since the hostname belongs to the destination VCN, create a listening endpoint in DBVCN.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBVCN
→ DNS Resolver

→ Choose Endpoints in DNS resolver page.

→ Create Endpoint

Select:

Endpoint type: Listening
VCN: DBVCN
Subnet: Select a private subnet in DBVCN
Endpoint IP: Auto-assigned or manually selected

After the endpoint is created, note the listener endpoint IP address. This IP address will be used in the resolver rule in the source VCN.

 Also create a Private view. In the DBVCN private resolver, open Associated private views and ensure the DBVCN private view is associated with the resolver. This allows the DBVCN listener endpoint to resolve private DNS records that belong to the DBVCN DNS domain.

Choose DBVCN as Private view and click Save changes.

Step 3: Create a Forwarding Endpoint in Source VCN DBSource

Now create a forwarding endpoint in the source VCN DBSource.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBSource
→ DNS Resolver

→ Endpoints
→ Create Endpoint

Select Endpoint type: Forwarding
VCN: DBSource
Subnet: Select a private subnet in DBSource
Endpoint IP: Auto-assigned or manually selected

Click Create Endpoint Button.

As the next step, create resolver rule.

Step 4: Create a Resolver Rule in DBSource

Now create a resolver rule in the source VCN resolver. This rule forwards DNS queries for the destination VCN domain to the DBVCN listening endpoint.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBSource
→ DNS Resolver
→ Rules
→ Create Rule

Create a forwarding rule:

Click Add Rule button.

In Match condition, Rule Condition: Domains
Domain: dbvcn.oraclevcn.com

Rule:

Action: Forward
source Endpoint: The forward endpoint created in last step.
Destination IP:  It is the IP of Listener endpoint we created in Destination VCN.

Click Save Changes.

Step 5: Validate DNS Resolution from Source Windows Instance

Log in to the source Windows instance:

windows-instance.sub05070237210.dbsource.oraclevcn.com

Run:

nslookup db19c.sub05052324220.dbvcn.oraclevcn.com

In case we need this hostname resolution in reverse way then we need to create Listener endpoint at source and Forwarder endpoint.

 

Create a Database Link from OCI Autonomous Database to a VM Database in a Different Tenancy

In the previous article, we discussed creating VCN peering between two OCI tenancies in the same region. In this article, we will use the same private networking setup to create a database link from an Oracle Autonomous Database to an Oracle Database running on a VM DB System in a different OCI tenancy. Since VCN peering is already configured between the two tenancies, the database traffic can use private networking instead of traveling over the public internet.

This is a common requirement when organizations manage workloads across multiple OCI tenancies. For example, one tenancy may host an Autonomous Database used for reporting or integration, while another tenancy may host an Oracle Database running on a VM DB System.

Oracle Autonomous Database supports private endpoints, which allow traffic to and from the database to remain within the OCI private network. To route outbound connections through the private endpoint, we need to set the ROUTE_OUTBOUND_CONNECTIONS database property.

 

Item	Example Value
Source tenancy	Tenancy hosting Autonomous Database
Target tenancy	Tenancy hosting VM DB System
Source database	Autonomous Database with private endpoint
Target database	Oracle Database on VM DB System
Source VCN CIDR	192.168.0.0/16
Target VCN CIDR	10.0.0.0/16
Target VM DB private IP	10.0.0.169
Target listener port	1521
Connection type	Private cross-tenancy OCI networking

Create an Autonomous Database in the source tenancy and a standalone Oracle Database on a compute VM in the target tenancy.
On the VM database server, ensure that the listener is running and that the pluggable database service is registered with the listener.

lsnrctl status

Confirm the listener is listening on the expected private IP and port.

Example:

HOST = 10.0.0.169
PORT = 1521

From the VM database server, verify the database service name.

show parameter service_names;

Or check listener services:

lsnrctl services

[oracle@db19c ~]$ lsnrctl status

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 23-MAY-2026 01:53:09

Copyright (c) 1991, 2025, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.0.0.169)(PORT=1521)))

STATUS of the LISTENER

------------------------

Alias                     LISTENER

Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production

Start Date                23-MAY-2026 01:51:16

Uptime                    0 days 0 hr. 1 min. 52 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /u01/app/oracle/product/19c/dbhome_1/network/admin/listener.ora

Listener Log File         /u01/app/oracle/diag/tnslsnr/db19c/listener/alert/log.xml

Listening Endpoints Summary...

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.0.0.169)(PORT=1521)))

  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Services Summary...

Service "513276ca6910454ae06500001727baf7" has 1 instance(s).

  Instance "ORCL", status READY, has 1 handler(s) for this service...

Service "ORCL" has 1 instance(s).

  Instance "ORCL", status READY, has 1 handler(s) for this service...

Service "ORCLXDB" has 1 instance(s).

  Instance "ORCL", status READY, has 1 handler(s) for this service...

Service "orclpdb" has 2 instance(s).

  Instance "ORCL", status READY, has 1 handler(s) for this service...

The command completed successfully

 

Create a Test User in the Target Database

Connect to the target VM database and create a test user.

CREATE USER test IDENTIFIED BY "<YourPasswordHere>";
GRANT CREATE SESSION TO test;
CREATE TABLE test.db_link_test (
    id NUMBER,
    description VARCHAR2(100)
);
INSERT INTO test.db_link_test VALUES (1, 'DB link test from Autonomous Database');
COMMIT;

Confirm Autonomous Database Uses Private Endpoint

In the OCI Console, open the Autonomous Database and verify that it is configured with a private endpoint.

The private endpoint should be placed in the source VCN/subnet that has peering & routing to the target VM DB VCN. The private endpoints allow Autonomous Database traffic to stay off the public internet.

Set Outbound Routing Through Private Endpoint

Connect to Autonomous Database as ADMIN and execute below SQL command.

Kindly note the Autonomous database network connection has been set to Private endpoint access only.  To execute SQL commands, we can invoke SQL Developer web  console from Database Actions in Autonomous database console.

 

In SQL developer web console, provide username as Admin and its password and login into the console.

Execute below command.

ALTER DATABASE PROPERTY SET ROUTE_OUTBOUND_CONNECTIONS = 'PRIVATE_ENDPOINT';

This setting routes outbound connections from Autonomous Database through the private endpoint.

SELECT property_name, property_value
FROM database_properties
WHERE property_name = 'ROUTE_OUTBOUND_CONNECTIONS';

Expected result:

ROUTE_OUTBOUND_CONNECTIONS    PRIVATE_ENDPOINT

Test Network Reachability from Autonomous Database

Create credential at Autonomous database for VM database.

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'VMDB_CRED',
    username        => 'TEST',
    password        => 'YourPasswordHere'
  );
END;
/

From Autonomous Database, use DBMS_CLOUD_ADMIN to test whether the target host and port are reachable.

BEGIN
  DBMS_CLOUD_ADMIN.CREATE_DATABASE_LINK(
    db_link_name     => ‘<DB_LINK_NAME>’,
    hostname         => ‘<VM_DB_Hostname>’,
    port             => '1521',
    service_name     => ‘<PDB_SERVICE_NAME>’,
    credential_name  => 'VMDB_CRED',
    directory_name   => NULL,
    private_target   => TRUE
  );
END;
/

The database link requires a hostname in the hostname argument. In this setup, the target VM database private IP is 10.0.0.169. Since Autonomous Database may not resolve the VM hostname by default, create a private DNS zone in the VCN associated with the Autonomous Database private endpoint and add an A record for the VM database hostname.

Query the Target Database Through the DB Link

Run a simple query from Autonomous Database:

SELECT *
FROM test.db_link_test@VMDB_LINK;

Expected result:

ID   DESCRIPTION
1    DB link test from Autonomous Database

 

In this article, we created a database link from an OCI Autonomous Database to a VM database located in a different OCI tenancy using private networking. The key requirements are cross-tenancy VCN peering, correct route table and security rule configuration, an Autonomous Database private endpoint, outbound routing through the private endpoint, private DNS hostname resolution, and a valid database credential. After these components were configured, the Autonomous Database was able to query the target VM database through the database link successfully.

Cross Connect Across OCI Tenancies through VCN Peering

In OCI, workloads are often distributed across different tenancies for reasons such as organizational separation or project isolation. In such cases, there may still be a requirement for private communication between resources hosted in separate tenancies. We will see how we can make the cross connectivity across regions.

In this exercise the tenancies are in the same region. We have used DRG to make the connectivity between them. Since both VCNs are in the same OCI region, this exercise uses a cross-tenancy VCN attachment to a DRG. RPC is used for DRG-to-DRG remote peering scenarios, commonly across regions or where separate DRGs are peered. In this article, we are not using RPC.

 First create IAM policy and define policy statements in both tenancies. Basically, we are making the tenancies know each other.

For this exercise we name the tenancies as below.

Requestor tenancy: owns the DRG.
Acceptor tenancy: owns the VCN that will be attached to the requestor DRG.

As per the prerequisites, we need OCID of both the tenancies and we need an IAM group on both the side to manage this attachment. In this exercise we have chosen Administrators group as we are going to have this setting at tenancy level.  DRG and VCN are available already in the respective tenancies. For connectivity testing purpose, we can windows VM at requestor tenancy and a Database VM in the acceptor tenancy.

Source Tenancy Name : Requestor
Requestor OCID:  ocid1.tenancy.oc1..aaaaaaaacq5gprsqz26em4koaokcntrxxxxxxxx
IAM Group in Requestor: ocid1.group.oc1..aaaaaaaa5xhfg6q6pefhbvwmtvzelih2kiuxgjwxxxxxxxxx

VCN CIDR Range: 192.168.0.0/16

Target Tenancy Name:   Acceptor
Acceptor OCID: ocid1.tenancy.oc1..aaaaaaaargwveli3zwyyeywzeex6x4zxqodjkxxxxxxx
IAM Group name in Acceptor:  ocid1.group.oc1..aaaaaaaat4idcm3dbat2zlgqarxxxxxxxxx

VCN CIDR Range: 10.0.0.0/16

 

At the requestor tenancy, Goto OCI Console -> Identity & Security -> Policy.

Create Policy in root compartment. But if there is a requirement that peering has to be done between particular compartment, then we can create the policy in those compartments.

Click Policy editor and provide below policy statements.

Define tenancy AcceptorTenancy as ocid1.tenancy.oc1..aaaaaaaargwveli3zwyyeywzeex6x4zxqodjkbvnde4la7j5cckwioxqfncq

Define group VCN-Admin as ocid1.group.oc1..aaaaaaaat4idcm3dbat2zlgqar3wzvxkz4hqlxynwkyo3gztsbtgg4on2xhq

Endorse group Default/Administrators to manage drg-attachment in tenancy AcceptorTenancy

Admit group VCN-Admin of tenancy AcceptorTenancy to manage drg in tenancy

Endorse group Default/Administrators to manage virtual-network-family in tenancy AcceptorTenancy

 

Let me explain the policy statements.

First statement defines the Acceptor tenancy OCID.
Second statement defines VCN-Admin as OCID of group available at acceptor
Third statement endorses that at acceptor tenancy the requestor tenancy group (administrators) can manage DRG attachment. This is required since the VCN at the acceptor going to be attached with DRG of requestor as shown in the picture.
Fourth statement is equivalent of third, but in the reverse order.
Fifth statement is required to make the group to manage virtual network family in acceptor tenancy. I was getting Privilege error without this statement. I suggest not to ignore this policy.

 

After policy are entered, click create button to create the policy.

At the Acceptor tenancy, Goto OCI Console -> Identity & Security -> Policy.

Create Policy in root compartment. But if there is a requirement that peering has to be done between particular compartment, then we can create the policy in those compartments.

Click Policy editor and provide below policy statements.

Define tenancy RequestorTenancy as ocid1.tenancy.oc1..aaaaaaaacq5gprsqz26em4koaokcntrpey4adi7mzzgve53cm44ozbxa4z4a

Define group DRG-Admin as ocid1.group.oc1..aaaaaaaa5xhfg6q6pefhbvwmtvzelih2kiuxgjwf5bg6bfqseeewjapd5mha

Admit group DRG-Admin of tenancy RequestorTenancy to manage virtual-network-family in tenancy

Admit group DRG-Admin of tenancy RequestorTenancy to manage drg-attachment in tenancy

Endorse group Default/Administrators to manage drg in tenancy RequestorTenancy

Let me explain the policy statements.

First statement defines the Requestor tenancy OCID.
Second statement defines DRG-Admin as OCID of group available at requestor
Third statement admits that DRG-Admin of tenancy can manage network in acceptor tenancy. Again, I suggest not to this policy. I was getting privilege error without this policy.

Fourth statement admits that DRG-Admin can also manage drg-attachment in acceptor tenancy.

Fifth statement is endorses acceptor group (administrators) can manage DRG in requestor tenancy.

 

Click Create and complete the policy creation.

Now we have created policies at both tenancies and we can go ahead and create the connectivity.

In the Acceptor tenancy, open the DBVCN VCN.
Go to Resources → Dynamic Routing Gateway Attachments.

Click Create DRG Attachment.

Choose Another tenancy.
Provide the DRG OCID from the Requestor tenancy.
Create the attachment.

It will create Attachment with DRG.

You can find the cross-tenancy column as “Yes”.

The tenancies are connected now. You can find the same in DRG of requestor.

In the requestor tenancy, Go to Networking -> Customer Connectivity -> Dynamic Routing Gateway.

Choose the DRG. In the DRG page, move to Attachments section. We could see VCN attachments.

This confirms that cross-tenancy connection is successful at requestor side as well. But currently only connection has established, but Security list and Route table needs to be updated to allow the connection s between these tenancies. For quick lab validation, we temporarily allowed broader traffic. For production, restrict the rules to the required ports and source CIDRs.

Security list – Requestor

Route table – Requestor

Destination CIDR: 10.0.0.0/16
Target: DRG

Security list – Acceptor

Route table – Acceptor

Destination CIDR: 192.168.0.0/16
Target: DRG

Connectivity testing

Requestor Windows VM to VM database connectivity.

 

VM Database server to Windows VM

 

This completes the cross-tenancy network foundation. In the next article, we will build on this setup and create a database link from an OCI Autonomous Database private endpoint to the VM-based Oracle Database across tenancies.