Firewall rule priority defines the order in which Google Cloud processes security rules against incoming or outgoing network packets. Rule priorities are configured as integer values, where 0 represents the highest possible priority and larger numbers represent lower priority. For VPC firewall rules created without an explicit priority, the platform assigns a default priority of 1000. Administrators should space rule priorities at intervals such as 100, 200, and 300 to permit the insertion of intermediate rules without renumbering existing configurations.
Rule processing follows a first-match mechanism based on descending numerical priority order. When traffic matches a rule, Google Cloud applies one of three primary actions: Allow permits the packet to pass and terminates further rule evaluation across lower-priority firewall rules; Deny blocks the packet immediately and terminates further rule evaluation across lower-priority firewall rules; and Go to next continues packet evaluation by delegating the decision to subsequent rules or lower levels in the policy hierarchy via the goto_next action. If traffic reaches the end of a hierarchical policy level without encountering a matching rule, the evaluation logic defaults to an implicit goto_next behavior to process lower-level rules. Rules inherited from higher tiers in the resource hierarchy cannot be overridden by lower-level rules, ensuring consistent enforcement of organization-wide security boundaries.
Traffic evaluation sequences depend directly on the direction of network communication and the presence of network inspection policies. For ingress traffic arriving at a virtual machine (VM), Google Cloud evaluates incoming packets against firewall policy rules first. If an ingress firewall rule denies the packet, the connection drops immediately, preventing further processing or mirroring; if an allow rule permits the packet, the traffic is then evaluated against mirroring rules to determine if it should be sent to a collector. If no custom ingress rules match standard VPC traffic, the implied deny ingress rule blocks the connection. However, VPC networks configured with a remote direct memory access over converged ethernet (RoCE) network profile implement an implied ingress allow all rule by default.
For egress traffic departing from a VM, Google Cloud reverses the inspection order by evaluating packets against packet-mirroring rules before processing egress firewall policy rules. The system checks egress mirroring rules by priority, applies a MIRROR or DO_NOT_MIRROR decision, and subsequently forwards the traffic to the egress firewall rule engine. The firewall engine checks custom egress rules in priority order and falls back to an implied IPv4 allow egress rule if no higher-priority rules match. Because logging cannot be enabled directly on implied firewall rules, administrators must deploy explicit custom rules such as an ingress deny rule or an egress deny rule at priority 65534 with logging enabled to capture and audit unhandled traffic.
Rule matching logic evaluates a packet against an ordered combination of targets, directions, sources, destinations, and Layer 4 protocol and port specifications. Target parameters define which VM network interfaces enforce the rule, identified using network tags, Identity and Access Management (IAM) service accounts, or secure tags. For ingress traffic, the engine matches against defined source filters, including IPv4/IPv6 Classless Inter-Domain Routing (CIDR) blocks, secure tags, domain names, or regional and global address groups. For egress rules, the engine evaluates destination CIDR ranges or specific backend endpoint subnets.
Layer 4 configuration matching requires traffic to satisfy specified protocol and port constraints. Administrators can match all protocols or restrict matching to specific protocols and destination ports, such as individual TCP or UDP ports like port 22 for SSH or port 80 for HTTP and port ranges such as tcp:5000-6000. When managing complex environments like Private Service Connect (PSC) interfaces or database producer-consumer models, specific narrow allow rules at higher priorities such as priority 100 or 1000 override broad deny rules at lower priorities such as priority 65534. This layered priority matching ensures granular access controls while maintaining default-deny perimeters across network boundaries.
VPC Firewall rules control traffic flowing into and out of Virtual Private Cloud networks by evaluating packets against defined criteria. Each rule specifies a direction of trafficâeither ingress for incoming traffic or egress for outgoing trafficâalong with an action to either allow or deny matching traffic. The rules are evaluated in priority order, where a lower numerical priority value means the rule is evaluated first; for example, a rule with priority 100 is evaluated before one with priority 200.
When creating a VPC firewall rule, you must define the target that receives the traffic, which can be all instances in the network, instances with specific network tags, or instances using particular service accounts. For ingress rules, you specify source IP ranges in CIDR notation to define where traffic originates, while egress rules use destination IP ranges to define where traffic is headed. If source ranges are omitted for an ingress rule, the default source becomes any IPv4 address (0.0.0.0/0), which can create security gaps if not carefully managed.
Protocol and port filtering determines which network protocols and destination ports a firewall rule affects. When you specify protocols and ports, you can choose to apply the rule to all protocols and ports, or narrow it to specific combinations. For TCP and UDP protocols, you can specify individual ports like port 80 for HTTP or port 443 for HTTPS, or define ranges such as ports 20-22 for multiple administrative services.
For VPC Firewall rules, you configure protocols and ports using the Specified protocols and ports option, where you select the protocol checkboxes (TCP, UDP, or Other) and enter port numbers or ranges in the associated fields. For more complex scenarios, you can enter comma-delimited lists like 20-22, 80, 8080 to cover multiple ports with a single rule. The "Other" protocol option allows you to specify protocols by name such as icmp for IPv4 ICMP or sctp for Stream Control Transmission Protocol, or by their IANA protocol numbers like protocol number 1 for ICMP or protocol number 58 for IPv6 ICMP.
Hierarchical firewall policies provide organization-wide firewall rule management that propagates down through folders and projects. These policies allow security administrators to define centralized rules that apply across multiple VPC networks without configuring rules individually on each network. When you create a hierarchical firewall policy, you define rules with priorities, directions, actions, and target specifications similar to VPC firewall rules, but the policy is evaluated in the context of the organizational hierarchy.
You can create hierarchical firewall policies with rules that use the goto_next action to delegate traffic handling to the next rule in the evaluation hierarchy, which is useful when building layered security controls. For example, a rule with priority 300 might use goto_next to pass traffic to the implied IPv4 allow egress rule, while a lower priority rule like 400 denies all other egress traffic. This layering allows for granular control where specific allowed traffic is handled by higher-priority rules before falling through to broader deny rules.
Regional network firewall policies (also called Cloud NGFW policies) provide next-generation firewall capabilities for specific VPC networks, particularly those using specialized network profiles like RDMA over Converged Ethernet (RoCE). These policies support advanced filtering options including secure tags for source and destination identification, address groups for managing collections of IP addresses, and domain names for application-layer filtering.
When creating rules within regional network firewall policies, you specify layer 4 configurations that define the protocol and port combinations, such as tcp:80 for HTTP traffic or tcp:5000-6000 for a range of ports. The policies also support combining multiple source parametersâyou can specify source IP ranges, source network types like VPC_NETWORKS or INTRA_VPC, address groups, and domain names together to create complex matching conditions. This flexibility enables security teams to implement fine-grained controls that align with specific application requirements and security best practices.
Through the Google Cloud console, you create firewall rules by navigating to the Firewall policies page and clicking Create firewall rule. The console presents a form where you enter the rule name, select the network, set the priority, choose the traffic direction (Ingress or Egress), select the action (Allow or Deny), define the target instances, specify source or destination IP ranges, and configure the protocols and ports. The console provides dropdown selections and input fields that guide you through each parameter, reducing the chance of configuration errors.
For hierarchical firewall policies specifically, the console workflow includes selecting the policy, clicking Add rule, and then filling in the priority, description, direction, action, target network, source or destination ranges, and protocol specifications. The console also provides options to enable logging on rules, which captures connection information for security monitoring and troubleshooting. Logging can be particularly valuable for understanding what traffic is being allowed or denied and for detecting potential security issues.
The gcloud command-line interface provides programmatic control over firewall rule creation, using commands like gcloud compute firewall-rules create with numerous flags to specify all rule parameters. Key flags include --network for the VPC network, --priority for evaluation order, --direction for traffic direction (ingress or egress), --action for allow or deny, and --rules for protocol and port specifications.
For network firewall policies, the gcloud compute network-firewall-policies rules create command creates rules within regional policies, with flags like --layer4-configs for protocol and port definitions, --src-ip-ranges for source addresses, and --src-secure-tag or --target-secure-tag for tag-based targeting. The CLI also supports disabling rules without deleting them using the --disabled flag, which is useful for temporarily removing a rule's effect while preserving its configuration for future use.
Effective traffic filtering requires applying the principle of least privilege by specifying the narrowest possible source, destination, and port combinations that meet your application needs. The documentation warns against omitting source parameters because doing so defaults to 0.0.0.0/0, potentially allowing traffic from any internet address. Instead, you should define specific IP ranges, network tags, or service accounts that precisely identify your trusted traffic sources.
When configuring egress rules, remember that VPC networks have an implied allow egress rule that permits all outbound traffic by default, while ingress traffic is blocked by an implied deny rule. This asymmetry means that egress filtering often requires explicitly creating deny rules to block unwanted outbound traffic, whereas ingress filtering typically requires creating allow rules to permit necessary inbound connections. Understanding these defaults helps you design appropriate security boundaries that align with your organization's requirements.
For an ingress firewall rule, the source criteria define the originating points from which traffic is allowed to flow into a target resource. Common sources include specific IPv4 ranges like 130.211.0.0/22 for Google Cloud health checks, IPv6 ranges, or entire subnets. When a source IP range is omitted from a rule, Google Cloud interprets it to mean any source (0.0.0.0/0), which creates a broad permission. A more secure approach is to specify restrictive source ranges, such as limiting SSH access (tcp:22) to only the IP ranges of administrative systems rather than the entire internet. The source filter can be set to IPv4 ranges or IPv6 ranges, and the rule will only match traffic originating from the specified CIDR blocks.
The destination or target criteria in a firewall rule specify which Google Cloud resources the rule applies to, determining where the traffic is allowed to go. For VPC firewall rules, targets can be defined using network tags like allow-health-check or service accounts attached to virtual machine (VM) instances. For more advanced control, global network firewall policies can use IAM-governed secure tags as targets. The rule's actionâallow or denyâis then enforced on traffic flowing between the specified source and the targeted destinations. Without a correctly configured destination target, even a well-specified source range will not apply its action to the intended backend instances.
Validation of source and destination criteria occurs during the firewall rule evaluation order. The VPC network's default deny ingress rule blocks all incoming traffic unless an explicit allow rule matches. Therefore, an allow rule must have a valid, higher-priority match for both its source and target parameters. For example, a rule allowing health check traffic must specify both the Google Cloud probe IP ranges as the source and the correct network tag on the backend VMs as the target. Rules are evaluated from lowest priority number (highest precedence) to highest, so a rule with a priority of 1000 allowing a specific subnet will be evaluated before a lower-priority rule that might deny broader traffic.
In global network firewall policies, source and destination criteria gain additional capabilities and different constraints compared to VPC firewall rules. These policies support using address groups and fully qualified domain names (FQDNs) as source or destination objects for egress rules. However, a key difference is that global network firewall policy rules cannot use service accounts as a source for ingress rules, whereas VPC firewall rules can. The migration of VPC rules to a global policy requires careful validation, as the tool automatically adjusts rule priorities to avoid overlaps, giving deny rules higher precedence than allow rules to maintain security intent.
StudyCerts
StudyCerts0 being the highest priority and the default priority being 1000 when not specified.For ingress traffic arriving at a VM, Google Cloud evaluates firewall policy rules first; if the traffic is allowed, it is then evaluated against mirroring rules. For egress traffic departing from a VM, the order is reversedâpacket-mirroring rules are evaluated before firewall policy rules. This difference matters when designing inspection and logging strategies.
Leaving space between priority numbers (using 100, 200, 300 rather than consecutive numbers) allows you to insert new rules between existing ones without renumbering the entire configuration. This makes ongoing rule management easier and reduces the risk of accidental misconfigurations when adding new security rules.
No, global network firewall policy rules cannot use service accounts as a source for ingress rules, whereas VPC firewall rules can. This is an important difference to understand when migrating rules between policy types, as you may need to redesign your source filtering approach.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills