Hub-and-spoke egress through a DRG and hub NAT gateway
Contoso has a hub VCN 10.50.0.0/16 with a NAT gateway and a spoke VCN 10.60.0.0/16, both attached to the same DRG. The spoke has no Internet Gateway and must send all internet-bound traffic through the hub NAT gateway. The spoke private subnet route table has 0.0.0.0/0 -> DRG. The hub VCN route table has 0.0.0.0/0 -> NAT and 10.60.0.0/16 -> DRG. The DRG route table associated with the hub attachment has 10.60.0.0/16 -> spoke attachment. The DRG route table associated with the spoke attachment has no default route. Spoke instances can reach hub resources but cannot reach the internet; curl times out, and NAT gateway metrics show no egress. The team adds 0.0.0.0/0 -> NAT to the spoke VCN route table, but that fails because the spoke has no NAT gateway. They want the minimal correct route changes and a validation plan.
1. What is the missing routing configuration, and why does the spoke route table alone not solve the problem?
Read the worked answer
The spoke VCN route table correctly points 0.0.0.0/0 to the DRG, but traffic entering the DRG from the spoke is evaluated against the DRG route table associated with the spoke attachment. That table has no default route, so the DRG has no next hop for internet-bound traffic. Add a default route in the DRG route table associated with the spoke attachment with next hop = hub VCN attachment.
Then confirm the return path: the DRG route table associated with the hub attachment must contain 10.60.0.0/16 -> spoke attachment, and the hub VCN route table used for traffic arriving from the DRG must contain 0.0.0.0/0 -> NAT. The hub NAT gateway performs source NAT using the hub NAT public address. Adding 0.0.0.0/0 -> NAT in the spoke VCN route table cannot work because a VCN route rule can target only a gateway attached to that same VCN; the spoke has only the DRG attachment.
2. How would you validate the path and distinguish a routing failure from a security-list or NSG failure?
Read the worked answer
Start at the spoke instance: confirm it has no public IP, then use Network Path Analyzer from the spoke VNIC to a public destination such as 1.1.1.1. The analyzer should show spoke subnet route -> DRG, DRG route table -> hub attachment, hub route table -> NAT. If it stops at the DRG, inspect the DRG route table associated with the spoke attachment for the default route.
If routing is correct, check security rules. The spoke and hub security lists/NSGs must allow outbound TCP 443 or ICMP as appropriate, and the return traffic must be allowed. OCI security lists and NSGs are stateful, so established return traffic is allowed if the initial direction was permitted, but asymmetric paths can still break stateful inspection. Use VCN flow logs on the spoke and hub to see whether packets are accepted at each hop, and check NAT gateway metrics for bytes and connections. A timeout with no NAT metrics points to routing; accepted flows with no reply point to security or upstream filtering.
3. What operational guardrail would you add to prevent a future spoke from making the same mistake?
Read the worked answer
Standardize the attachments: every spoke attachment gets a DRG route table with a default route to the hub attachment, and the hub attachment's DRG route table imports or explicitly lists every spoke CIDR. Keep the spoke VCN route table with 0.0.0.0/0 -> DRG and no NAT gateway. Add a documented checklist and automate validation with Network Path Analyzer or flow-log queries after each new attachment.
Also monitor NAT gateway metrics and DRG route-table changes. If a spoke adds its own Internet Gateway, it can bypass the hub inspection and NAT path, so restrict gateway creation through IAM policy and review route tables for unexpected 0.0.0.0/0 -> Internet Gateway rules. This is a routing and governance problem, not a load-balancer or DNS problem.