Google Cloud / Basic: Resource and Access Boundaries / Lesson 6

VPC and Network Reachability

Trace routes, addresses, firewall policy, name resolution, and application listeners as separate parts of a connection.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain global VPC and regional subnet scope.
Separate routing, firewall decisions, identity, and listeners.
Check synthetic address plans without probing networks.

A VPC provides connectivity, not automatic application access

A Google Cloud VPC network is global, while subnets are regional and provide address ranges used by resources in their region. A VM’s interface, routes, firewall rules, DNS, and application configuration all participate in reachability. Being in the same project does not prove that two resources can communicate, and an IP path does not grant IAM or database authorization.

Default networks and their rules are environment-dependent starting points, not a universal production design. Custom address planning should consider overlap with other networks, hybrid connectivity, managed-service connections, and future growth. Shared VPC separates network ownership from service-project use under explicit permissions; it does not remove responsibility for those boundaries.

Check overlap before assuming routes can distinguish networks

The first offline program compares invented private CIDR ranges. It detects that a proposed range overlaps an existing one. This is an address-math check, not a statement that a real subnet can be created or connected. Google reserves and constrains addresses according to product-specific rules that this local library does not evaluate.

A non-overlapping plan is necessary for many connectivity designs but not sufficient. Review route advertisements, peering or hybrid limitations, DNS, service connectivity, and organizational policy. Do not “solve” overlap by changing production ranges without a migration plan. The example writes no configuration and sends no packets.

python Compare synthetic CIDR ranges offline

from ipaddress import ip_network

existing = ip_network("10.20.0.0/24")
proposed = ip_network("10.20.0.128/25")
separate = ip_network("10.21.0.0/24")
print("proposed overlaps", existing.overlaps(proposed))
print("separate overlaps", existing.overlaps(separate))

Expected output

proposed overlaps True
separate overlaps False

The /25 lies inside the /24, while10.21.0.0/24 is separate; no network is contacted.

Firewall policy and application identity are different controls

VPC firewall rules allow or deny traffic according to their documented targets, direction, protocols, ports, and priorities. They are not IAM permissions for reading an object or using a database. Google Cloud firewall policy layers and rule evaluation can be more complex than a single ordered list. Review the exact product and policy hierarchy rather than importing another cloud’s assumptions.

A stateful network allowance does not prove the target process is listening or healthy. Conversely, a listening service is not reachable when routing or policy blocks the path. Restrict sources and targets to the intended workload. A broad internet source is not a generic diagnostic repair for a private connection failure.

Model a connection as several necessary conditions

The second program evaluates a deliberately simplified static checklist: route, firewall allowance, and listener. The missing listener makes the local model report false. It does not reproduce packet processing, DNS, TLS, connection tracking, or real Google policy evaluation. Its purpose is to stop the common inference that one green control proves the whole path.

For a real authorized investigation, first define source identity/address, destination, protocol, port, time, and expected name resolution. Then gather the appropriate existing evidence for each layer. Keep secret material and full sensitive payloads out of diagnostics. This course performs only the offline checklist and no connectivity tests.

python Review a simplified connection checklist

checks = {"route": True, "firewall": True, "listener": False}
missing = [name for name, passed in checks.items() if not passed]
print("model reachable", all(checks.values()))
print("missing", ",".join(missing))

Expected output

model reachable False
missing listener

The static model lacks a listener; it proves nothing about a live route or firewall.

Private paths have distinct service contracts

Private Google Access, Cloud NAT, Private Service Connect, and private services access solve different connectivity problems. Cloud NAT supports appropriate outbound translation and is not an inbound port-forwarding shortcut. Private Google Access for API access is not the same thing as configuring a Cloud SQL private-IP path. A product’s “private” label does not replace authentication, authorization, or encryption requirements.

Document which mechanism each dependency uses, its location and routing scope, DNS expectations, policy owner, and failure behavior. Test the design conceptually with missing routes, wrong names, denied identity, and unavailable listeners. A complete operational validation needs approved environment-specific work, which no runnable example in this lesson attempts.

Common errors and fixes

A project grant is used to repair a blocked TCP path.

Why it happens: IAM and packet reachability were confused.
How to fix it: Trace the network path and authorization separately.
Prevent it next time: Document each layer’s evidence.

Cloud NAT is assumed to accept unsolicited inbound connections.

Why it happens: Outbound translation was mistaken for inbound publishing.
How to fix it: Choose a documented inbound service design.
Prevent it next time: State direction and connection initiator.

Non-overlapping CIDRs are called proof of connectivity.

Why it happens: Address math was treated as route/firewall/service verification.
How to fix it: Review all required layers and product constraints.
Prevent it next time: Label offline checks precisely.

Check your understanding

1. A VM can resolve a database name but its connection times out. What does successful DNS establish, and what remains?

Show worked solution

It establishes only that the resolver returned an answer under that context. Review the resolved address, route, firewall policy, service connectivity mechanism, destination listener, and relevant health evidence. Authentication may become the next issue after transport succeeds. Do not broaden IAM or open public sources merely because the first visible symptom is a timeout.

2. Why is10.20.0.128/25 overlapping10.20.0.0/24 rather than an independent adjacent subnet?