Oracle Cloud Infrastructure (OCI) OS Management Hub helps administrators manage software sources and packages on registered Oracle Linux instances. In addition to Oracle-provided repositories, OS Management Hub can configure third-party YUM repositories and attach them to managed systems.

In this tutorial, we'll add Remi's RPM Repository as a third-party software source and attach it to an Autonomous Linux 10 instance. Finally, we'll refresh the repository metadata and verify that the new repository is available from the Linux command line.

This walkthrough follows the configuration shown in the accompanying OCI Console screenshots.

Prerequisites

Before starting, have an Oracle Linux 10 instance registered with OCI OS Management Hub, permissions to create and attach software sources in the relevant compartment, and the correct repository URL and GPG signing key for your OS version and architecture. The example uses an x86_64 instance.

Step 1: Open Software Sources in OCI OS Management Hub

In the OCI Console, navigate to Observability & Management → OS Management Hub → Software Sources. Select the compartment where you want to create the software source. Choose Actions → Add Third-Party Software Source.

Step 2: Enter the Basic Information

On the Basic Information page, provide a meaningful name and, optionally, a description. In the demonstration, the source is named RemisRepo and described as a third-party repository for Remi.

The source name must start with a letter and contain only letters and numbers. The chosen name will also identify the repository on managed Linux instances.

Click Next.

Step 3: Configure the Repository URL and Operating System

In Repository Configuration, enter the third-party YUM repository URL. Ensure the URL matches the Linux version and CPU architecture of the managed instance. Select Oracle Linux 10 and x86_64, as shown in this demonstration.

The exact repository URL should be obtained from the repository provider and checked before use. Do not use a URL intended for a different OS release or architecture.

Step 4: Enable GPG Verification

Under Security settings, enable GPG Check and supply the corresponding GPG Key URL from the repository provider. GPG signature verification helps confirm that downloaded packages have been signed by the expected source.

Verify the signing key independently using the repository provider's official documentation before trusting packages.

Step 5: Review and Create the Third-Party Software Source

Review the source name, description, repository settings, operating system, architecture, and GPG configuration. Then select Create Third-Party Software Source.

OS Management Hub creates the software source and begins synchronizing its repository metadata. Wait for synchronization to complete before proceeding.

Step 6: Confirm the Software Source Was Created

Return to OS Management Hub → Software Sources. Locate the new Remi software source and inspect its details and synchronization status.

The repository should be available for attachment once its metadata has synchronized successfully.

Step 7: Open the Registered Autonomous Linux Instance

Navigate to OS Management Hub → Instances and select the registered Autonomous Linux 10 instance that should receive the repository.

On the instance details page, open Software Sources to review its currently attached repositories.

Step 8: Attach a Software Source

Select Attach Software Sources.

In the attachment interface, click Add.

Step 9: Select the Remi Repository

Locate the third-party software source created earlier. Select its checkbox and click Add to attach it to the instance.

After the operation completes, return to the instance's Software Sources tab and confirm that the Remi repository is listed among the attached software sources.

Step 10: Verify the Repository from Autonomous Linux

Connect to the managed instance using SSH or an SSH client such as PuTTY. Refresh the repository metadata with the following commands:

sudo dnf clean all
sudo dnf makecache

Next, list the enabled repositories:

sudo dnf repolist

The Remi repository should appear in the repository list. This confirms that the third-party source has been attached and its metadata can be accessed from the managed instance.

If it does not appear, review the software source synchronization status, attachment status, repository URL, GPG configuration, and network access to the repository endpoint.

Conclusion

OCI OS Management Hub provides a centralized way to configure third-party software sources for registered Oracle Linux systems. In this example, we added Remi's RPM Repository, enabled GPG verification, attached the source to an Autonomous Linux 10 instance, and validated it using dnf clean all, dnf makecache, and dnf repolist.

This approach helps administrators manage supported third-party package repositories through the same OS Management Hub workflow used for Oracle-provided sources.

Note: This tutorial demonstrates repository configuration and attachment. Package installation and application compatibility testing are outside the scope of the source document. Verify third-party repository compatibility and package support before using it for production workloads.

Oracle Cloud Infrastructure (OCI) provides flexible compute resources that allow organizations to increase or decrease CPU and memory allocations based on workload requirements.

For regular OCI virtual machines, administrators can typically resize an instance using the Change Shape option without rebuilding the server.

However, this process is different for OCI Shielded Instances.

Shielded Instances provide additional protection against firmware-level and boot-level threats through security features such as Secure Boot, Measured Boot, and Trusted Platform Module (TPM).

Although these capabilities improve security, they introduce certain operational limitations. One significant limitation is that the shape of a Shielded Instance cannot be changed after deployment.

Therefore, scaling a Shielded Instance requires a different approach.

In this article, we will explore how to scale up or scale down an OCI Shielded Instance by creating a replacement virtual machine from a boot volume backup, while retaining the original private IP address.

We will also discuss how to preserve a public IP address when required.

1. What Is an OCI Shielded Instance?

An OCI Shielded Instance is a compute instance configured with additional firmware and boot security protections.

These protections help defend against unauthorized modifications to the boot process and certain types of low-level malware.

OCI Shielded Instances use three primary security technologies.

Secure Boot

Secure Boot validates the digital signatures of firmware and boot components before allowing them to execute.

This helps prevent unauthorized bootloaders and certain malicious operating system components from starting.

Measured Boot

Measured Boot records measurements of components involved in the boot process.

These measurements can be compared against previously established measurements to detect unexpected changes.

Trusted Platform Module (TPM)

TPM provides hardware-backed or virtualized security capabilities used to store and protect boot measurements and other security-related information.

Together, these features provide additional protection for workloads requiring stronger boot integrity.

Important: Shielded Instances improve boot security but do not replace operating system hardening, patch management, encryption, or other security controls.

2. What Types of Workloads Benefit from Shielded Instances?

Shielded Instances are particularly useful for workloads that require stronger protection against unauthorized firmware or boot-level modifications.

Financial and banking applications

Financial institutions often operate systems containing sensitive financial information.

Shielded Instances can provide an additional layer of protection for application servers, database servers, and other critical infrastructure.

Enterprise databases

Database servers hosting sensitive business information can benefit from secure boot protections.

Examples include:

• Oracle Database servers
• Microsoft SQL Server servers
• MySQL database servers
• Enterprise application databases

Security-sensitive applications

Applications processing confidential customer or organizational information may benefit from additional boot integrity controls.

Identity and authentication infrastructure

Identity management servers and other security infrastructure can benefit from protections against unauthorized changes to the boot environment.

Compliance-driven workloads

Organizations operating under strict security requirements may consider Shielded Instances as part of their broader infrastructure security architecture.

However, using Shielded Instances alone does not guarantee compliance with any particular regulatory framework.

3. Limitations of OCI Shielded Instances

Although Shielded Instances provide additional security, they have several important limitations.

3.1 Shape changes are not supported

The most relevant limitation for this article is that OCI does not support changing the shape of an existing Shielded Instance.

With a regular OCI instance, administrators may be able to modify the OCPU and memory allocation directly.

For a Shielded Instance, this is not supported.

A replacement instance must be provisioned with the required configuration.

3.2 Live migration is not supported

Shielded Instances do not support OCI live migration or reboot migration.

This affects the available infrastructure maintenance and migration options.

3.3 Custom images are not supported

Shielded Instances have restrictions on custom image usage.

Therefore, administrators must verify the supported platform image and boot volume launch options before planning an instance replacement.

3.4 Supported shapes and operating systems are limited

Not every OCI compute shape or operating system image supports Shielded Instances.

Before resizing, confirm that the target shape is compatible with the operating system and required security features.

3.5 TPM-related considerations

Applications or security products that depend on TPM-stored information may require additional configuration after instance replacement.

For example, TPM-bound secrets or encryption keys may not automatically remain usable on the new instance.

3.6 Boot measurements may change

Measured Boot values can change when the underlying compute configuration changes.

Administrators should review boot integrity measurements after replacing the instance.

3.7 Downtime is required

Because the existing instance must be stopped and replaced, this procedure requires a maintenance window.

Application and database services must be shut down properly before taking the final backup.

4. Understanding the Scaling Approach

Since OCI does not allow direct shape changes for Shielded Instances, we can use a replacement-based approach.

The process involves:

1. Recording the existing instance configuration.
2. Gracefully shutting down the application or database.
3. Stopping the existing virtual machine.
4. Creating a boot volume backup.
5. Restoring the backup to a new boot volume.
6. Terminating the existing instance.
7. Provisioning a replacement instance with the required shape.
8. Assigning the original private IP address.
9. Reattaching required data volumes.
10. Starting and validating the application or database.

The replacement instance uses a different compute resource configuration while retaining the operating system and application files stored in the restored boot volume.

**Note:** This is an instance replacement, not an in-place resize. The replacement receives a new instance OCID and new VNIC resources.

---

## 5. Step 1: Record the Existing Instance Configuration

Before starting the scaling activity, collect the current server configuration.

Navigate to:

**OCI Console → Compute → Instances**

Select the Shielded Instance.

Record the following details:

| Parameter | Existing Configuration |
|---|---|
| Instance Name | `<Instance Name>` |
| Availability Domain | `<Availability Domain>` |
| Fault Domain | `<Fault Domain>` |
| Shape | `<Existing Shape>` |
| OCPUs | `<Existing OCPUs>` |
| Memory | `<Existing Memory>` |
| Operating System | `<Operating System>` |
| VCN | `<VCN Name>` |
| Subnet | `<Subnet Name>` |
| Private IP | `<Existing Private IP>` |
| Public IP | `<Reserved Public IP, if applicable>` |
| NSGs | `<NSG Names>` |
| Boot Volume | `<Boot Volume Name>` |
| Attached Block Volumes | `<Data Volume Names>` |

Also record the instance's IAM configuration, SSH access method, tags, metadata, and any custom network settings.

This information will be required when provisioning the replacement instance.

### Important networking consideration

The replacement instance must be launched in the appropriate subnet to reuse the original private IP.

For a primary private IP, terminating the original instance normally releases the address.

The same address can then be requested during replacement instance provisioning, provided it is still available.

Do not assume that OCI reserves the released IP for you.

---

## 6. Step 2: Gracefully Stop the Application or Database

Before taking the boot volume backup, ensure that the application or database is shut down properly.

This is especially important for database workloads.

Connect to the database and perform a controlled shutdown using the procedure appropriate for your environment.

Stop application services using the appropriate commands or service management tools.

Verify that the service is no longer running.

### Why is this important?

Taking a backup while the database is actively writing data may result in a backup that is only crash consistent rather than application consistent.

For production databases, also take and verify an appropriate database level backup, such as RMAN for Oracle Database.

A boot volume backup does not automatically protect data stored on separate block volumes.

---

## 7. Step 3: Stop the Existing Shielded Instance

After confirming that application and database services have stopped, shut down the operating system.

Navigate to:

**OCI Console → Compute → Instances → Select Instance**

Select:

**Stop**

Wait until the instance reaches the **Stopped** state.

This ensures that the operating system is no longer writing to the boot volume.

Avoid using a forced stop unless necessary.

---

## 8. Step 4: Create a Boot Volume Backup

Navigate to:

**OCI Console → Storage → Block Storage → Boot Volumes**

Locate the boot volume attached to the existing Shielded Instance.

Open the boot volume and select:

**Backups → Create Boot Volume Backup**

Provide a descriptive name.

For example:

```text
shielded-instance-pre-scaling-backup

Choose a full backup if you want a clearly identifiable recovery point for the maintenance activity.

Wait until the backup reaches the Available state.

Why take a boot volume backup?

The backup provides a recovery point containing the boot volume's data at the time the backup was taken.

This includes operating system files and application files stored on that volume.

It also provides an additional recovery option if the replacement procedure encounters problems.

Important: If application or database data is stored on separate OCI Block Volumes, those volumes must be protected separately using an appropriate backup or volume group backup strategy.

9. Step 5: Restore the Boot Volume Backup

Before terminating the original instance, restore the boot volume backup to a new boot volume.

Navigate to:

OCI Console → Storage → Block Storage → Boot Volume Backups

Select the backup created in the previous step.

Choose the option to restore or create a boot volume from the backup.

Configure:

Wait until the restored boot volume becomes available.

The restored boot volume will be used to launch the replacement instance.

Why restore before termination?

Restoring the boot volume before terminating the existing instance allows administrators to verify that the backup can be restored successfully.

However, restoration alone does not guarantee that the operating system will boot on the target shape.

For Shielded Instances, confirm that the restored boot volume and its source image are compatible with the required Shielded Instance configuration.

If the required launch combination is not supported, stop the procedure and investigate before terminating the original instance.

10. Step 6: Terminate the Existing Shielded Instance

Once the boot volume backup and restored boot volume are available, proceed with the termination.

Navigate to:

OCI Console → Compute → Instances

Select the existing Shielded Instance.

Choose:

Terminate

During termination, ensure that the option to permanently delete the original boot volume is not selected.

Preserving the original boot volume provides an additional recovery option.

What happens during termination?

When the instance is terminated:

• The original compute instance is deleted.
• Its primary VNIC is removed.
• Its primary private IP is released.
• Ephemeral public IP addresses are released.
• Reserved public IP resources can remain available for reassignment.
• The boot volume can be retained if the appropriate option is selected.
• Separate block volumes are detached rather than automatically migrated to the replacement instance.

Important IP address consideration

The original private IP can be reused only if it is available when creating the replacement instance.

To reduce the risk of another resource obtaining the address, perform the replacement immediately within a controlled maintenance window.

If the private IP is already allocated to another resource, OCI will not allow the replacement instance to use it.

Do not terminate the original server until the backup, restored boot volume, target shape compatibility, and recovery plan have been verified.

11. Step 7: Provision the New Shielded Instance

Navigate to:

OCI Console → Compute → Instances → Create Instance

Select the option to create the instance using an existing boot volume.

Choose the restored boot volume created earlier.

Select the required shape

For example:

Select a supported Shielded Instance shape.

Ensure that the required Secure Boot, Measured Boot, and TPM capabilities are supported and correctly configured.

The exact launch options available depend on the source boot volume, operating system image, and OCI platform support.

Configure networking

Select the same VCN and subnet used by the original instance.

Under primary VNIC networking, choose the option to specify a private IPv4 address.

Enter:

<Existing Private IP>

The replacement instance should now request the same private IP address.

OCI will assign it only if the address is available and valid for the selected subnet.

Preserve the public IP if required

If the original instance used a reserved public IP, reassign that reserved public IP to the replacement instance's private IP after provisioning.

If the original instance used an ephemeral public IP, the same public address cannot be guaranteed after termination.

Complete provisioning

Review the configuration and launch the replacement instance.

Wait until it reaches the Running state.

Verify that the instance boots successfully and that the intended Shielded Instance security features are enabled.

12. Step 8: Reattach Data Volumes

If the original instance had separate OCI Block Volumes, reattach them to the replacement instance.

Navigate to:

OCI Console → Compute → Instances → New Instance → Attached Block Volumes

Select:

Attach Block Volume

Choose the required volumes.

Ensure that the attachment type and device configuration match the operating system requirements.

Linux considerations

Verify the block devices:

lsblk

Check mounted file systems:

df -h

Confirm that all expected volumes are present.

If the instance uses /etc/fstab, ensure that the entries still refer to valid UUIDs, device paths, or mount points.

For Oracle Database workloads, confirm that all database files, redo logs, archive logs, and other required storage locations are accessible.

13. Step 9: Validate the IP Address and Network Configuration

Once the replacement instance is running, verify its networking configuration.

Check the private IP address

For Linux:

ip addr

Compare the assigned private IP with the recorded address of the original instance.

Check the routing table

ip route

Verify that the required routes are present.

Verify OCI networking

Confirm that the replacement instance has the correct:

• VCN and subnet
• Private IP address
• Reserved public IP, if applicable
• Network Security Groups
• Route table association
• DNS configuration

If the original instance used secondary VNICs or secondary private IPs, recreate or reattach the required network configuration as appropriate.

14. Step 10: Start and Validate the Application or Database

After confirming the storage and network configuration, start the required services.

Verify application connectivity to the database.

Validate application functionality.

Resource validation

Check CPU and memory:

lscpu

free -h

Confirm that the operating system recognizes the new compute resources.

Also validate monitoring agents, scheduled jobs, backup policies, security agents, and startup services.

15. Important Considerations Before Production Scaling

Plan for downtime

This is not an online scaling procedure.

The original instance must be shut down and replaced.

Schedule an appropriate maintenance window.

Preserve the original boot volume

Retain the original boot volume until the replacement instance has been fully validated.

Protect database data separately

If database files are stored on attached block volumes, a boot volume backup alone is insufficient.

Take appropriate database and storage backups.

Verify the target shape

Check that the selected shape supports the operating system and Shielded Instance security configuration.

Also verify service limits and compute capacity availability.

Review TPM and Secure Boot dependencies

If the workload relies on TPM-bound secrets, custom Machine Owner Keys, or specialized boot configurations, additional recovery steps may be necessary.

Reconfigure instance specific integrations

A replacement instance receives new OCI resource identifiers.

Review monitoring, automation, IAM policies, instance principals, backup configurations, and any integrations that reference the original instance OCID.

16. Scaling Regular Instances vs. Shielded Instances

For workloads that require frequent CPU and memory adjustments, the operational limitations of Shielded Instances should be considered during the initial architecture design.

17. Conclusion

OCI Shielded Instances provide additional security protections through Secure Boot, Measured Boot, and TPM.

These capabilities can be valuable for sensitive enterprise applications and database workloads.

However, one of their main operational limitations is that the compute shape cannot be changed after the instance has been launched.

To scale a Shielded Instance, administrators can use a replacement based approach involving a boot volume backup, restoration, termination of the original instance, and provisioning of a new instance with the required CPU and memory configuration.

The original private IP address can be reused if it is available in the selected subnet. Reserved public IP addresses can also be reassigned to the replacement instance.

For production workloads, the procedure should be performed within a planned maintenance window with verified backups, appropriate security compatibility checks, and a tested recovery plan.

With careful preparation, organizations can adjust the compute resources allocated to Shielded Instances while minimizing configuration changes and maintaining application connectivity.

References

1. Oracle Cloud Infrastructure — Shielded Instances
2. Changing the Shape of an OCI Instance
3. OCI Boot Volumes
4. Creating a Boot Volume Backup
5. Restoring a Boot Volume
6. OCI Public IP Address Management
7. Terminating an OCI Instance

Disclaimer: The procedure described in this article is a reference approach. Validate Shielded Instance compatibility, boot volume recovery, networking behavior, security requirements, and application dependencies before implementing it in production.

Organizations increasingly adopt multicloud architectures to take advantage of different cloud platforms.

One common scenario involves hosting application servers in Microsoft Azure while running Oracle Database workloads in Oracle Cloud Infrastructure (OCI).

For example, an organization may prefer Azure for its application infrastructure while using OCI Database Services or Oracle Database on OCI Compute for its database workloads.

However, communication between application and database servers requires secure, reliable, and low latency connectivity.

Although site-to-site IPSec VPN is an option, enterprise applications may benefit from dedicated private connectivity.

Microsoft Azure ExpressRoute and OCI FastConnect provide a solution for connecting these environments without routing application to database traffic over the public internet.

In this article, we will explore how to establish private connectivity between Azure and OCI using Oracle Interconnect for Azure.

We will cover:

• Azure Virtual Network configuration

• OCI Virtual Cloud Network configuration

• Azure ExpressRoute circuit provisioning

• OCI FastConnect virtual circuit configuration

• BGP routing and route propagation

• Network security rules

• Oracle Database connectivity testing

• High availability and troubleshooting

The objective is to enable application servers hosted in Azure to communicate securely with Oracle Database servers hosted in OCI using private IP addresses.

1. Understanding the Architecture

The proposed architecture consists of two cloud environments.

Microsoft Azure

The Azure environment hosts application servers inside a Virtual Network (VNet).

An ExpressRoute virtual network gateway connects the VNet to the ExpressRoute circuit.

Oracle Cloud Infrastructure

The OCI environment hosts Oracle Database servers inside a Virtual Cloud Network (VCN).

An OCI Dynamic Routing Gateway (DRG) connects the VCN to a FastConnect private virtual circuit.

Architecture components

The ExpressRoute and FastConnect services establish the private interconnection between the two cloud environments.

Architecture diagram

Microsoft Azure
+-----------------------------------+
| Virtual Network (VNet)            |
|                                   |
| Application Subnet                |
|       |                           |
| Application Servers               |
|       |                           |
| ExpressRoute Virtual Network GW   |
+-------|---------------------------+
        |
        v
Azure ExpressRoute
        |
        | Private Interconnection
        |
        v
OCI FastConnect
        |
        v
+-----------------------------------+
| Oracle Cloud Infrastructure       |
|                                   |
| Dynamic Routing Gateway (DRG)     |
|       |                           |
| Virtual Cloud Network (VCN)       |
|       |                           |
| Database Subnet                   |
|       |                           |
| Oracle Database Servers           |
+-----------------------------------+

The application servers connect to the Oracle Database using its private IP address or private DNS hostname.

The database does not require a public IP address.

2. Prerequisites

Before configuring the interconnection, ensure that both Azure and OCI environments are available.

Azure prerequisites

• Active Microsoft Azure subscription

• Azure VNet with application subnet

• Non-overlapping VNet CIDR ranges

• A dedicated GatewaySubnet

• Permissions to create ExpressRoute circuits and virtual network gateways

• Supported ExpressRoute peering location

OCI prerequisites

• Active OCI tenancy

• OCI VCN with database subnet

• Oracle Database server or OCI Database Service

• Dynamic Routing Gateway

• Permissions to create FastConnect virtual circuits

• Supported OCI region for Oracle Interconnect for Azure

Network planning

Before deployment, identify the following:

Important: Azure VNet and OCI VCN address ranges must not overlap.

Also, verify that the selected Azure ExpressRoute peering location supports direct interconnection with the selected OCI region.

Not every Azure and OCI region pair supports Oracle Interconnect for Azure.

3. Step 1: Configure the Azure Virtual Network

Navigate to:

Azure Portal → Virtual Networks

Create a new VNet or select an existing VNet hosting the application servers.

Configure the VNet with the required address space.

For example:

Virtual Network: <Azure VNet>
Address Space: <Azure VNet CIDR>

Subnets:
- <Application Subnet>
- GatewaySubnet

Create the GatewaySubnet

An Azure ExpressRoute virtual network gateway requires a dedicated subnet named exactly:

GatewaySubnet

Create this subnet within the Azure VNet.

Microsoft generally recommends a /27 or larger gateway subnet for most deployments.

Do not deploy application servers or other workloads into GatewaySubnet.

Avoid associating Network Security Groups or unsupported user-defined routes with this subnet.

4. Step 2: Create the Azure ExpressRoute Circuit

Navigate to:

Azure Portal → ExpressRoute Circuits → Create

Configure the ExpressRoute circuit.

ExpressRoute configuration

Select Oracle Cloud FastConnect as the connectivity provider.

The peering location must be supported by Oracle Interconnect for Azure.

ExpressRoute service key

Once the ExpressRoute circuit is created, Azure generates a unique service key.

The service key is required when creating the corresponding OCI FastConnect virtual circuit.

Copy the service key and keep it available for the OCI configuration.

The ExpressRoute circuit may initially show that the provider has not completed provisioning. This is expected until the corresponding OCI FastConnect configuration is completed.

5. Step 3: Create the Azure ExpressRoute Virtual Network Gateway

Navigate to:

Azure Portal → Virtual Network Gateways → Create

Create an ExpressRoute virtual network gateway.

Gateway configuration

Choose the gateway SKU based on expected traffic throughput, availability requirements, and supported features.

After deployment, the gateway will be used to connect the Azure VNet to the ExpressRoute circuit.

Create the ExpressRoute connection

Open the newly created virtual network gateway.

Navigate to:

Connections → Add

Select the ExpressRoute circuit created previously.

This associates the Azure VNet with the private interconnection.

6. Step 4: Configure the OCI Dynamic Routing Gateway

Navigate to:

OCI Console → Networking → Dynamic Routing Gateways

Create a new DRG or select an existing DRG.

Attach the OCI VCN hosting the Oracle Database servers to the DRG.

DRG attachment

The DRG provides connectivity between the OCI VCN and external private networks.

In this architecture, it connects the OCI VCN to the Azure environment through FastConnect.

DRG routing considerations

Verify that the DRG route tables support:

• Routing from the OCI database subnet toward the Azure VNet

• Routing from FastConnect toward the OCI VCN

• Advertisement of the appropriate OCI VCN prefixes

• Import of the Azure VNet prefixes

OCI DRG route distribution and route table configuration must be reviewed, particularly when the DRG has existing VPN, FastConnect, or multiple VCN attachments.

7. Step 5: Create the OCI FastConnect Virtual Circuit

Navigate to:

OCI Console → Networking → Customer Connectivity → FastConnect

Select:

Create Connection

Choose the FastConnect partner option.

Select:

Microsoft Azure: ExpressRoute

FastConnect configuration

BGP configuration

Oracle Interconnect for Azure uses Border Gateway Protocol (BGP) to exchange network routes.

The connection requires BGP addressing for redundant peering sessions.

Use the addressing information specified in the OCI FastConnect provisioning workflow.

Each BGP session must use a valid, non-overlapping address range.

The BGP configuration enables the Azure and OCI networks to exchange the required private routes.

After provisioning, verify that the FastConnect virtual circuit becomes active and that the Azure ExpressRoute circuit shows successful provider provisioning and private peering.

8. Step 6: Configure Azure Routing

The Azure application servers must have a route toward the OCI database network through ExpressRoute.

With a correctly configured ExpressRoute gateway and BGP route propagation, the required OCI routes are normally learned dynamically.

Expected Azure route

Verify the effective routes on an Azure application server's network interface.

Navigate to:

Azure Portal → Virtual Machines → Networking → Effective Routes

Confirm that the OCI VCN prefix is reachable through the ExpressRoute virtual network gateway.

Important note

In a standard deployment, it is generally unnecessary to create a user defined route for the OCI prefix if the correct BGP route is already being propagated.

Custom route tables should be introduced only when required by the network architecture.

If a custom route table is attached to the application subnet, ensure it does not block or override the ExpressRoute routes.

9. Step 7: Configure OCI Database Subnet Routing

The OCI database subnet must have a route back to the Azure application subnet.

Navigate to:

OCI Console → Networking → Virtual Cloud Networks → Subnets

Select the database subnet and review its associated route table.

OCI database subnet route table

This route allows database servers to send return traffic toward Azure.

OCI DRG route table

Verify that the DRG route table associated with the VCN attachment contains the Azure VNet route through the FastConnect attachment.

Also verify that the DRG route table used for traffic arriving from FastConnect can reach the OCI database VCN.

Expected traffic flow

Oracle Database Server
        |
        v
OCI Database Subnet Route Table
        |
        v
OCI Dynamic Routing Gateway
        |
        v
OCI FastConnect
        |
        v
Azure ExpressRoute
        |
        v
Azure Application Server

Both forward and return routing must be configured correctly.

10. Step 8: Configure Azure Network Security Groups

Azure Network Security Groups control traffic entering and leaving application server network interfaces and subnets.

For the application servers, allow outbound database connectivity to OCI.

Example Azure NSG rule

Port 1521 is commonly used by Oracle Database listeners.

However, the actual port must match the Oracle Database listener configuration.

If the application uses TCPS, a different listener port, or additional services, configure the required rules accordingly.

Avoid unnecessarily allowing all traffic between the two cloud environments.

11. Step 9: Configure OCI Network Security Groups

On the OCI side, configure the database subnet's Network Security Group or Security List to permit connections from the Azure application servers.

Example OCI NSG ingress rule

This allows application servers hosted in Azure to connect to the Oracle Database listener in OCI.

For stronger security, restrict the source CIDR to the specific application subnet or application server IP addresses rather than the entire Azure VNet.

Ensure that any host-based firewalls and database listener access controls also permit the required connections.

12. Step 10: Configure Private DNS Resolution

Network connectivity alone is not sufficient if applications rely on database hostnames.

For example, an application may connect using:

db-prod.internal.example.com

The Azure application servers must be able to resolve the database hostname to its OCI private IP address.

Possible DNS approaches include:

• Azure DNS Private Resolver

• OCI DNS private zones

• DNS forwarding between Azure and OCI

• Existing enterprise DNS servers

Choose the DNS design based on the organization's existing infrastructure.

Example DNS resolution

Azure Application Server
          |
          v
Private DNS Resolver
          |
          v
Oracle Database Hostname
          |
          v
OCI Database Private IP

Ensure that DNS queries and responses can traverse the interconnection where required.

Avoid configuring the application to use a public database endpoint when private connectivity is available.

13. Step 11: Test Application to Database Connectivity

After completing the network configuration, perform connectivity tests.

Test DNS resolution

From an Azure application server:

nslookup db-prod.internal.example.com

Confirm that the hostname resolves to the correct OCI private IP address.

Test database listener connectivity

For Windows application servers:

Test-NetConnection db-prod.internal.example.com -Port 1521

For Linux application servers:

nc -zv db-prod.internal.example.com 1521

A successful TCP connection confirms that the listener port is reachable.

It does not necessarily confirm that database authentication or SQL connectivity is working.

Test Oracle Database connectivity

If Oracle client tools are available:

sqlplus username@//db-prod.internal.example.com:1521/service_name

Use the correct database service name and authentication method.

Validate the traffic path

Verify that the traffic follows:

Azure Application Server
          |
          v
Azure ExpressRoute Gateway
          |
          v
Azure ExpressRoute
          |
          v
OCI FastConnect
          |
          v
OCI DRG
          |
          v
Oracle Database Server

Also verify that the return traffic follows the same private interconnection.

14. High Availability and Performance Considerations

Redundant connectivity

Oracle Interconnect for Azure supports redundant connectivity components.

Verify the redundancy provided by the selected ExpressRoute and FastConnect service configuration.

For mission critical workloads, consider additional redundancy across regions or peering locations where supported.

ExpressRoute gateway sizing

Select an appropriate Azure ExpressRoute gateway SKU based on application throughput and performance requirements.

ExpressRoute FastPath

For supported configurations, Azure ExpressRoute FastPath can reduce data path overhead by allowing traffic to bypass the virtual network gateway's data path.

Verify SKU and topology support before enabling FastPath.

Database latency

Application performance can be sensitive to database round trip latency.

Select suitable Azure and OCI regions and validate latency using application level tests.

Cost considerations

The architecture may incur charges for:

• Azure ExpressRoute circuit

• Azure ExpressRoute virtual network gateway

• OCI FastConnect virtual circuit

• Data transfer, depending on the selected billing model

• Other networking and monitoring services

Review both Azure and OCI pricing before deployment.

15. Benefits of Azure and OCI Private Interconnection

Private application-to-database connectivity

Applications communicate with Oracle Database servers through private network connectivity rather than public database endpoints.

Multicloud flexibility

Organizations can run application workloads in Azure while retaining Oracle Database workloads in OCI.

Reduced exposure

Database servers can remain in private OCI subnets without public IP addresses.

Dynamic routing

BGP enables the two cloud environments to exchange private network routes.

Enterprise connectivity

ExpressRoute and FastConnect provide dedicated private connectivity options suitable for enterprise workloads.

Scalability

The architecture can be extended to additional application servers, database servers, and supported network segments.

Conclusion

Microsoft Azure ExpressRoute and Oracle Cloud Infrastructure FastConnect provide an effective solution for building private multicloud architectures.

By connecting Azure Virtual Networks to OCI Virtual Cloud Networks through Oracle Interconnect for Azure, organizations can host application servers in Azure while securely accessing Oracle Database workloads in OCI.

The key configuration components include Azure ExpressRoute circuits, ExpressRoute virtual network gateways, OCI FastConnect private virtual circuits, OCI Dynamic Routing Gateways, BGP routing, and appropriate network security rules.

Proper planning of CIDR ranges, route propagation, DNS resolution, connectivity testing, and high availability is essential for a successful deployment.

With the correct configuration, organizations can establish a reliable and secure private network connection between their Azure application infrastructure and Oracle Database environment in OCI.

References

• Oracle Interconnect for Azure – Oracle Documentation

• Set Up a Private Interconnection Between Microsoft Azure and Oracle Cloud

• Microsoft Azure ExpressRoute Virtual Network Gateways

• Oracle Cloud Infrastructure FastConnect Overview

• Oracle Application Solutions Integrating Azure and OCI

Disclaimer: This article provides a reference architecture and general configuration procedure. Service availability, portal options, supported region pairs, bandwidth options, and pricing should be verified against current Oracle and Microsoft documentation before production implementation.

When deploying enterprise applications in Oracle Cloud Infrastructure (OCI), securing network traffic is one of the most important aspects of infrastructure design.

A typical OCI environment consists of multiple private subnets hosting application servers, database servers, Active Directory domain controllers, and management systems.

While OCI provides native networking services such as Internet Gateways and NAT Gateways, organizations may require a centralized next generation firewall (NGFW) to inspect and control inbound, outbound, and internal network traffic.

One approach is to deploy Palo Alto Networks VM-Series as the perimeter firewall and use OCI custom routing to direct traffic through the firewall.

In this article, we will explore how to configure OCI networking to achieve the following objectives:

• Use Palo Alto as the centralized perimeter firewall.

• Route inbound internet traffic through Palo Alto.

• Route outbound internet traffic from private subnets through Palo Alto.

• Eliminate the requirement for an OCI NAT Gateway.

• Enable firewall inspection between private subnets.

• Maintain private IP addressing for application, database, and Active Directory servers.

• Support existing VPN or on-premises connectivity.

This article focuses only on OCI networking configurations. Palo Alto firewall policies, NAT rules, and internal routing configurations are outside the scope.

Important: Palo Alto can replace the outbound NAT functionality of an OCI NAT Gateway, but it cannot replace the OCI Internet Gateway itself. The Internet Gateway remains necessary to provide public internet connectivity to the firewall.

1. Architecture Overview

The proposed architecture consists of a single OCI Virtual Cloud Network (VCN) with one public subnet for the Palo Alto untrust interface and multiple private subnets for workloads.

The firewall's trust interface is attached to a separate private subnet.

Network components

Proposed network architecture

                         INTERNET
                            |
                            |
                     OCI Internet Gateway
                            |
                            |
                  +---------------------+
                  |    Public Subnet    |
                  |                     |
                  | Palo Alto Untrust   |
                  |     Interface       |
                  +----------+----------+
                             |
                             |
                  +----------v----------+
                  |    PALO ALTO FW     |
                  |      VM-Series      |
                  +----------+----------+
                             |
                             |
                  +----------v----------+
                  |  Palo Alto Trust    |
                  |  Private Interface  |
                  +----------+----------+
                             |
          +------------------+------------------+
          |                  |                  |
          v                  v                  v
   +-------------+    +-------------+    +-------------+
   | AD Subnet   |    | Application |    | DB Subnet   |
   |             |    | Subnet      |    |             |
   | AD Servers  |    | App Servers |    | DB Servers  |
   +-------------+    +-------------+    +-------------+
                             |
                             v
                     +---------------+
                     | Management    |
                     | Subnet        |
                     +---------------+

All workload subnets are private. Only the Palo Alto untrust interface requires a public IP address.

The diagram illustrates the logical traffic paths. Actual connectivity depends on the OCI route tables, VNIC placement, and firewall forwarding configuration.

2. Understanding the Traffic Flow

Before configuring the OCI networking components, it is important to understand how traffic will flow through the environment.

Inbound internet traffic

Internet
   |
   v
OCI Internet Gateway
   |
   v
Palo Alto Public IP
   |
   v
Palo Alto Firewall
   |
   v
Private Application Server

The Palo Alto firewall becomes the public-facing entry point for applications.

Application servers remain in private subnets without public IP addresses.

Outbound internet traffic

Private Server
   |
   v
Private Subnet Route Table
   |
   v
Palo Alto Trust Interface
   |
   v
Palo Alto Firewall
   |
   v
Palo Alto Untrust Interface
   |
   v
OCI Internet Gateway
   |
   v
Internet

Outbound traffic is directed through Palo Alto instead of an OCI NAT Gateway.

Internal subnet traffic

Application Server
   |
   v
OCI Intra-VCN Routing
   |
   v
Palo Alto Firewall
   |
   v
Database Server

For internal traffic inspection, explicit intra-VCN routes must be configured.

A default route alone does not guarantee that communication between private subnets will pass through the firewall.

3. Step 1: Create the OCI Virtual Cloud Network

Navigate to:

OCI Console → Networking → Virtual Cloud Networks

Create a VCN using an appropriate private CIDR block.

For this article, we will use generic subnet placeholders instead of actual IP addresses.

Recommended subnet structure

Ensure that all subnet CIDRs are non-overlapping.

For better control, assign separate route tables to each subnet.

This allows routing changes to be implemented independently without affecting unrelated workloads.

4. Step 2: Configure the Internet Gateway

Navigate to:

VCN → Internet Gateways → Create Internet Gateway

Create an Internet Gateway and attach it to the VCN.

The Internet Gateway is responsible for providing internet connectivity to the Palo Alto firewall's public facing interface.

Important consideration

Although Palo Alto will act as the perimeter firewall, the Internet Gateway is still required.

The Internet Gateway provides OCI's connection to the public internet.

Palo Alto provides security inspection, forwarding, and NAT functionality.

Therefore:

• Internet Gateway: Required.

• NAT Gateway: Not required.

• Palo Alto Firewall: Handles centralized traffic inspection and NAT.

5. Step 3: Configure Palo Alto Firewall Network Interfaces

Deploy the Palo Alto VM-Series firewall using an OCI-supported deployment method.

The firewall should have at least two data interfaces.

Assign a public IP address to the Palo Alto untrust interface.

The trust interface should use a private IP address.

Disable source/destination checking

OCI normally performs source/destination checking on VNICs.

This ensures that packets received by a VNIC are intended for that interface.

However, network appliances such as firewalls need to forward packets on behalf of other resources.

Therefore, source/destination checking must be disabled on the firewall's forwarding VNICs.

Navigate to:

Compute → Instances → Palo Alto Instance → Attached VNICs

Open the relevant VNIC and enable:

Skip Source/Destination Check

Apply this setting to the forwarding interfaces as required by the firewall architecture.

This allows Palo Alto to forward traffic between different OCI subnets.

6. Step 4: Configure the Palo Alto Public Subnet Route Table

Create a dedicated route table for the firewall's untrust subnet.

Route table: RT-PA-UNTRUST

Associate this route table with the Palo Alto untrust subnet.

How it works

When Palo Alto forwards outbound internet traffic through its untrust interface, OCI uses this route to send the traffic to the Internet Gateway.

The Internet Gateway then provides connectivity to the public internet.

Do not configure the untrust subnet's default route back to the Palo Alto firewall. This could create a routing loop.

7. Step 5: Configure Private Subnet Route Tables

The next step is to direct outbound internet traffic from private workloads through Palo Alto.

Each private workload subnet should have a default route targeting the firewall's trust private IP.

Active Directory subnet route table

RT-AD-PRIVATE

Application subnet route table

RT-APP-PRIVATE

Database subnet route table

RT-DB-PRIVATE

Management subnet route table

RT-MGMT-PRIVATE

In OCI, the target type should be Private IP, selecting the private IP resource associated with the Palo Alto trust VNIC.

The route target must be supported and reachable in the chosen OCI network topology.

Resulting traffic flow

Private Server
      |
      v
Default Route (0.0.0.0/0)
      |
      v
Palo Alto Trust IP
      |
      v
Palo Alto Firewall
      |
      v
Palo Alto Untrust Interface
      |
      v
Internet Gateway
      |
      v
Internet

With this configuration, the OCI NAT Gateway is no longer required for outbound internet connectivity from these private subnets.

8. Step 6: Configure Intra-VCN Routing

This is one of the most important parts of the architecture.

By default, OCI provides local routing between subnets within the same VCN.

For example:

Application Server → Database Server

This communication may occur directly through OCI networking without passing through Palo Alto.

If the requirement is to inspect communication between private subnets, additional routing is necessary.

Application subnet route table

Add an explicit route:

Database subnet route table

Add the corresponding return route:

These routes are intended to redirect traffic between the application and database subnets through Palo Alto.

Why configure both directions?

Palo Alto is a stateful firewall.

It tracks connections and requires the relevant return traffic to follow the correct session path.

If application-to-database traffic passes through Palo Alto but database-to-application traffic bypasses it, communication may fail.

Additional considerations

For complete inter-subnet inspection, apply appropriate routing to the other private subnets, including:

• Active Directory

• Application

• Database

• Management

Ensure that the firewall's own routing allows packets to reach their final destination.

Also, note that OCI subnet route tables cannot force traffic between two hosts in the same subnet through a firewall. If same subnet inspection is required, additional network segmentation may be necessary.

9. Step 7: Configure OCI Network Security Groups

OCI Network Security Groups (NSGs) provide network-level security controls for VNICs.

Route tables determine the traffic path, while NSGs determine which traffic is allowed.

Palo Alto untrust interface

Allow only the required internet-facing ports.

For example:

Avoid unrestricted administrative access from the public internet.

Palo Alto trust interface

Allow the required traffic between the firewall and private workloads.

Application subnet

Allow the required application traffic from authorized sources.

Database subnet

Restrict database access to approved application servers and administrative systems.

Active Directory subnet

Allow the necessary Active Directory protocols, including DNS, Kerberos, LDAP, SMB, and required RPC communication.

Security rules must account for the actual packet source and destination addresses, including any NAT performed by the firewall.

10. Step 8: Configure Inbound Internet Access

Since there are no public Load Balancers, internet facing applications are accessed through the Palo Alto public IP.

Traffic flow

Internet Client
       |
       v
Palo Alto Public IP
       |
       v
Palo Alto Firewall
       |
       v
Private Application Server

From the OCI side, verify the following:

1. The Palo Alto untrust interface has a public IP address.

2. The untrust subnet has a default route to the Internet Gateway.

3. OCI security rules allow the required incoming traffic.

4. Application servers remain in private subnets.

5. The application subnet has a valid return route through Palo Alto.

6. Source/destination checking is disabled on the required firewall forwarding VNICs.

The Palo Alto firewall must also be configured to forward traffic to the relevant private application server.

The firewall-specific configuration is outside the scope of this article.

11. Step 9: Configure On-Premises Connectivity

If the environment requires connectivity to an on-premises data center, OCI supports IPSec VPN and FastConnect through a Dynamic Routing Gateway (DRG).

There are two common deployment models.

Option 1: VPN terminates on Palo Alto

On-Premises Network
         |
         v
IPSec VPN Tunnel
         |
         v
Palo Alto Firewall
         |
         v
Private OCI Subnets

Option 2: VPN terminates on OCI DRG

On-Premises Network
         |
         v
OCI DRG
         |
         v
Palo Alto Firewall
         |
         v
Private OCI Subnets

For the second option, configure the required DRG route tables and VCN ingress routing to ensure that the intended traffic passes through Palo Alto.

A simple private subnet route to the DRG may bypass the firewall.

The appropriate routing design depends on the VPN termination point and the OCI topology.

12. Step 10: Validate the OCI Network Configuration

After completing the OCI configuration, perform connectivity tests.

Outbound internet testing

From a private server, test access to an approved external endpoint.

Confirm that the traffic is routed through Palo Alto.

Inbound internet testing

Access the published application through the Palo Alto public IP or DNS name.

Confirm that the traffic reaches the private application server.

Internal connectivity testing

Test communication between:

• Application and database servers

• Application and Active Directory servers

• Management and application servers

Confirm that the required traffic passes through Palo Alto.

OCI troubleshooting tools

OCI provides several tools for validating the network configuration.

Network Path Analyzer

Helps identify network configuration issues along supported OCI paths.

VCN Flow Logs

Provides visibility into accepted and rejected traffic.

Route Tables

Verify destination CIDRs and private IP route targets.

Network Security Groups

Verify ingress and egress security rules.

VNIC Configuration

Confirm that source/destination checking is disabled on the required forwarding interfaces.

Network Path Analyzer does not fully validate third-party firewall policies or NAT behavior, so firewall-side verification is also necessary.

13. Production Considerations

Before implementing this architecture in production, consider the following.

High availability

A single Palo Alto firewall becomes a critical dependency for inbound, outbound, and inspected internal traffic.

For production environments, consider deploying multiple firewall instances with a supported high-availability design.

Symmetric routing

Ensure that forward and return traffic follow the intended firewall path.

Asymmetric routing can cause stateful firewall sessions to fail.

OCI Service Gateway

Some private workloads may require access to OCI services such as Object Storage.

A Service Gateway can provide private connectivity to supported OCI services.

However, if the security requirement is to inspect all applicable network traffic through Palo Alto, avoid adding bypass routes without reviewing the architecture.

Route table management

For environments with many private subnets, maintaining individual route rules can become complex.

Consider using consistent naming conventions and infrastructure-as-code tools such as Terraform to manage route tables and security configurations.

14. Key Benefits

Centralized security

Palo Alto becomes the centralized security enforcement point for internet-facing and selected internal network traffic.

Reduced public exposure

Application, database, Active Directory, and management servers remain in private subnets.

No OCI NAT Gateway required

Outbound internet access can be provided through Palo Alto using the existing Internet Gateway.

Internal network segmentation

OCI intra-VCN routing enables firewall inspection between selected private subnets.

Improved network visibility

Centralized traffic inspection helps administrators monitor and troubleshoot network communication.

Flexible architecture

The design can be extended to support multiple application environments and additional private subnets.

Conclusion

Oracle Cloud Infrastructure provides flexible networking capabilities that allow third-party network appliances to be integrated into enterprise environments.

By combining OCI route tables, private IP next hop routing, and intra-VCN routing, Palo Alto Networks VM-Series can be deployed as a centralized perimeter firewall for private OCI workloads.

This architecture enables organizations to control inbound and outbound internet connectivity, eliminate the need for an OCI NAT Gateway, and introduce security inspection between selected private subnets.

References

• Oracle Cloud Infrastructure – VCN Route Tables

• Oracle Cloud Infrastructure – Virtual Cloud Networks

• Oracle Cloud Infrastructure – Network Security Groups

• Oracle Cloud Infrastructure – Network Path Analyzer

• Palo Alto Networks Documentation

Disclaimer: The configurations provided in this article are architectural examples. Always validate route target support, firewall VNIC placement, traffic symmetry, and security rules before implementing changes in a production environment.

When designing enterprise cloud infrastructure, security and network flexibility are two critical considerations.

In Oracle Cloud Infrastructure (OCI), public Layer 7 Load Balancers are commonly used to distribute incoming application traffic across backend servers hosted in private subnets.

However, organizations may need to introduce a next-generation firewall (NGFW), such as Palo Alto Networks VM-Series, into an existing architecture without changing public IP addresses, modifying DNS records, or recreating Load Balancers.

One possible solution is to use OCI intra-VCN routing to insert a Palo Alto firewall between the existing public Load Balancers and their backend application servers.

In this article, we will explore how to design this architecture while achieving the following objectives:

• Preserve existing public Load Balancer IP addresses.
• Inspect Load Balancer-to-backend application traffic using Palo Alto.
• Route outbound internet traffic from private servers through Palo Alto.
• Maintain direct communication between internal application and database subnets.
• Preserve existing site-to-site VPN connectivity.
• Eliminate the requirement for an OCI NAT Gateway.

Important: This design places public Layer 7 Load Balancers in front of the Palo Alto firewall. The firewall inspects the backend side connection, not necessarily the original client to Load Balancer connection. The routing configuration must also be validated against OCI's private IP next hop and intra-VCN routing requirements.

1. Understanding the Existing Architecture

Consider an OCI environment with the following components:

In the original architecture, internet users connect directly to public OCI Load Balancers, which forward traffic to application servers hosted in private subnets.

The Palo Alto firewall handles other network traffic, including VPN connectivity and selected private network communication.

The objective is to introduce firewall inspection for application backend traffic without modifying the existing public facing Load Balancers.

2. Proposed Architecture

The proposed design retains the existing OCI public Load Balancers and uses custom subnet routing to direct their backend traffic through Palo Alto.

Inbound application traffic

Internet
   |
   v
OCI Internet Gateway
   |
   v
OCI Public Layer 7 Load Balancer
   |
   v
Palo Alto Firewall
   |
   v
Private Application Server

Outbound internet traffic

Private Application Server
   |
   v
Palo Alto Trust Interface
   |
   v
Palo Alto Firewall
   |
   v
Palo Alto Untrust Interface
   |
   v
OCI Internet Gateway
   |
   v
Internet

Internal application communication

Application Server
   |
   | OCI Local VCN Routing
   |
   v
Database Server

Internal application to database traffic continues to use OCI's local routing and does not need to pass through the firewall.

Network Architecture Diagram

The diagram illustrates how public Load Balancers, the Palo Alto firewall, private application subnets, VPN connectivity, and internet access work together.

3. Understanding OCI Intra-VCN Routing

OCI automatically provides connectivity between subnets within the same Virtual Cloud Network.

For example, an application server in one subnet can communicate with a database server in another subnet through OCI's internal networking.

However, OCI also supports custom intra-VCN routing, allowing selected traffic to be directed through a network appliance such as a firewall.

This capability is particularly useful for:

• Network traffic inspection
• Security segmentation
• Centralized firewall enforcement
• Routing through third-party network appliances

For this architecture, we use intra-VCN routing to redirect traffic between the Load Balancer subnet and application subnet through Palo Alto.

The routing must be configured in both directions to maintain stateful firewall sessions.

4. Configuring the Public Load Balancer Subnet

The first requirement is to retain the existing Load Balancers in their current public subnet.

There is no need to recreate them or change their public IP addresses.

Load Balancer subnet route table

Create or modify the route table associated with the public Load Balancer subnet.

The first route directs traffic destined for the application subnet through the Palo Alto firewall.

The second route allows the public Load Balancers to continue communicating with internet clients.

Why this preserves the public IP addresses

The Load Balancers remain unchanged.

We are only modifying how backend traffic is routed within the VCN.

Therefore, the existing public IP addresses, DNS records, and client-facing application endpoints can remain the same.

Important consideration: The firewall private IP must be a supported and reachable route target. The chosen firewall interface must have a valid forwarding path toward the application subnet.

5. Configuring the Application Subnet

The application subnet route table is equally important.

Palo Alto is a stateful firewall, meaning it tracks connections and expects to see the traffic required to maintain their session state.

If Load Balancer-to-application traffic passes through Palo Alto but the response bypasses it, connections may fail.

Application subnet route table

The route to the Load Balancer subnet ensures that application responses return through Palo Alto.

The default route directs outbound internet traffic through the firewall.

Existing VPN or DRG routes should remain unchanged.

What happens to internal traffic?

Internal communication can continue using OCI local routing.

For example:

Application Server → Database Server

This traffic does not need to pass through Palo Alto unless explicitly required by the security design.

A default route to Palo Alto does not automatically override more specific routes for internal VCN destinations.

6. Configuring Palo Alto Firewall

After configuring OCI route tables, the Palo Alto firewall must be configured to forward and inspect the required traffic.

6.1 Firewall routing

The firewall requires routes for the following destinations:

The firewall's routing configuration must match the OCI route tables.

6.2 Security policies

Configure security policies to permit the required communication.

Load Balancer to application traffic

Private server outbound internet traffic

6.3 Source NAT configuration

Private application servers use private IP addresses that cannot be routed directly over the internet.

To provide outbound internet access, configure source NAT on Palo Alto.

After Palo Alto translates the source address to its untrust private IP, the OCI Internet Gateway performs the public IP translation.

The resulting traffic flow is:

Private Server
   |
   v
Palo Alto Trust
   |
   v
Palo Alto Source NAT
   |
   v
Palo Alto Untrust
   |
   v
OCI Internet Gateway
   |
   v
Public Internet

This removes the need for an OCI NAT Gateway for the selected private workloads.

7. Maintaining Symmetric Routing

Symmetric routing is one of the most important requirements when inserting a stateful firewall into an existing application path.

Consider the following example.

Forward traffic

Load Balancer
      |
      v
Palo Alto Firewall
      |
      v
Application Server

Return traffic

Application Server
      |
      v
Palo Alto Firewall
      |
      v
Load Balancer

Both directions must follow the intended firewall path.

If the return traffic bypasses Palo Alto, the firewall may not be able to maintain the session correctly.

To avoid asymmetric routing:

1. Configure the appropriate routes in both subnet route tables.
2. Ensure Palo Alto has routes toward both subnets.
3. Disable source/destination checking on the firewall's forwarding VNICs.
4. Avoid unnecessary NAT for Load Balancer to backend traffic.
5. Validate traffic using Palo Alto session and traffic logs.

The exact routing design depends on the placement of the firewall interfaces and the supported OCI forwarding configuration.

8. Understanding Layer 7 Load Balancer Behavior

This is an important consideration when using OCI Layer 7 Load Balancers.

A Layer 7 Load Balancer typically terminates the client connection and establishes a separate connection to the backend server.

Therefore, the traffic flow consists of two logical connections:

Client facing connection

Internet Client
      |
      v
OCI Public Load Balancer

Backend facing connection

OCI Public Load Balancer
      |
      v
Palo Alto Firewall
      |
      v
Application Server

In this architecture, Palo Alto inspects the backend facing connection.

If HTTPS terminates at the Load Balancer and HTTP is used toward the backend, the firewall can inspect the HTTP traffic.

If HTTPS is used between the Load Balancer and backend, the firewall sees encrypted traffic unless appropriate decryption and inspection capabilities are configured.

Additionally, the firewall may see the Load Balancer's source IP rather than the original internet client's IP.

The original client IP may be forwarded using HTTP headers such as X-Forwarded-For.

These details are important when designing firewall policies and troubleshooting application traffic.

9. Preserving Existing VPN Connectivity

In many enterprise OCI environments, Palo Alto is also responsible for site-to-site VPN connectivity.

The proposed architecture does not require changing the existing VPN configuration.

Existing VPN tunnel interfaces, security policies, and remote network routes can remain in place.

For example:

On-Premises Network
        |
        v
IPSec VPN Tunnel
        |
        v
Palo Alto Firewall
        |
        v
OCI Private Subnets

When configuring outbound internet routing, ensure that more specific routes for on-premises destinations remain available.

Otherwise, private network traffic may incorrectly follow the default internet route.

10. Testing and Validation

Before implementing the design in production, perform a complete validation.

Public application connectivity

• Confirm that existing Load Balancer public IP addresses remain unchanged.
• Verify that public HTTPS endpoints are accessible.
• Confirm Load Balancer backend health checks are successful.
• Verify that backend traffic is visible in Palo Alto traffic logs.

Outbound internet connectivity

• Confirm private application servers can access approved internet destinations.
• Verify that outbound traffic passes through Palo Alto.
• Confirm source NAT is working correctly.
• Verify that external services see the expected public source IP.

Internal network connectivity

• Test application to database communication.
• Confirm internal traffic continues using direct VCN routing.
• Verify that existing VPN connectivity is unaffected.

Firewall validation

Useful Palo Alto commands include:

show routing route

show session all

show counter global filter severity drop

These commands help verify routing, active sessions, and potential packet drops.

A controlled migration and rollback plan should be prepared before applying production route table changes.

11. Key Benefits

Implementing this architecture can provide several advantages.

Preserves existing public IP addresses

Public Load Balancers remain unchanged, avoiding unnecessary DNS and application endpoint modifications.

Centralized security inspection

Application backend traffic can be inspected using Palo Alto security policies.

Centralized outbound internet access

Private servers can access the internet through the firewall without requiring an OCI NAT Gateway.

Maintains internal network performance

Application to database traffic can continue using direct OCI local routing.

Supports existing VPN connectivity

Existing site to site VPN connectivity can remain operational without redesigning the VPN architecture.

Flexible security architecture

OCI custom routing provides flexibility to integrate third-party network security appliances into existing environments.

12. Important Production Considerations

Before deploying this architecture, consider the following:

Firewall availability: A single Palo Alto instance can become a single point of failure for application backend traffic and outbound internet access. Production environments should consider an appropriate high availability design.

OCI routing constraints: Verify that all private IP route targets are valid for the relevant subnet route tables and VCN topology.

Load Balancer health checks: Ensure health check traffic can traverse the firewall and return correctly.

Firewall licensing: Confirm the Palo Alto license includes the required security and inspection features.

Network security rules: Review OCI Network Security Groups and Security Lists to allow the required forwarding traffic.

Existing public IPs: Public IP preservation depends on retaining the existing public Load Balancer resources and their public-facing configuration.

Rollback planning: Maintain copies of the original OCI route tables and firewall configuration before making changes.

Conclusion

OCI intra-VCN routing provides a powerful mechanism for integrating third party firewalls into existing cloud architectures.

By combining custom OCI route tables with Palo Alto Networks VM-Series, organizations can introduce security inspection between existing public Load Balancers and backend application servers while preserving their public IP addresses.

The same firewall can also provide centralized outbound internet access for private workloads, while internal application communication continues using OCI's native routing capabilities.

The key to a successful implementation is careful route planning, symmetric traffic flow, appropriate firewall policies, and thorough testing.

With the correct architecture, organizations can improve network security without unnecessarily redesigning their existing OCI application infrastructure.

References

• Oracle Cloud Infrastructure – VCN Route Tables
• Oracle Cloud Infrastructure – Creating a Route Table
• Palo Alto Networks Documentation
• Oracle Cloud Infrastructure Documentation

Disclaimer: The configurations in this article are architectural examples and should be validated against the actual OCI environment, firewall topology, routing requirements, and security policies before production implementation.