When organizations move workloads to Oracle Cloud Infrastructure (OCI), a frequent challenge is managing overlapping IP address ranges across cloud and on-premises environments. In an ideal world, each network would have a unique CIDR block to ensure seamless connectivity. However, in real-world scenarios, such as mergers and acquisitions or migrating legacy workloads from data centers to the cloud, overlapping addresses are often unavoidable. This overlap complicates direct routing and network integration, requiring creative solutions to enable smooth connectivity.
In this blog, I’ll share a customer scenario where workloads were migrated from on-premises to OCI over private connectivity (VPN or FastConnect), while retaining the original on-premises IP addresses. This real-world example highlights both the complexity of overlapping CIDRs and the creative solutions required to achieve seamless connectivity.
Solving Overlapping IPs with Network Address Translation (NAT)
To overcome the challenge of overlapping address spaces, we use both Source NAT (SNAT) and Destination NAT (DNAT) to translate network traffic as it flows between environments. The key is implementing one-to-one NAT—also called static mapping—which establishes a dedicated, predictable mapping between a specific source IP and its translated counterpart.
One-to-one NAT can operate at two levels:
- Individual addresses, where each original IP is mapped to a unique translated IP.
- Subnet level, mapping entire blocks of addresses in a one-to-one fashion
For example:
192.168.0.1 → 172.16.1.1
192.168.0.2 → 172.16.1.2
In our design, we use subnet-level mapping. This approach allows entire ranges to be handled through a scalable set of NAT rules, avoiding the need to manage individual entries for every IP, which would quickly become unmanageable in larger environments.
Challenges
The standard solution for handling overlapping CIDRs typically requires two NAT devices: one on-premises to handle Source NAT (SNAT), and another in OCI for Destination NAT (DNAT). If you need two-way communication, you must set up even more SNAT/DNAT rules to support traffic in both directions.
However, when both environments use overlapping CIDRs, using a single routing device isn’t feasible. Routing tables cannot accommodate identical routes pointing to different interfaces without causing conflicts, making direct routing impossible.
In this customer’s case, deploying multiple NAT devices wasn’t an option. They wanted to avoid changes on the on-premises side and were working within strict cost and operational constraints. This meant finding a streamlined, cost-effective approach that would minimize complexity while enabling secure connectivity between overlapping networks.
Solution: Palo Alto VM on OCI
To address these constraints, we deployed a Palo Alto Networks VM-Series firewall on OCI. The Palo Alto virtual appliance is a next-generation firewall available in the OCI Marketplace and provides advanced routing and NAT capabilities.
The Palo Alto VM is deployed in a Hub VCN and is used for:
- Source and Destination NAT
- Virtual Router
Source and Destination NAT
We configure NAT policies in both directions:
- One set of SNAT/DNAT rules for traffic from on-premises to OCI
- Another set of SNAT/DNAT rules for traffic from OCI to on-premises
Virtual Router
The Palo Alto Virtual Router (VR) is a software-based routing engine within the firewall. It maintains separate routing tables and supports routing protocols such as static routes, OSPF, and BGP.
Virtual Routers behave like multiple independent routers on a single firewall instance. This allows routing isolation across interfaces while sharing the same physical appliance, improving flexibility, scalability, and cost efficiency.
Implementation Overview
Note: Provisioning the Palo Alto VM on OCI and basic OCI routing configuration are outside the scope of this blog. Please refer to earlier blogs and videos for detailed guidance.
High-Level Architecture
- Establish private connectivity between on-premises and a non-overlapping Hub VCN in OCI using VPN or FastConnect.
- This design can also be extended across OCI regions using Remote Peering Connections (RPCs).
- Deploy a Palo Alto VM in the Hub VCN with the following interfaces and subnets:
- Management (default)
- Out-A
- In-A
- Out-B
- In-B
- Peer the overlapping Spoke VCN with the Hub VCN using Local Peering Gateway (LPG).
- DRG is not used here because it propagates overlapping CIDRs, which can lead to routing ambiguity.
Palo Alto Configuration
Once the OCI infrastructure is in place, we configure the following on the Palo Alto VM:
- Virtual Routers
- NAT policies
- Security policies
Virtual Routers
Four additional VNICs are attached to the Palo Alto VM and mapped to the interfaces as follows:
- Ethernet1/1 → Out-A
- Ethernet1/2 → In-A
- Ethernet1/3 → Out-B
- Ethernet1/4 → In-B
We then create two Virtual Routers and assign the corresponding interfaces as follows:
- VR1: Ethernet1/1 and Ethernet1/2
- VR2: Ethernet1/3 and Ethernet1/4
Why Two Virtual Routers and Four Interfaces?
The source and destination networks use identical CIDR blocks, a single routing table cannot contain two identical routes pointing to different interfaces.
Traditionally, this would require deploying two separate Palo Alto VMs, each with an “inside” and “outside” interface. However, Palo Alto Virtual Routers allow us to maintain isolated routing tables within a single firewall instance.
Additionally, we use a non-overlapping, externally facing IP range for NAT translation to avoid address conflicts between the two environments.
You can see this architecture illustrated in the following diagram:
This approach:
- Eliminates the need for multiple firewall VMs
- Reduces cost
- Simplifies operations
A non-overlapping IP range is used for NAT translation between the two environments.
NAT Configuration
We configure four NAT rules on the Palo Alto VM:
- SNAT-A and DNAT-A: Traffic from on-premises to OCI
- SNAT-B and DNAT-B: Traffic from OCI to on-premises
All NAT rules use Static IP NAT at the subnet level to ensure one-to-one address mapping.
Security Policy
Security policy configuration is beyond the scope of this blog. However, it is important to note that Palo Alto security policies evaluate pre-NAT IP addresses. Policies must therefore be written using the original (pre-translated) source and destination IPs.
Testing and Verification
Traffic was generated between the on-premises and OCI environments using TCP (port 3389) and ICMP.
Palo Alto traffic logs confirmed that SNAT and DNAT were correctly applied, and communication between hosts with overlapping IP addresses was successful.
Conclusion
Overlapping CIDR blocks are a common challenge in enterprise cloud migrations, especially when customers need to preserve existing IP addressing schemes. While traditional designs often require multiple NAT devices and on-premises changes, this solution demonstrates how a single Palo Alto VM on OCI, combined with Virtual Routers and one-to-one NAT, can elegantly solve the problem.
By leveraging Palo Alto’s advanced routing and NAT capabilities, we achieved:
- Seamless communication between overlapping networks
- No changes to the on-premises environment
- Reduced infrastructure cost
- A scalable and operationally simple design
This architecture provides a practical and cost-effective approach for organizations facing overlapping IP challenges during OCI adoption or hybrid connectivity design.