Today, we’re introducing Network Address Translation (NAT) on the Dynamic Routing Gateway (DRG), a native capability that enables private connectivity between networks with overlapping IPv4 address space. Available in all commercial Oracle Cloud Infrastructure (OCI) regions at no additional cost, NAT on DRG lets customers connect these networks without renumbering them or deploying separate appliances.

For large enterprises, overlapping IPv4 address space is a common challenge. Business units, acquired companies, partners, and cloud environments often use the same private IPv4 address ranges. When these networks need to communicate, address conflicts can be a barrier that often forces teams into costly and complex workarounds. Resolving these conflicts has traditionally meant renumbering entire environments, deploying third-party NAT or firewall appliances solely for address translation, or using public IPv4 address space privately to avoid overlap. Each approach adds cost and complexity, potentially turning a connectivity requirement into a major project.

NAT on DRG simplifies this process by allowing customers to configure 1:1 IPv4 NAT policies directly on their DRGs, minimizing the amount of network changes required to enable address translation. With NAT on DRG, customers can resolve overlapping networks across VCNs in the same or different regions, on-premises environments connected through FastConnect or Site-to-Site VPN, and multi-cloud interconnects.

NAT Policies

Overview

NAT on DRG allows you to define 1:1 NAT policies composed of prioritized rules and attach them directly to DRG attachments. When traffic passes through the attachment, the DRG evaluates rules in priority order and applies the first match—performing source NAT (SNAT), destination NAT (DNAT), or both.

These capabilities are fully integrated into the DRG, aligning address translation with your connectivity architecture across VCNs, on-premises networks, cross-region environments, and cross-tenancy connections.

Key features

  • CIDR-to-CIDR address translation: Supports 1:1 IPv4 address translation between CIDR ranges, including individual host IP addresses (up to /32), across both RFC1918 and non-RFC1918 address spaces used in private networks for OCI to OCI, hybrid cloud, and multi-cloud use cases.
  • Bidirectional translation: 1:1 address translation allows connections to be initiated from either side of a DRG attachment.
  • Flexible NAT rules: Support for SNAT only, DNAT only, or SNAT and DNAT in a single rule. Write conditional network address translation rules based on the source, destination, or combination thereof, allowing custom NAT policies.
  • Policy-based control with deterministic behavior: Rules are evaluated in priority order (lowest number first), ensuring predictable, first-match behavior in complex environments. Traffic that doesn’t match any configured rules is forwarded with no additional action.
  • Native DRG integration: You can introduce NAT to your virtual environment without deploying major network architecture changes. Policies are attached directly to existing DRG attachments, including VCN, FastConnect virtual circuit, IPsec VPN tunnel, and remote peering connection (RPC) attachments.

Key scenarios

  • Eliminating address translation appliances: Remove the need for third-party NAT or firewall virtual appliances in many DRG-centric architectures, reducing infrastructure footprint, operational complexity, and potential bottlenecks.
  • Unblocking migrations: Enable lift-and-shift migrations, mergers, or third-party cloud environments even when IP conflicts exist, avoiding costly renumbering projects.
  • Simplifying multi-network connectivity: Provide a consistent mechanism for handling overlaps across on-premises, partner networks, and multiple VCNs.

Use cases

Use Case #1: Overlapping CIDRs between two local VCNs

Overlapping VCN CIDRs are a classic failure mode: two local VCNs belonging to different business units might utilize the same CIDRs for subnets or there may be a partial overlap. Both can be resolved without significantly altering your network architecture by utilizing NAT on DRG. Perform source NAT and destination NAT at the same time to translate bidirectional traffic to a set of non-overlapping IPs.

Rules are analyzed in order based on an associated priority so you can configure a hierarchical NAT policy that performs NAT on a specific host IP prior to evaluating a rule for a VCN subnet CIDR or a whole VCN CIDR.

Use Case #1
Figure 1: Overlapping subnet CIDRs resolved with stateless 1:1 NAT on DRG

Two VCNs with the same CIDR communicate privately by translating each VCN subnet CIDR to a unique private CIDR as traffic traverses the DRG.

Use Case #2: Overlapping CIDRs between multiple remote VCNs

If your VCNs with overlapping CIDRs are in different regions, they can still be translated. Depending on your use case, NAT rules can be split between different NAT policies for each VCN attachment, or optionally utilize a single NAT policy on your remote peering connection (RPC) attachment that contains all your consolidated NAT rules. The diagram below illustrates the latter where a single NAT policy is used for translating all traffic between regions.

Use Case #2
Figure 2: Overlapping subnet CIDRs in different OCI regions resolved with stateless 1:1 NAT on DRG

This scenario maintains the translation for all VCNs in the region, including non-overlapping ones where only source NAT is required.

Use Case #3: Overlapping CIDRs between OCI and On-Premises

NAT on DRG also supports use cases where the IP overlap exists between an OCI VCN and your on-premises or another third-party destination, such as a partner network or another cloud service provider. NAT on DRG supports translation on FastConnect virtual circuits, standard Site-to-Site IPsec VPN tunnels, Site-to-Site IPsec IPsec VPN tunnels over FastConnect, and Oracle multi-cloud interconnects.

Use Case #3
Figure 3: Overlapping IPs between VCN subnet CIDR and on-premises or remote network with stateless 1:1 NAT on DRG

With this scenario, the overlap is between on-premises and an OCI VCN. Depending on your use case, consider applying your NAT policy to the VCN, virtual circuit, or IPsec VPN Tunnel attachment.

Use Case #4: Shared services VCN

If you’re providing a shared service to multiple organizations or third-party entities via private connectivity and want to ensure that there is no overlap between organizations, then consider translating all traffic towards your shared service. It doesn’t matter if your customers connect via FastConnect, Site-to-Site VPN, or they have their own OCI tenancy/compartment and are connecting through a VCN attachment or cross-tenancy remote peering connection. All these permutations are supported by NAT on DRG.

Use Case #4
Figure 4: Multiple organizations must access a common shared service, with potential overlap between organizations

Perform source NAT for each connection. Use a unique NAT policy per organization, and use the same NAT policy across redundant Site-to-Site IPsec VPN tunnels or FastConnect virtual circuits to ensure that your NAT policy remains during failover.)

Next steps

If you’re dealing with overlapping IP space (especially in hybrid connectivity and multi-VCN designs), NAT on DRG provides a native, DRG-integrated approach to keep traffic routable without renumbering or adding translation-only appliances. To learn more and explore examples, check out the NAT on DRG documentation. Experience DRG’s advanced networking scenarios firsthand – try Oracle Cloud Infrastructure with a US$300 free credit and start building your network today. In addition, for IP exhaustion use cases such as those that necessitate 1:Many NAT, see the OCI Network Firewall.