Firewall Rules

Exam guide§3.3

VPC firewall rules are stateful and attach to the VPC network, applied at the VM (instance) level, not the subnet. Return traffic for an allowed connection is automatically permitted.

Routes decide where, firewall decides whether

A route maps a destination IP range to a next hop. A packet leaving a VM is only delivered if a route matches its destination and a firewall rule allows it - both must pass.

#NumbersRoutes you get for free

• Subnet routes - created with each subnet; let VMs on the same network reach each other. Destination is the subnet's CIDR range.
• Default route - 0.0.0.0/0 to the internet gateway; sends anything not matched by a more specific route out of the network.
• Traffic is forwarded to the most specific matching route (longest prefix wins).

⚠GotchaA route alone does not deliver the packet

Creating a route only tells the network where the next hop is. If no firewall rule permits the traffic, the packet is still dropped. Routes and firewall rules are evaluated independently.

A route applies to an instance when the network matches and either no instance tags are set (applies to all VMs) or the instance's tags match. Compute Engine compiles the network's route collection into a read-only routing table per VM.

A massively scalable virtual router sits at the core of every VPC network. Each VM connects directly to it, and every packet leaving a VM is handled here first - the router consults that instance’s read-only routing table to pick the next hop (internet gateway, a peer VM, or the VPN gateway).

How rules are evaluated

#NumbersImplied rules (always present, lowest priority 65535)

• Implied allow egress to 0.0.0.0/0 - VMs can send out.
• Implied deny ingress from 0.0.0.0/0 - nothing gets in until you allow it.
• These two cannot be deleted, only overridden by higher-priority rules.

#NumbersPriority

• Range 0 (highest) to 65535 (lowest). Lower number wins.
• First matching rule applies; evaluation stops there.
• Default of a user-created rule is 1000.

⚠GotchaDeny beats allow only if its priority is lower-or-equal

Priority, not action, decides the winner. A deny at priority 1000 loses to an allow at priority 900. When an allow and a deny have the same priority, the deny wins. Design with explicit priorities.

Direction and what you match

• Ingress: match on source (IP ranges, source tags, or source service accounts) + target.
• Egress: match on destination IP ranges + target.

Targeting & access

Targets: network tag vs service account

?DECISIONTarget by network tag or by service account?

	Network tag	Service account
Applied by	Anyone with compute.instances.setTags	Requires IAM to change the VM's SA
Security	Weaker - easy to add/remove a tag	Stronger - governed by IAM
Best for	Ad-hoc grouping, labs	Production, least-privilege segmentation

Pick this when: service accounts for identity you control via IAM; tags for quick, flexible grouping

⚠GotchaDo not mix tags and service accounts in one rule's filter

A single rule cannot combine source tags and source service accounts in its filter. Pick one identity model per rule.

CommandsAllow a TCP port to tagged VMs

# Ingress allow tcp:25565 from anywhere, to VMs tagged minecraft-server

gcloud compute firewall-rules create minecraft-rule \

--allow=tcp:25565 \

--source-ranges=0.0.0.0/0 \

--target-tags=minecraft-server

IAP TCP forwarding: SSH/RDP without a public IP

Identity-Aware Proxy (IAP) tunnels SSH (tcp:22) and RDP (tcp:3389) to VMs that have no external IP, so you skip bastion hosts entirely. Access is governed by IAM, not the network.

#NumbersThe one firewall rule IAP needs

• Allow ingress on tcp:22 (and/or tcp:3389) from 35.235.240.0/20 - the fixed range all IAP tunnels originate from.
• Caller needs the IAP-secured Tunnel User role (roles/iap.tunnelResourceAccessor).
• Connect with gcloud compute ssh VM --tunnel-through-iap (no external IP required).

⚠GotchaMemorize 35.235.240.0/20

IAP SSH/RDP fails if a firewall rule does not allow ingress from 35.235.240.0/20. Scoping the allow rule to that CIDR (instead of 0.0.0.0/0) is the recommended, exam-preferred way to expose SSH to a private VM.

Load-balancer health checks: allow the probe ranges

Health checks decide which backend instances receive traffic, but the probes come from Google-owned ranges, not from your clients. A firewall rule must allow them or every instance is marked unhealthy and gets no traffic.

#NumbersThe firewall rule health checks need

• Allow ingress on the backend's serving port (e.g. tcp:80) from 130.211.0.0/22 and 35.191.0.0/16 - the ranges all load-balancer and managed-instance-group health-check probes originate from.
• Scope it with a target tag (e.g. allow-health-checks) and attach that tag to the backend VMs / instance template.
• Include the /22 and /16 - the ranges, not single addresses.

⚠GotchaMemorize 130.211.0.0/22 and 35.191.0.0/16

If a firewall rule does not allow ingress from 130.211.0.0/22 and 35.191.0.0/16, health checks fail, backends show unhealthy, and the load balancer sends no traffic - even though the app is fine. This is the health-check counterpart to IAP's 35.235.240.0/20.

Hierarchical firewall policies (Cloud NGFW)

Applied at the organization or folder level, evaluated before VPC-level rules. Use them for org-wide guardrails (e.g. deny RDP from the internet everywhere) that individual projects cannot override. Actions include allow, deny, and goto_next (delegate to lower levels).

→StepsEvaluation order

• Org hierarchical policy
• Folder hierarchical policy
• VPC firewall rules
• Implied rules

First terminal match wins.