10.2 Firewall Rules, Cloud VPN & VPC Network Peering
Key Takeaways
- Firewall rules are evaluated by priority (0-65535, default 1000, lower number wins); implied deny-ingress and allow-egress rules sit at priority 65535 on every VPC.
- The default network's default-allow-ssh/rdp/icmp rules are sourced from 0.0.0.0/0 and are a common security misconfiguration the exam expects you to spot.
- IAP TCP forwarding (source range 35.235.240.0/20 plus roles/iap.tunnelResourceAccessor) is the recommended replacement for open SSH/RDP firewall rules.
- Hierarchical firewall policies (Cloud NGFW) apply at the org/folder/project level across many VPCs; classic firewall rules apply to one VPC only.
- Cloud VPN/Interconnect connect Google Cloud to an external network; VPC Network Peering connects two already-separate VPCs inside Google Cloud, non-transitively, with a default 25-peering-connection quota.
Why This Matters on the ACE Exam
The exam guide names this pairing explicitly under Domain 3: "creating ingress and egress firewall rules and policies" and "peering external networks (e.g., Cloud VPN, VPC Network Peering)." In practice these show up as two distinct question flavors — troubleshooting-style questions ("a VM can't be reached over SSH, what's missing?") and connectivity-design questions ("connect this VPC to that other network — which mechanism?"). Both build directly on the VPC and subnet foundation from Section 10.1.
Firewall Rule Anatomy
Every VPC firewall rule is defined by six components, and exam questions frequently hinge on getting just one of them right:
| Component | Values | Notes |
|---|---|---|
| Direction | INGRESS or EGRESS | Ingress = traffic coming into an instance; egress = traffic leaving it |
| Action | allow or deny | |
| Target | All instances, specific network tags, or specific service accounts | Defines which VMs the rule applies to |
| Source / Destination | IP ranges, tags, or service accounts | Source for ingress rules, destination for egress rules |
| Protocol : Port | e.g., tcp:22, tcp:80,443, all | |
| Priority | 0–65535, default 1000 | Lower number wins — a priority-100 rule is evaluated before a priority-1000 rule |
Two implied rules exist on every VPC and cannot be deleted, only overridden by a higher-priority (lower-number) explicit rule: an implied allow-egress rule and an implied deny-ingress rule, both at priority 65535 (the lowest possible priority). This is why a brand-new custom-mode VPC blocks all inbound traffic until you add explicit allow rules — but permits all outbound traffic by default.
The default network (an auto-mode VPC) additionally ships four extra explicit rules at priority 65534: default-allow-internal, default-allow-ssh (tcp:22), default-allow-rdp (tcp:3389), and default-allow-icmp — every one of them sourced from 0.0.0.0/0. Leaving default-allow-ssh in place on a production network is a textbook security trap the exam expects you to recognize and fix.
Network tags vs. service accounts as targets: tags are simple strings anyone with edit access to a VM can attach, so they carry no access control of their own. Targeting by service account is Google's recommended pattern for anything security-sensitive, because only a user or service account holding roles/iam.serviceAccountUser on that SA can attach it to a VM in the first place — firewall targeting inherits IAM's access control.
Hierarchical firewall policies (Cloud Next Generation Firewall / Cloud NGFW): classic VPC firewall rules attach to exactly one VPC network. Hierarchical firewall policies attach at the organization, folder, or project level and cascade down to every VPC underneath, letting a security team enforce a rule like "deny all egress to a list of known-bad IP ranges" across hundreds of projects from a single policy — without editing every VPC individually.
Secure Remote Access: Identity-Aware Proxy (IAP)
Rather than opening tcp:22 to 0.0.0.0/0, the exam-recommended pattern is IAP TCP forwarding: create a firewall rule allowing ingress only from IAP's fixed range, 35.235.240.0/20, on tcp:22 (or tcp:3389 for RDP). IAP then gates the tunnel itself with IAM — a user needs roles/iap.tunnelResourceAccessor before they can even reach that firewall-permitted range, so access is authenticated and audited before a packet ever reaches the VM. This removes the need for a public IP on the instance entirely.
Cloud VPN and VPC Network Peering
Once two networks need to talk to each other — a Google Cloud VPC to an on-premises data center, or one VPC to another — the correct mechanism depends on ownership and connection type:
| Mechanism | Connects | Encryption | Key detail |
|---|---|---|---|
| Cloud VPN (Classic) | GCP VPC ↔ another network, over the public internet | IPsec-encrypted tunnel | Single tunnel, no SLA; static or dynamic (BGP) routing |
| Cloud VPN (HA VPN) | Same, but redundant | IPsec-encrypted | Two external IPs + two tunnels to redundant peer gateways; 99.99% availability SLA; requires a Cloud Router for BGP |
| Cloud Router | Not a connection itself — a routing control plane | N/A | Exchanges routes dynamically over BGP; required for HA VPN and dynamic Interconnect routing |
| VPC Network Peering | Two independently-owned VPCs (same or different project/org) | None needed — traffic stays on Google's internal backbone | Non-transitive (A↔B and B↔C does not give A↔C); subnet ranges must not overlap; default quota of 25 peering connections per VPC network (expandable by quota request) |
The recurring exam distinction: Cloud VPN and Cloud Interconnect connect Google Cloud to something outside Google Cloud (on-premises, another cloud); VPC Network Peering connects two VPCs that are both already inside Google Cloud but under separate ownership. If the scenario says "two already-existing, separately-managed VPCs," think peering, not VPN. If it says "our corporate data center," think VPN or Interconnect (revisit Chapter 5 for the VPN-vs-Interconnect bandwidth trade-off).
Exam Scenario
A security review finds a production VM reachable over SSH from any IP address on the internet, via a rule named default-allow-ssh. The fix: delete or disable default-allow-ssh, then add a narrower rule allowing tcp:22 only from 35.235.240.0/20 (IAP), targeted by service account rather than an open network tag — and grant roles/iap.tunnelResourceAccessor only to the engineers who actually need access.
Key Takeaways
- Firewall rules are evaluated by priority (lower number = higher precedence); every VPC has implied deny-ingress/allow-egress rules at priority 65535 that explicit rules override.
- Service-account-based firewall targeting is IAM-controlled and more secure than tag-based targeting.
- IAP TCP forwarding (source range
35.235.240.0/20) replaces open SSH/RDP firewall rules with an IAM-gated tunnel. - Cloud VPN/Interconnect connect Google Cloud to an external network; VPC Network Peering connects two separately-owned VPCs already inside Google Cloud, non-transitively.
- HA VPN needs a Cloud Router for BGP and delivers a 99.99% SLA versus Classic VPN's single, non-SLA tunnel.
Which source IP range should you allow in a firewall rule to permit IAP TCP forwarding for SSH access to a VM with no public IP address?
Which statement about VPC Network Peering is correct?
An organization needs to enforce a single "deny egress to a list of known-malicious IP ranges" rule across 200 projects without editing each VPC individually. Which feature should they use?