Overlapping CIDRs, Split DNS and a NAT That Nobody Owns

The DRG is a router, not a translator. It builds a forwarding table keyed by prefix and next-hop attachment. When 10.10.0.0/16 arrives from the Azure attachment and the same 10.10.0.0/16 is locally attached as the VCN CIDR, longest-prefix match cannot disambiguate them: the lookup returns one next hop, and packets destined for 10.10.4.20 either loop at the edge or die silently because there is no ICMP-generating hop. That is exactly the observed signature - packets leave both sides and nothing answers. No combination of DRG route tables, route distributions or import policies can fix identical prefixes, because the ambiguity is in the address itself.

Options:

• Re-IP Azure (nine months). Clean, no translation, but blocks delivery.
• Re-IP OCI instead. Usually far faster because the OCI estate is smaller: stand up a new VCN in 10.50.0.0/16, migrate the handful of OCI workloads, and keep the old VCN isolated with no interop attachment. This is normally the cheapest permanent fix and should be the default recommendation.
• NAT via an NVA. Workable for a narrow, one-directional flow, but it breaks end-to-end address identity (TLS with IP SANs, DB allow-lists, audit logs), needs stateful return-path engineering, and creates a bandwidth and availability bottleneck nobody owns.
• Interim service-level bridge. Use a non-overlapping interop VCN that hosts an API gateway or reverse proxy; Azure calls the proxy, the proxy reaches 10.10.4.20 locally. This ships in weeks and disappears when re-IP completes.

Recommend: interim bridge now, OCI-side re-IP as the permanent fix, and treat full Azure re-IP as a decommissioning cleanup rather than a prerequisite.

Resolution must be delegated in both directions, and the forwarders themselves must live in address space that does not overlap - which is why DNS is the second casualty of the CIDR clash.

OCI to Azure: create forwarding rules in the OCI VCN resolver (or a private view applied to the interop VCN) that send the Azure zone suffixes - for example svc.privatelink..core.windows.net and any contoso.com zones - to an Azure DNS Private Resolver inbound endpoint in a delegated subnet. That inbound endpoint needs a non-overlapping IP, so it belongs in an added Azure address space such as 10.60.0.0/24, not in 10.10.0.0/16.

Azure to OCI: Azure DNS Private Resolver outbound rules (or conditional forwarders on AD DNS) point at the OCI DNS listener address that serves the VCN private view. Publish the Exadata endpoint name and any custom zones in that view.

What breaks first:

1. The forwarder IP overlaps, so the rule cannot be installed or the traffic routes ambiguously. Fix address space before touching DNS.
2. Reverse zones. in-addr.arpa for 10.10.0.0/16 is claimed by both sides; PTR records will be wrong or missing and some client libraries and monitoring tools depend on them.
3. TTL and caching. Developers hard-coding IPs of a private endpoint creates a hidden dependency that survives DNS changes; publish a service name and enforce it.
4. Resolver limits. A single forwarder subnet is a choke point; deploy resolver endpoints per region and monitor query failures, because DNS failure looks exactly like the earlier silent drop to an application team.

Symptoms are classic source-NAT and stateful-path failures, not a routing bug.

Diagnosis:

• Azure-initiated flows require a separate translation direction. If only one direction is translated, the return packet carries an address the NVA does not own or does not have a session for. Timeouts appearing after hours rather than immediately point at session table expiry or idle-timeout mismatch between the NVA and the cloud security layers, not at a bad route.
• Port allocation errors at peak indicate PAT exhaustion. A single translated IP gives roughly 64k ports per destination tuple; a service opening 8,000 short-lived connections per minute to a database connection pool will exhaust it. This is not tunable away without adding translated IPs or reducing connection churn with pooling.
• Interconnect has two circuits. If the NVA sees one direction on one circuit and the return on the other, the session lookup fails and the connection blackholes intermittently.
• MTU: the interconnect path is effectively 1500 bytes; NAT plus tunnelling may not fragment as you expect, and large result sets stall rather than error.

Verdict: keep it only as a narrow, time-boxed bridge for a named set of flows, with a documented owner, session table alarms, connection pooling in front of it, and pinned circuit routing. It is not an architecture. The permanent answer is eliminating the overlap - re-IP the OCI side quickly and retire the NAT before it becomes load-bearing. If NAT must persist, terminate it in a cluster with session synchronisation and size it well above 6.8 Gbps-class peaks.