NAT on DRG Overview

NAT on DRG is intended for environments where packets must move across DRG attachments, but the original addressing can't be used safely throughout the full path. Common examples include an OCI VCN communicating with an on-premises network, two independently managed networks connected through a DRG, or a hub-and-spoke design where spoke VCN traffic reaches the DRG through a hub VCN by way of local peering gateways (LPGs).

Without NAT, overlapping address space can cause unexpected routing behavior. For example, if two VCNs advertise overlapping CIDRs into a DRG route table, one route might be active while another is marked as a conflict, and route selection can depend on DRG route-table behavior rather than on the intended traffic path. NAT on DRG helps avoid that ambiguity by rewriting packet headers as traffic enters the DRG through an attachment that has an associated NAT policy and a matching NAT rule.

In practical terms, NAT on DRG lets you translate an original source CIDR to a different source CIDR, an original destination CIDR to a different destination CIDR, or both source and destination CIDRs in the same rule. Translation is attachment-aware, not global to every packet on the DRG. A packet is translated only when it traverses an attachment associated with a NAT policy and matches a rule in that policy.

This attachment-aware design lets the same DRG support both translated and untranslated traffic flows. The attachment where the policy is associated decides where the packet is matched and rewritten. For example, if a policy is associated with a VCN attachment, packets ingressing the DRG through that attachment are evaluated against the policy's rules. If another attachment has no associated policy, or if the policy has no matching rule, traffic on that path isn't translated.

NAT on DRG can be used to perform stateless, 1:1 NAT. In this model, the original and translated CIDRs represent equally sized address spaces, and the DRG preserves host position within the CIDR during translation. For example, if 10.0.0.0/24 is translated to 192.168.10.0/24, a packet with source address 10.0.0.25 is translated to source address 192.168.10.25. The same principle applies to destination NAT: if 172.16.20.0/24 is translated to 10.20.20.0/24, a packet addressed to 172.16.20.40 is translated to 10.20.20.40.

Because NAT on DRG uses stateless 1:1 translation, the original and translated CIDRs in each pair must be the same size, the translation is deterministic, and the DRG doesn't need per-flow session state to map return traffic back to the original host. This is especially useful for overlapping-address scenarios because each original host can be presented as a unique translated host while preserving a predictable mapping. The 1:1 nature of the mapping also helps you reason about translated addresses without maintaining a separate lookup table for each host; route design can be based on translated CIDRs, and troubleshooting is easier because the translated source or destination is derived directly from the original host position in the CIDR.

NAT rules are written in the inbound direction, for traffic ingressing the DRG through the attachment where the NAT policy is associated. The DRG automatically applies the inverse translation on the corresponding egress path for return traffic. You don't need to configure a separate reverse rule for stateless 1:1 NAT. This makes stateless NAT effectively bidirectional for the matched traffic flow, as long as routing allows the translated prefixes to be reached in both directions.

NAT on DRG is built from three main configuration objects: DRG NAT policies, DRG NAT rules, and DRG attachments. A DRG NAT policy is a reusable container for NAT rules. You create rules inside the policy and then associate the policy with one or more supported DRG attachments. Each attachment can reference at most one NAT policy at a time.

A policy by itself doesn't translate traffic, and a policy with no matching rules doesn't translate active traffic traversing the attachment. Translation occurs only when a packet traverses an associated attachment and its source, destination, or both match a rule in that policy.

A DRG NAT rule defines the original CIDR to match and the translated CIDR to apply. A rule can include source translation only, destination translation only, or both source and destination translation. Each translation pair must include an original CIDR and a translated CIDR of the same prefix size. Every rule has a unique priority, and rule priority decides which translation is applied when several rules could match.

A DRG attachment is the point where a NAT policy is bound to actual traffic flow. The attachment decides where traffic enters the DRG for a connected network such as a VCN, RPC, FastConnect virtual circuit, or IPSec VPN tunnel. When a packet ingresses the DRG through an attachment with an associated NAT policy, the packet is checked against that policy's rules in priority order. The first matching rule is applied, and the packet then continues through normal DRG forwarding behavior. If no rule matches, traffic continues as regular, untranslated traffic.

Rules are evaluated in priority order. The lower the number, the higher the precedence. Give more specific or higher-precedence translationslower priority numbers, while broader fallback translations should get given higher numbers. For example, a you might use priority 10 for a specific /32 host translation, priority 20 for a /24 subnet translation, and priority 30 for a broader catch-all translation inside the same translated domain. In that structure, the /32 rule wins first, then the /24, and then the broader rule.

Policies are reusable objects. One policy can contain shared translation logic and can be associated with several eligible attachments, while each attachment still references only one policy at a time. Because each attachment references one policy and each policy contains an ordered set of rules, the main operational questions are which attachment should own the translation point, which rule should win when several possible matches exist, and which translated CIDRs must be routed after a policy is attached.

A NAT rule doesn't need to align exactly with a VCN CIDR, subnet CIDR, DRG imported route, or on-premises advertised route. The rule can match a full routed prefix, a more specific subnet inside a larger route, or a single host route such as /32. This lets you translate only the addresses that need translation instead of translating every address in a larger connected network.

The translated network also doesn't need to be directly attached to the DRG. For example, traffic from a spoke VCN connected to a hub VCN through an LPG can still be translated when that traffic traverses the hub VCN attachment where the NAT policy is associated.

NAT on DRG doesn't replace routing. Translation changes addresses in the packet, but it doesn't automatically ensure that every translated CIDR is reachable throughout the rest of the network. If source traffic from a VCN is translated before being sent to on-premises, on-premises must know how to return traffic to the translated source CIDR. If destination traffic is translated toward a VCN, the DRG and VCN route tables must still send the packet to the correct next hop after translation. You should inject or advertise translated routes themselves where needed.

Address translation also doesn't solve name resolution. DNS queries and DNS responses aren't translated by NAT on DRG. If applications, users, or systems resolve names to original addresses but must communicate with translated addresses, the DNS design must account for that separately.

For more detail, see Routing and DNS Considerations.

NAT on DRG supports SNAT only, DNAT only, and SNAT and DNAT in the same rule. For 1:many NAT use cases, use OCI Network Firewall NAT.

NAT policies can be associated with DRG attachment types such as VCN, RPC, FastConnect virtual circuit, and IPSec VPN tunnel attachments. Loopback attachments aren't supported for NAT policy association.

NAT policies can be associated with DRG attachment types such as VCN, RPC, FastConnect virtual circuit, and IPSec VPN tunnel attachments. Loopback attachments aren't supported for NAT policy association.

1. Create a DRG NAT policy.
2. Add NAT rules to the policy.
3. Associate the policy with the correct DRG attachment.
4. Update DRG route tables, VCN route tables, or on-premises advertisements so translated CIDRs are reachable.
5. Validate traffic flow and name resolution behavior.