Overlapping CIDRs, Private Object Storage Access and a Failed Security Review

No. Both networks are 10.0.0.0/16, and OCI VCN peering requires non-overlapping CIDRs.

• Route selection is longest-prefix match with no NAT layer in peering, so identical prefixes are ambiguous. Peering will be rejected or will silently route to the wrong place.
• Local peering is also non-transitive: even with clean CIDRs, an LPG between production and the clinic VCN would not give the clinic VCN reachability to on-premises through the DRG. Hub-and-spoke through the DRG is what provides transitive routing.

Options, in order of preference:

1. Re-IP the smaller/younger network (usually the acquired tenant) into a free block and reserve a supernet now: e.g. prod 10.0.0.0/16, clinic 10.1.0.0/16, analytics 10.2.0.0/16, with 10.3.0.0/16 and above left free. Cost is re-addressing instances and updating DNS, firewall rules and vendor configuration.
2. If the nine-month contract genuinely forbids re-addressing, do not try to bridge the overlap. Keep the clinic tenancy isolated and exchange data at the application layer (Object Storage replication, TLS API calls, or a managed file transfer) until the re-IP lands.
3. Do not assume static routes or an appliance will fix it; overlapping prefixes break connectivity regardless of route table entries.

Put the CIDR plan under change control before the analytics VCN is created, or the same overlap gets copied into a third network.

• Create a service gateway in the production VCN and attach the Object Storage service (or "All Services in Region").
• Add a route rule to the private subnets' route table: destination = the Object Storage (or all-services-in-region) service CIDR, target = the service gateway. No internet gateway, NAT gateway or public IP is needed; traffic stays on the OCI network.
• Remove or avoid any 0.0.0.0/0 route to a NAT/IGW on those subnets, otherwise you cannot prove which path is taken. Route tables attach to subnets, so every VNIC in the subnet inherits the rule.
• The bucket must be in a region covered by that gateway (service gateways are regional).
• A network path is not an authorisation. The instances still need identity and policy: instance principals through a dynamic group, with a policy granting read on the bucket's compartment.
• If the bucket lived in a different tenancy, a service gateway would not be sufficient - an Object Storage private endpoint would be the tool.
• Verify from inside an instance (e.g. an SDK/CLI call to the object namespace) and confirm in Monitoring that no NAT or internet egress occurs.

No. Security lists and NSGs are allow-only and additive; there is no deny rule and no rule ordering. A stricter NSG cannot mask a permissive security list entry.

• Security lists attach to a subnet and apply to every VNIC in it. NSGs attach to individual VNICs and are referenced by source in rules. With 200 instances of mixed roles, NSGs are the correct unit of control.
• The wide rule must be deleted or narrowed, not overridden.

Sequence:

1. Create an NSG for the administrative/bastion path and an NSG for the app tier with ingress TCP 22 sourced only from the bastion NSG. Restrict egress as well.
2. Attach the app NSG to the instances and confirm SSH still works through the intended path.
3. Delete the 0.0.0.0/0:22 rule from the subnet's security list - only after step 2 is verified, and with a console connection or Bastion session open as a fallback so you cannot lock yourself out.
4. Better long term: remove public IPs from the instances entirely and use the OCI Bastion service for session-based, time-limited, audited SSH.
5. Re-run the security review against the effective rule set (security list + all attached NSGs), since the finding is about reachability, not about how many rule objects exist.