An engineer created a firewall rule to allow inbound HTTP traffic on port 80 from the internet to instances with the tag 'web-server'. However, after applying the rule, a test instance with the tag 'web-server' is still not reachable on port 80. What is a likely cause?
Trap 1: The firewall rule has a priority lower than 65535.
The priority value of a VPC firewall rule is a numeric ordering, where lower numbers take precedence over higher numbers. A priority lower than 65535 (e.g., the default 1000) simply means the rule is evaluated earlier, not that it is ineffective or overridden, provided no higher-priority rule matches first. In this scenario, the rule's action and direction are correct, so priority is irrelevant; the rule fails to apply because it targets a specific network tag, not because of its position in the evaluation order. Even a rule with priority 65535 would apply normally if its target matches the instance.
Trap 2: The instance is using a VPC with a custom subnet.
VPC firewall rules are scoped to the entire VPC network, not to individual subnets, so whether a subnet is auto-created or custom has no bearing on which firewall rules apply. Custom subnets only let you choose your own IP ranges and secondary ranges, but they do not change how firewall rules select instances—that selection is based on target tags, target service accounts, or all instances in the network. Therefore, an instance in a custom subnet is still subject to the same VPC-wide firewall evaluation as any other instance, and the missing 'web-server' tag is the actual reason the rule is ignored.
Trap 3: The firewall rule is denying outbound traffic.
GCP firewall rules are stateful, meaning that when an inbound connection is allowed, all subsequent outbound traffic belonging to that established connection is automatically permitted, even if a separate outbound deny rule exists. A rule that denies outbound traffic only blocks new outbound connections initiated from the instance; it does not block return packets for an already-allowed inbound flow. Since the engineer's rule is specifically allowing inbound HTTP, the return HTTP traffic from the instance is not affected by any outbound deny rule. The issue is not outbound denial but the instance's lack of the target network tag needed for the inbound allow rule to match.
- A
The firewall rule has a priority lower than 65535.
Why wrong: The priority value of a VPC firewall rule is a numeric ordering, where lower numbers take precedence over higher numbers. A priority lower than 65535 (e.g., the default 1000) simply means the rule is evaluated earlier, not that it is ineffective or overridden, provided no higher-priority rule matches first. In this scenario, the rule's action and direction are correct, so priority is irrelevant; the rule fails to apply because it targets a specific network tag, not because of its position in the evaluation order. Even a rule with priority 65535 would apply normally if its target matches the instance.
- B
The instance is using a VPC with a custom subnet.
Why wrong: VPC firewall rules are scoped to the entire VPC network, not to individual subnets, so whether a subnet is auto-created or custom has no bearing on which firewall rules apply. Custom subnets only let you choose your own IP ranges and secondary ranges, but they do not change how firewall rules select instances—that selection is based on target tags, target service accounts, or all instances in the network. Therefore, an instance in a custom subnet is still subject to the same VPC-wide firewall evaluation as any other instance, and the missing 'web-server' tag is the actual reason the rule is ignored.
- C
The firewall rule is denying outbound traffic.
Why wrong: GCP firewall rules are stateful, meaning that when an inbound connection is allowed, all subsequent outbound traffic belonging to that established connection is automatically permitted, even if a separate outbound deny rule exists. A rule that denies outbound traffic only blocks new outbound connections initiated from the instance; it does not block return packets for an already-allowed inbound flow. Since the engineer's rule is specifically allowing inbound HTTP, the return HTTP traffic from the instance is not affected by any outbound deny rule. The issue is not outbound denial but the instance's lack of the target network tag needed for the inbound allow rule to match.
- D
The instance does not have the 'web-server' network tag.
The engineer's firewall rule is configured to target instances that carry the 'web-server' network tag. GCP firewall rules can apply to all instances in a VPC, to instances with a specific tag, or to instances whose service account matches a given target. If the instance does not have the 'web-server' tag, the rule never enters into effect for that instance, so inbound HTTP traffic is not permitted. This is a common misconfiguration: the rule is correctly defined, but because the target tag is missing from the instance, the rule is simply not applied, leading to traffic being denied by the implicit deny-all rule.