Context
A permissive VPC firewall rule may never decide a connection if an organization or folder policy already matches it. Google Cloud firewall troubleshooting therefore needs the effective rule hierarchy, not just the rules visible in one project. Trace a specific connection through the applicable policies before creating another local allow.
Define the packet and the target
Record direction, source and destination addresses, protocol, destination port, target VM, network, service account, and relevant tags or secure tags. Use the translated address where the enforcement point sees a translated flow.
Separate a firewall denial from a missing route, failed listener, or unhealthy application. A connection test that times out does not reveal which layer caused the failure. Collect guest listener evidence and network configuration alongside firewall logs or analysis results.
Inventory policy associations
Hierarchical firewall policies can be associated with an organization or folder and affect resources beneath that scope. Creating a policy does not apply it everywhere automatically; association and resource placement matter.
Find the target project's position in the resource hierarchy and the effective policies inherited through it. Include network firewall policies and VPC rules according to the network's configured enforcement order. Do not assume a single universal ordering from a diagram that omits a supported policy layer.
Record rule priorities within their applicable policy. A low numerical priority in one local rule does not necessarily outrank an earlier decision at a higher level of the hierarchy. Priority values need policy context to be meaningful.
Interpret allow, deny, and delegation
An effective higher-level allow or deny can terminate evaluation for matching traffic. A goto_next action delegates evaluation to the next applicable layer; it is not a final allow. Google documents the exact matching and implied-rule behavior for each policy type.
Inspect target selectors carefully. A rule intended for a workload service account may not match a replacement VM with a different identity. Conversely, a broad inherited selector can affect more workloads than the project team expected.
Use supported effective-firewall views, connectivity analysis, and logging where available. Check their scope and freshness. Analysis of a configured path is valuable, but a live application request is still needed to verify the listener, identity, and business result.
An illustrative ineffective exception
A project team adds an ingress allow for a vendor integration. Traffic remains blocked because an inherited organization policy denies the source range before local rules can decide it. Repeatedly lowering the local rule's numerical priority changes nothing.
The network owners review the actual source and business requirement. They implement a narrowly scoped exception at the layer that owns the restriction, or delegate only the intended scope to a lower layer. The final test confirms the vendor path works while an unapproved source remains denied.
Quick diagnostic map
| Evidence | Boundary to investigate | Next check |
|---|---|---|
| Local allow has no effect | Earlier policy decision | Effective hierarchy and match |
| Rule works before project move | Inheritance changed | Folder and organization associations |
| Replacement VM differs | Selector mismatch | Service account and target attributes |
| Firewall allows; request still fails | Another network or application layer | Route, listener, and protocol |
A focused operator exercise
Create a test flow matrix containing an allowed source, a denied source, and a deliberately delegated case. Capture the target's hierarchy, effective policy associations, and matching rule identifiers. Run each request and compare the observed outcome with the intended decision.
Move a test resource or change a test association only within an isolated environment, then verify the resulting inheritance. Confirm the runbook identifies the deciding layer instead of prescribing a new broad VPC rule. Retain both positive and negative outcomes with the configuration revision.
Make exceptions maintainable
Give every exception an owner, purpose, scope, and review condition. Keep organization controls and project-level rules in compatible change workflows so one team does not unintentionally invalidate another's accepted path.
Monitor denied-flow changes after folder moves, service-account replacements, or policy updates. Maintain independent administrative recovery access appropriate to the environment. A policy architecture should explain both how application access is granted and how an erroneous restriction is repaired.
Frequently asked questions
Can a project rule override an inherited organization deny?
Not when the inherited rule has already made the applicable final decision. Change or scope the decision at the owning layer.
Does goto_next mean the packet is allowed?
No. It passes evaluation onward. The eventual result depends on the remaining applicable policies and rules.
Continue the investigation
- Organization Policy Denials: Fix the Deployment Contract
- Load Balancer Health Failures: Verify the Probe Path and Protocol
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Google Cloud Shared VPC & Private Access to discuss implementation, validation and operational handover.
Technical reference
Hierarchical firewall policies | Cloud Next Generation Firewall | Google Cloud Documentation