Yonderx explains: your Google Cloud firewall is a bouncer, not a locked door

If you set up a Google Cloud firewall and think your network is locked tight, you are missing the point. A firewall is not a locked door — it is a bouncer. It stands at the entrance, checks IDs (IP addresses and ports), and decides who gets in. But it does not look inside bags or check for bad intentions. That distinction matters because a bouncer can stop a rowdy guest, but not a polite thief with a stolen ticket. In cloud networking, understanding what your firewall does — and does not do — is the difference between a secure architecture and a false sense of safety.

This guide explains how Google Cloud VPC firewall rules actually work, using the bouncer analogy throughout. We cover the core mechanism, a step-by-step example, edge cases, limits, and practical next steps. By the end, you will know exactly where firewall rules fit in your security stack and what else you need.

Why this topic matters now

Cloud adoption has shifted security left, but many teams still treat firewall rules as a silver bullet. A 2023 survey by a major cloud security firm found that over 60% of cloud breaches involved misconfigured firewall rules — not because the rules were wrong, but because the rules could not address the attack vector. For example, a firewall rule allowing HTTP traffic (port 80) from the internet to a web server is necessary, but it does not prevent a SQL injection or a path traversal attack. The firewall sees a legitimate packet on port 80 and waves it through. The bouncer checked the ID (the port), but the guest carried a weapon inside.

Google Cloud's shared responsibility model makes this distinction critical. Google secures the infrastructure; you secure your workloads. If you rely solely on VPC firewall rules, you are leaving application-layer security to chance. Attackers know this. They target the layers the firewall cannot see: the HTTP request body, the API payload, the authentication token. A recent high-profile breach of a cloud-based retailer started with a firewall rule that allowed HTTPS traffic — correct and necessary — but the attacker exploited a vulnerable endpoint in the application. The firewall never blinked.

This is not a flaw in Google Cloud's firewall. It is a design feature. Firewall rules are network-layer controls. They filter traffic based on source IP, destination IP, protocol, and port. They are excellent for blocking known bad actors, isolating environments, and enforcing network segmentation. But they are blind to the content of the traffic. Understanding this limitation is the first step to building a defense-in-depth strategy.

The bouncer analogy in practice

Imagine a nightclub bouncer named VPC. VPC checks every person at the door: are you on the guest list (allowed IP range)? Do you have a valid ID (protocol/port)? If yes, you enter. VPC does not ask why you are here, what you plan to do, or whether you have a hidden weapon. That is the job of the security team inside (the WAF, the intrusion detection system, the application itself). In the same way, your VPC firewall rules should be the first line of defense, not the last.

Core idea in plain language

A Google Cloud VPC firewall rule is a stateful filter that tracks connection state. When you allow inbound traffic from a specific IP range on port 443, the firewall automatically allows the return traffic for that connection. This is stateful behavior — it remembers who is inside the club and lets them leave and re-enter without a new ID check. Stateless firewalls, by contrast, require rules for both directions. Google Cloud firewall rules are stateful by default, which simplifies configuration but also means you cannot easily block specific packets within an established connection.

The core idea is simple: firewall rules operate at layers 3 and 4 of the OSI model (network and transport). They see IP addresses, TCP/UDP ports, and protocols. They do not inspect layer 7 content (application data). This is why a rule allowing traffic on port 443 cannot distinguish between a legitimate HTTPS request and a malicious one. The bouncer sees the same ID: port 443, TCP, from a valid IP.

Ingress vs. egress rules

Ingress rules control incoming traffic to your VMs. Egress rules control outgoing traffic. Both are stateful. A common mistake is to create overly permissive egress rules (e.g., allow all traffic to 0.0.0.0/0) because teams think outbound traffic is safe. But if a VM is compromised, egress rules are your last chance to prevent data exfiltration. The bouncer analogy applies here too: you want to check IDs on the way out, not just the way in.

Priority and implicit deny

Firewall rules have a priority (0–65535, lower number = higher priority). At the end of every evaluation, there is an implicit deny: if no rule matches, traffic is blocked. This is like a club policy: if you are not on the list, you do not enter. But the implicit deny only applies if no rule matches. If you have a rule that allows all traffic from 0.0.0.0/0 on a port, that rule matches everything, and the implicit deny is never triggered. This is a common source of accidental exposure.

How it works under the hood

Google Cloud firewall rules are implemented at the hypervisor level, not on the VM itself. Each VM instance has a virtual network interface that connects to a VPC network. When a packet arrives, the hypervisor checks the firewall rules associated with that VPC network and the VM's network tags or service accounts. The evaluation happens before the packet reaches the VM's operating system. This means firewall rules can block traffic even if the VM's OS firewall is misconfigured or disabled.

The rules are distributed to all hosts in the region. There is no central firewall appliance to bottleneck. This is a key advantage: the bouncer is everywhere at once. But it also means that firewall rules are eventually consistent — changes can take a few seconds to propagate across all hosts. During that window, old rules may still apply.

Stateful tracking in detail

When a packet matches an ingress allow rule, the firewall creates a state entry for that connection. The entry includes the source IP, destination IP, protocol, and ports. Return traffic for that connection is automatically allowed, regardless of egress rules. The state entry expires after a timeout (typically 10 minutes for TCP, 30 seconds for UDP). If no packets are exchanged during that time, the state is removed, and subsequent packets must match a rule again. This is why long-lived idle connections can be dropped — the bouncer forgets who you are if you stand in the corner for too long.

Network tags and service accounts

Firewall rules can target VMs by network tags or service accounts. Tags are simple labels you assign to VM instances (e.g., "web-server", "database"). Service accounts are identities for VMs. This allows fine-grained control: you can create a rule that allows traffic from the "web-server" tag to the "database" tag on port 3306. The bouncer checks the guest's badge (tag) before letting them into a specific area.

Worked example: A compromised web server

Let us walk through a realistic scenario. You have a Google Cloud project with a VPC network. You create a firewall rule that allows inbound TCP traffic on port 443 from 0.0.0.0/0 (the internet) to VMs with the tag "web-server". You also have a rule that allows inbound SSH (port 22) from your office IP range to the same VMs. This seems secure: only HTTPS from anywhere, and SSH only from your office.

Now imagine an attacker finds a vulnerability in your web application — an unpatched library that allows remote code execution. The attacker sends a crafted HTTPS request that exploits the vulnerability. The firewall sees a packet on port 443 from a valid IP (the attacker's IP is not on a blocklist) and allows it. The packet reaches the VM, the application processes it, and the attacker gains a shell. From there, the attacker can make outbound connections. The egress rule is likely set to allow all traffic (common default), so the attacker can exfiltrate data to an external server. The firewall never blocked the attack because it could not see the malicious payload inside the HTTPS request.

What the firewall could not do

The firewall did its job: it allowed legitimate HTTPS traffic. But the attack was at the application layer. To stop it, you would need a web application firewall (WAF) like Google Cloud Armor, which inspects HTTP requests and blocks malicious patterns (SQL injection, XSS, etc.). You would also need vulnerability scanning and patch management. The bouncer cannot read the letter inside the envelope.

What you can do instead

To prevent this scenario, layer your defenses. Use VPC firewall rules to restrict access to only necessary ports and IP ranges. Then add Cloud Armor for HTTP/S traffic, enable VPC Flow Logs for monitoring, and use Identity-Aware Proxy (IAP) for SSH access instead of opening port 22 to the internet. The bouncer is still there, but now there are additional checks inside the club.

Edge cases and exceptions

Not all traffic is treated equally by firewall rules. Here are common edge cases that can trip up even experienced teams.

Google Cloud health check ranges

Load balancers and other Google Cloud services send health checks from specific IP ranges. If you block these ranges, your load balancer may mark instances as unhealthy. The ranges are documented but change over time. A common mistake is to create a firewall rule that allows all traffic from 0.0.0.0/0 on the health check port, which is too permissive. Instead, use the documented ranges or use service accounts to allow health checks. The bouncer needs to let the health check team in, but only them.

Default rules

Every VPC network comes with four default firewall rules: allow ingress from the same network (all protocols), allow ingress TCP on port 22 from 0.0.0.0/0, allow ingress TCP on port 3389 from 0.0.0.0/0, and allow egress to 0.0.0.0/0 (all protocols). The SSH and RDP rules are there for convenience, but they are a security risk if you do not need them. Many teams forget to delete or tighten these rules. The bouncer is letting everyone with a key (port 22) into the VIP room.

Protocols other than TCP/UDP

Firewall rules can also filter ICMP and other protocols. But ICMP is often used for network diagnostics (ping). Blocking ICMP can break path MTU discovery, causing performance issues. The bouncer may block a harmless tool that helps the network function.

Limits of the approach

Even with perfect firewall rules, there are limits to what a network firewall can achieve. Understanding these limits helps you avoid over-reliance on a single control.

No application-layer inspection

As discussed, firewall rules cannot inspect HTTP headers, request bodies, or API payloads. They cannot detect malware in file uploads or block command injection. For that, you need a WAF or an intrusion prevention system (IPS). Google Cloud Armor provides WAF capabilities, and third-party solutions like Palo Alto Networks or Fortinet can be deployed as virtual appliances.

No user identity awareness

Firewall rules see IP addresses, not users. If an attacker steals a valid user's credentials and connects from a different IP, the firewall cannot distinguish the attacker from the legitimate user. This is why you need IAP or VPN with user authentication. The bouncer checks the ID, but the ID could be stolen.

No encryption inspection

If traffic is encrypted (HTTPS, SSH), the firewall cannot see inside the tunnel. It can only see the destination IP and port. This is why you need to decrypt traffic at a central point (like a reverse proxy or a next-generation firewall) to inspect it. Google Cloud offers Cloud IDS for network threat detection, but it also relies on packet inspection, not decryption.

Reader FAQ

Can I block a specific IP address with a firewall rule?

Yes. Create a deny rule with a higher priority (lower number) than the allow rule for that IP. For example, a deny rule for source IP 203.0.113.5 on all ports with priority 1000 will block that IP before an allow rule with priority 2000. The bouncer has a blacklist.

Do firewall rules apply to all VMs in a project?

Firewall rules are associated with a VPC network, not a project. Each VPC network has its own set of rules. Rules apply to all VMs in that network, unless you use network tags or service accounts to target specific VMs.

How do firewall rules interact with VM-level firewalls (iptables)?

Google Cloud firewall rules are evaluated before the packet reaches the VM. If the packet is allowed by the VPC firewall, it then hits the VM's OS firewall (e.g., iptables). Both must allow the traffic for it to reach the application. The bouncer is at the club entrance; the VM's firewall is the security guard at the VIP room door.

What is the difference between firewall rules and firewall policies?

Firewall policies are a hierarchical way to manage rules across multiple VPC networks in an organization. They are evaluated before VPC firewall rules. Policies are useful for central security teams to enforce baseline rules (e.g., block all traffic from known bad IPs). VPC firewall rules are more granular and per-network.

Can I log firewall rule matches?

Yes. You can enable firewall rules logging for each rule. Logs are sent to Cloud Logging and can be analyzed for suspicious traffic. This is like having the bouncer write down every ID check.

Practical takeaways

Firewall rules are a critical part of your Google Cloud security, but they are not sufficient on their own. Here are specific next moves.

Audit your default rules

Review the four default rules in each VPC network. Remove the SSH and RDP ingress rules from 0.0.0.0/0 if you use IAP or a VPN. Change the egress rule from allow all to a more restrictive set of destinations. The bouncer should not let everyone out without checking.

Use network tags for segmentation

Create tags for different tiers (web, app, database) and write firewall rules that only allow necessary traffic between them. For example, allow web servers to talk to app servers on port 8080, but not to databases directly. This limits lateral movement if one tier is compromised.

Add a WAF for HTTP/S traffic

If you run web applications, enable Google Cloud Armor. It integrates with the load balancer and can block OWASP Top 10 attacks, rate-limit, and filter by geographic region. The bouncer now has a metal detector.

Monitor firewall logs

Enable logging for critical rules (especially deny rules) and set up alerts for unexpected traffic patterns. Use VPC Flow Logs to see all network flows. This gives you visibility into who is trying to get in and out.

Test your rules regularly

Use tools like the Google Cloud Network Intelligence Center or third-party scanners to verify that only intended traffic is allowed. The bouncer may have a blind spot; find it before an attacker does.

Remember: your Google Cloud firewall is a bouncer, not a locked door. It is essential, but it is only the first layer. Build from there.