Firewall Rules Overview

Google Cloud Platform (GCP) firewall rules let you allow or deny traffic to and from your virtual machine (VM) instances based on a configuration you specify. GCP firewall rules are applied at the virtual networking level, so they provide effective protection and traffic control regardless of the operating system your instances use.

Every VPC network functions as a distributed firewall. While firewall rules are defined at the network level, connections are allowed or denied on a per-instance basis. You can think of the GCP firewall rules as existing not only between your instances and other networks, but between individual instances within the same network.

Firewall rules in GCP

GCP firewall rules are specific to a VPC network. Each rule either allows or denies traffic when its conditions are met. Its conditions allow you to specify the type of traffic, such as ports and protocols, and the source or destination of the traffic, including IP addresses, subnets, and instances. Refer to firewall rule components for descriptions of the components that define a firewall rule.

Every network has two permanent implied firewall rules which permit outgoing connections and block incoming connections. Refer to the default and implied firewall rules section for more information about their applicability and how they interact with rules you define. Additionally, the default network is pre-populated with some additional editable rules.

You create or modify GCP firewall rules through the Google Cloud Platform Console, gcloud command line tool, and REST API. When you create or modify a firewall rule, you can specify the instances to which it is intended to apply by using the target component of the rule.

Specifications

Firewall rules have the following characteristics:

• Firewall rules are defined at the VPC network level, and are specific to the network in which they are defined. The rules themselves cannot be shared among networks.

• Firewall rules only support IPv4 traffic. When specifying a source for an ingress rule or a destination for an egress rule by address, you can only use an IPv4 address or IPv4 block in CIDR notation.

• The action taken by a firewall rule is either allow or deny. The rule cannot simply log as an action. Refer to the action on match component of a firewall rule for more information.

• Each firewall rule is defined to apply to either incoming (ingress) or outgoing (egress) traffic, not both. Refer to the direction of traffic component of a firewall rule for more information.

• GCP firewall rules are stateful. If a connection is allowed between a source and a target or a target and a destination, all subsequent traffic in either direction will be allowed as long as the connection is active. In other words, firewall rules allow bidirectional communication once a session is established. The connection is considered active if at least one packet is sent every 10 minutes. Firewall rules cannot allow traffic in one direction while denying the associated return traffic.

• GCP firewall rules do not reassemble fragmented TCP packets. Consequently, a firewall rule applicable to the TCP protocol can only apply to the first fragment because it contains the TCP header. Firewall rules applicable to the TCP protocol do not apply to the subsequent TCP fragments.

• The maximum number of tracked connections in the firewall rule table depends on the number of stateful connections supported by the machine type of the instance:

Instance Machine Type	Maximum Number of Stateful Connections
Shared-core machine types	130,000
Instances with 1 to 8 vCPUs	130,000 connections per vCPU
Instances with more than 8 vCPUs	1,040,000 (130,000×8) connections total

Default and implied rules

Every VPC network has two implied firewall rules. These rules exist, but are not shown in the Cloud Console:

• The implied allow egress rule: An egress rule whose action is allow, destination is 0.0.0.0/0, and priority is the lowest possible (65535) lets any instance send traffic to any destination, except for traffic blocked by GCP. Outbound access may be restricted by a higher priority firewall rule. Internet access is allowed if no other firewall rules deny outbound traffic and if the instance has an external IP address or uses a NAT instance. Refer to Internet access requirements for more details.

• The implied deny ingress rule: An ingress rule whose action is deny, source is 0.0.0.0/0, and priority is the lowest possible (65535) protects all instances by blocking incoming traffic to them. Incoming access may be allowed by a higher priority rule. Note that the default network includes some additional rules that override this one, allowing certain types of incoming traffic.

The implied rules cannot be removed, but they have the lowest possible priorities. Rules you create can override them as long as your rules have higher priorities (priority numbers less than 65535).

Note: Implied firewall rules are present in all VPC networks, regardless of how the networks are created, and whether they are auto or custom mode. The default network has the same implied rules.

Additional rules in the default network

In addition to the implied rules, the default network is pre-populated with firewall rules that allow incoming traffic to instances. These rules can be deleted or modified as necessary:

• default-allow-internal
  Allows ingress connections for all protocols and ports among instances in the network. This rule has the second-to-lowest priority of 65534, and it effectively permits incoming connections to VM instances from others in the same network.
• default-allow-ssh
  Allows ingress connections on TCP port 22 from any source to any instance in the network. This rule has a priority of 65534.
• default-allow-rdp
  Allows ingress connections on TCP port 3389 from any source to any instance in the network. This rule has a priority of 65534, and it enables connections to instances running the Microsoft Remote Desktop Protocol (RDP).
• default-allow-icmp
  Allows ingress ICMP traffic from any source to any instance in the network. This rule has a priority of 65534, and it enables tools like ping.

Note: These rules are included in the default network, but you can create your own rules that allow these types of traffic in your other networks.

Blocked traffic

Regardless of firewall rules, Google Cloud Platform always blocks the following traffic. Firewall rules cannot be used to un-block traffic that is always blocked.

Blocked traffic	Applies to
GRE traffic	All sources, all destinations, including among instances using internal IP addresses
Protocols other than TCP, UDP, ICMP, and IPIP	Traffic between: • instances and the Internet • instances if they are addressed with external IP addresses • instances if a load balancer with an external IP address is involved
Egress traffic on TCP port 25 (SMTP)	Traffic from: • instances to the Internet • instances to other instances addressed by external IP address

Firewall rule components

Each firewall rule consists of the following configuration components:

• A numerical priority, which is used to determine if the rule will be applied. Only the highest priority (lowest priority number) rule whose other components match traffic is applied; conflicting rules with lower priorities are ignored.

• The direction of traffic: ingress rules apply to incoming connections from specified sources to GCP targets, and egress rules apply to traffic going to specified destinations from targets.

• An action on match, either allow or deny, which determines if the rule permits or blocks traffic.

• A target, which defines the instances (including GKE clusters and App Engine Flex instances) to which the rule will apply.

• A source for ingress rules or a destination for egress rules

• The protocol (such as TCP, UDP, or ICMP) and port

• The enforcement status of the firewall rule: You can enable and disable firewall rules without deleting them.

Components summary

Priority	Direction	Action	Enforcement	Target	Source	Destination	Protocols, Ports
Integer from 0 to 65535, inclusive; default 1000.	ingress	Either allow or deny.	Either enabled (default) or disabled.	Instances receiving traffic from the source. One of the following: • All instances in the    VPC network • Instances by   service account • Instances by network tag	One of the following: • Range of IPv4 addresses;   default is any (0.0.0.0/0) • Instances by   service account • Instances by network tag	Destination is not specified separately for ingress rules. The target defines the destination.	Specify a protocol or protocol and a port. If not set, the rule applies to all protocols.
Integer from 0 to 65535, inclusive; default 1000.	egress	Either allow or deny.	Either enabled (default) or disabled.	Instances sending traffic to the destination. One of the following: • All instances in the    VPC network • Instances by   service account • Instances by network tag	Source is not specified separately for egress rules. The target defines the source.	Any network or a specific range of IPv4 addresses; default is any (0.0.0.0/0).	Specify a protocol or protocol and a port. If not set, the rule applies to all protocols.

Priority

The firewall rule priority is an integer from 0 to 65535, inclusive. Lower integers indicate higher priorities. If you do not specify a priority when creating a rule, it is assigned a priority of 1000.

The relative priority of a firewall rule determines if it is applicable when evaluated against others. The evaluation logic works as follows:

• Rules that apply to ingress traffic cannot conflict with rules that apply to egress traffic.

• The highest priority rule applicable to a target for a given type of traffic takes precedence. Target specificity does not matter. For example, a higher priority ingress rule for certain ports and protocols intended for all targets overrides a similarly defined rule for the same ports and protocols intended for specific targets.

• The highest priority rule applicable for a given protocol and port definition takes precedence, even when the protocol and port definition is more general. For example, a higher priority ingress rule allowing traffic for all protocols and ports intended for given targets overrides a lower priority ingress rule denying TCP 22 for the same targets.

• A rule with a deny action overrides another with an allow action only if the two rules have the same priority. Using relative priorities, it is possible to build allow rules that override deny rules, and vice versa.

Consider the following example where two firewall rules exist:

• An ingress rule from sources 0.0.0.0/0 (anywhere) applicable to all targets, all protocols, and all ports, having a deny action and a priority of 1000.

• An ingress rule from sources 0.0.0.0/0 (anywhere) applicable to specific targets with the tag webserver, for traffic on TCP 80, with an allow action.

The priority of the second rule determines whether TCP traffic on port 80 is allowed for the webserver targets:

• If the priority of the second rule is set to a number greater than 1000, it will have a lower priority, so the first rule denying all traffic will apply.

• If the priority of the second rule is set to 1000, the two rules will have identical priorities, so the first rule denying all traffic will apply.

• If the priority of the second rule is set to a number less than 1000, it will have a higher priority, thus allowing traffic on TCP 80 for the webserver targets. Absent other rules, the first rule would still deny other types of traffic to the webserver targets, and it would also deny all traffic, including TCP 80, to instances without the webserver tag.

The previous example demonstrates how you can use priorities to create selective allow rules and global deny rules to implement a security best practice of least privilege.

Note: Every network has two non-removable, low-priority, implied firewall rules, and the default network comes with additional removable firewall rules. Refer to default and implied rules for more information.

Direction of traffic

The direction of a firewall rule can be either ingress or egress. The direction is always defined from the perspective of the target.

• The ingress direction describes traffic sent from a source to a target. Ingress rules apply to packets for new sessions where the destination of the packet is the target.

• The egress direction describes traffic sent from a target to a destination. Egress rules apply to packets for new sessions where the source of the packet is the target.

• If you don't specify a direction, GCP uses ingress.

Consider an example connection between two VMs in the same network. Traffic from VM1 to VM2 can be controlled using either of these firewall rules:

• An ingress rule with a target of VM2 and a source of VM1.

• An egress rule with a target of VM1 and a destination of VM2.

Action on match

The action component of a firewall rule determines if it will permit or block traffic, subject to the other components of the rule:

• An allow action permits connections matching the other specified components.

• An deny action blocks connections matching the other specified components.

Note: A firewall rule can only have one action component. Both allow and deny cannot be specified in the same rule. Create separate firewall rules with different priorities to define the order in which the rules should be applied.

Enforcement

You can change whether or not a firewall rule is enforced by setting its state to enabled or disabled. Disabling a rule is useful for troubleshooting or to grant temporary access to instances. It's much easier to disable a rule, test, and then re-enable it, than it is to delete and re-create the rule.

Unless you specify otherwise, all firewall rules are enabled when they are created. You can also choose to create a rule in a disabled state.

The enforcement state for firewall rules can be changed from enabled to disabled and back by updating the rule.

Consider disabling a firewall rule for situations like these:

• For troubleshooting: If you're not sure whether a firewall rule is blocking or allowing traffic, disable it temporarily to determine if traffic is allowed or blocked. This is useful to troubleshoot the effect of one rule in conjunction with others.
• For maintenance: Disabling firewall rules can make periodic maintenance simpler. Suppose you have a firewall rule that blocks incoming SSH to targets (for example, instances by target tag), and that rule is usually enabled. When you need to perform maintenance, you can disable the rule. After you finish, enable the rule again.

Target

For an ingress (inbound) rule, the target parameter designates the destination VMs, including GKE clusters and App Engine Flex instances. For an egress (outbound) rule, the target designates the source VMs, clusters, and instances. Thus, the target parameter is always used to designate GCP VMs, but whether a target is a destination of traffic or a source for traffic depends on the direction of the rule.

You specify a target by using exactly one of the following options:

• All instances in the network: The firewall rule applies to all VMs in the network.

• Instances by target tags: The firewall rule applies only to VMs with a matching network tag.

• Instances by target service account: The firewall rule applies only to VMs that use a specific service account.

When you create rules that use tags or service accounts as the target parameter, the rules apply to the primary internal IP address of all targeted VMs in the network.

Firewall rules can be layered to create specific exceptions. For example, suppose you have a firewall rule with a priority of 1000 to block (deny action) incoming access (ingress direction) to VMs from the Internet (any IP, source 0.0.0.0/0). You have certain VMs that need to be able to respond to incoming Internet connections. You can create a second (900 for example) that allows incoming connections for the necessary protocols and ports. This second firewall rule will also need to be scoped to just the VMs needing incoming Internet connections. To scope this second rule, use either target tags or target service accounts. See filtering by service account vs. network tag for details about the benefits and limitations of each scoping method.

Source or destination

You specify either a source or a destination, but not both, depending on the direction of the firewall you create:

• For ingress (inbound) rules, the target parameter specifies the destination VMs for traffic; you cannot use the destination parameter. You specify the source by using the source parameter.

• For egress (outbound) rules, the target parameter specifies the source VMs for traffic; you cannot use the source parameter. You specify the destination by using the destination parameter.

Sources

The source parameter is only applicable to ingress rules. It must be exactly one of the following:

• Source IP ranges: You can specify ranges of IP addresses as sources for packets. The ranges can include addresses inside your VPC network and those outside of it. Source IP ranges can be used to define sources both inside and outside of GCP.

• Source tags: You can define the source for packets as the primary internal IP address of the network interface of other VMs in the same VPC network, identifying those source VMs by a matching network tag. Source tags only apply to other GCP VMs in your network.

• Source service accounts: You can define the source for packets as the primary internal IP address of the network interface of other VMs in the same VPC network, identifying those source VMs by the service account they use. Source service accounts only apply to other GCP VMs in your network.

• A combination of source IP ranges and source tags can be used.

• A combination of source IP ranges and source service accounts can be used.

• If all of source IP ranges, source tags, and source service accounts are omitted, GCP defines the source as any IP address (0.0.0.0/0).

Important: Network tags and service accounts cannot be used in the same firewall rule. Refer to filtering by service account vs. network tag for details.

Destinations

The destination parameter is only applicable to egress rules. The destination parameter only accepts IP address ranges. The ranges can include addresses inside your VPC network and those outside of it.

If you do not specify a destination range, GCP defines the destination to be all IP addresses (0.0.0.0/0).

Protocols and ports

Protocols and ports may be specified in a component for each firewall rule to narrow its intended applicability. You can specify a protocol, a protocol and one or more ports, a combination of protocols and ports, or nothing.

• If neither a protocol nor a port are specified, the firewall rule applies to all traffic (that is, any and all protocols and ports).

• You can specify a protocol using its name (tcp, udp, icmp, esp, ah, sctp, ipip) or its decimal protocol number. If you specify a protocol without a port (for example, tcp), the firewall rule applies to all ports associated with that protocol.

• If the protocol supports ports, you can specify a port or range of ports with the associated protocol:

  • To specify an individual protocol and port, separate the protocol and port with a colon (for example, tcp:80).

  • To specify a protocol and contiguous, inclusive range of ports, use a dash to define the range (for example, tcp:20-22).

  • To specify a protocol and a discontiguous range of ports, create multiple protocol/port combinations separated by a either a semicolon (if using the Cloud Console to create the rule) or a comma (if using gcloud). For example: tcp:80;tcp:443 (Console) or tcp:80,tcp:443 (gcloud)

• You can specify a multiple protocol and port combinations by separating each type of protocol or discontiguous port range with a semicolon (Cloud Console) or a comma (gcloud). For example: icmp;tcp:80;tcp:443;udp:67-69 (Console) or icmp,tcp:80,tcp:443,udp:67-69 (gcloud)

Note: The ICMP protocol does not have a concept of ports. You cannot use a port number as an attempt to specify ICMP types. You can only allow or disallow all ICMP traffic as a whole.

Caution: A port cannot be specified by itself. Specifying just a number defines the protocol, not the port. For example, if you specify 80 by itself, you will create a protocol component for IP protocol number 80 (ISO-IP). This is different than specifying tcp:80, which means TCP port 80.

Source and target filtering by service account

You can use service accounts to create firewall rules that are more specific in nature:

• For both ingress and egress rules, you can use service accounts to specify targets.

• For ingress rules, you can specify the source for incoming packets as the primary internal IP address of any VM in the network where the VM uses a particular service account.

The service account must be created before you create a firewall rule that relies on it.

Firewall rules that use service accounts to identify instances apply to both new instances created and associated with the service account and existing instances if you change their service accounts. Changing the service account associated with an instance requires that you stop and restart it. You can associate service accounts with individual instances and with instance templates used by managed instance groups.

Note: You can use service accounts from the same project where the firewall rule is defined or from other projects, such as Shared VPC host projects. However, you cannot use service accounts that come from other projects if you use VPC Network Peering to connect to networks in those other projects.

Filtering by service account vs. network tag

This section highlights key points to consider when deciding if you should use service accounts or network tags to define targets and sources (for ingress rules).

If you need strict control over how firewall rules are applied to VMs, use target service accounts and source service accounts instead of target tags and source tags:

• A network tag is an arbitrary attribute. One or more network tags can be associated with an instance by any IAM member who has permission to edit it. IAM members with the Compute Engine Instance Admin role to a project have this permission. IAM members who can edit an instance can change its network tags, which could change the set of applicable firewall rules for that instance.

• A service account represents an identity associated with an instance. Only one service account can be associated with an instance. You control access to the service account by controlling the grant of the Service Account User role for other IAM members. For an IAM member to start an instance using a service account, that member must have the Service Account User role to at least that service account as well as appropriate permissions to create instances (for example, having the Compute Engine Instance Admin role to the project).

You cannot mix and match service accounts and network tags in any firewall rule:

• You cannot use target service accounts and target tags together in any firewall rule (ingress or egress).

• The following are invalid sources for ingress firewall rules if you specify targets by target tag or target service account:

Targets	Invalid Sources
Target tags	Source service accounts Combination of source IP ranges and source service accounts
Target service account	Source tags Combination of source IP ranges and source tags

Operational considerations for service accounts and network tags are:

• Changing a service account for an instance requires stopping and restarting it. Adding or removing tags can be done while the instance is running.

• Only one target service account can be specified per firewall rule. More than one target tag can be specified in a single firewall rule.

• Only one source service account can be specified per ingress firewall rule. More than one source tag can be specified in a single firewall rule.

• If you identify instances by network tag, the firewall rule applies to the primary internal IP address of the instance.

Use cases

The following use cases demonstrate how firewall rules work. Note that all of the firewall rules are enabled in these examples.

Ingress cases

Ingress firewall rules control incoming connections from a source to target instances in your VPC network. The source for an ingress rule can be defined as one of the following:

• A range of IPv4 addresses; the default is any (0.0.0.0/0)
• Other instances in your VPC network identified by service account
• Other instances in your VPC network identified by network tags

The default source is any IP address (0.0.0.0/0). If you want to control incoming connections for sources outside of your VPC network, including other sources on the Internet, use a range of range of IPv4 addresses in CIDR format.

Ingress rules with an allow action permit incoming traffic based on the other components of the rule. In addition to specifying the source and target for the rule, you can limit the rule to apply to specific protocols and ports. Similarly, ingress rules with a deny action can be used to protect instances by blocking incoming traffic based on the firewall rule components.

Caution: You can also use target service accounts or target tags to specify the ingress destinations. If you do that, you limit how you can specify the source for the rule. Refer to filtering by service account vs. network tag for details.

Ingress examples

The following diagram illustrates some examples of ingress connections which can be controlled by firewall rules. The examples use the target parameter in rule assignments to apply rules to specific instances.

Ingress firewall rules example (click to enlarge)

• An ingress rule with priority 1000 is applicable to VM 1. This rule allows incoming TCP traffic from any source (0.0.0.0/0). TCP traffic from other instances in the VPC network is allowed, subject to applicable egress rules for those other instances. VM 4 is able to communicate with VM 1 over TCP because VM 4 has no egress rule blocking such communication (only the implied allow egress rule is applicable). Because VM 1 has an external IP, this rule also permits incoming TCP traffic from external hosts on the Internet.

• VM 2 has no specified ingress firewall rule, so the implied deny ingress rule rule blocks all incoming traffic. Connections from other instances in the network are blocked, regardless of egress rules for the other instances. Because VM 2 has an external IP, there is a path to it from external hosts on the Internet, but this implied deny rule blocks external incoming traffic as well.

• An ingress rule with priority 1000 is applicable to VM 3. This rule allows TCP traffic from instances in the network with the network tag client, such as VM 4. TCP traffic from VM 4 to VM 3 is allowed because VM 4 has no egress rule blocking such communication (only the implied allow egress rule is applicable). Because VM 3 does not have an external IP, there is no path to it from external hosts on the Internet.

Egress cases

Egress firewall rules control outgoing connections from target instances in your VPC network. Egress rules with an allow action permit traffic from instances based on the other components of the rule. For example, you can permit outbound traffic to specific destinations, such as a range of IPv4 addresses, on protocols and ports you specify. Similarly, egress rules with a deny action block traffic based on the other components of the rule.

Every egress rule needs a destination. The default destination is any IP address (0.0.0.0/0), but you can create a more specific destination by using a range of IPv4 addresses in CIDR format. When specifying a range of IPv4 addresses, you can control traffic to instances in your network and to destinations outside of your network, including destinations on the Internet.

Egress examples

The following diagram illustrates some examples of egress connections which can be controlled by firewall rules. The examples use the target parameter in rule assignments to apply rules to specific instances.

Egress firewall rules example (click to enlarge)

• VM 1 has no specified egress firewall rule, so the implied allow egress rule rule lets it send traffic to any destination. Connections to other instances in the VPC network are allowed, subject to applicable ingress rules for those other instances. VM 1 is able to send traffic to VM 4 because VM 4 has an ingress rule allowing incoming traffic from any IP address range. Because VM 1 has an external IP address, it is able to send traffic to external hosts on the Internet. Incoming responses to traffic sent by VM 1 are allowed because firewall rules are stateful.

• An egress rule with priority 1000 is applicable to VM 2. This rule denies all outgoing traffic to all destinations (0.0.0.0/0). Outgoing traffic to other instances in the VPC is blocked, regardless of the ingress rules applied to the other instances. Even though VM 2 has an external IP address, this firewall rule blocks its outgoing traffic to external hosts on the Internet.

• An egress rule with priority 1000 is applicable to VM 3. This rule blocks its outgoing TCP traffic to any destination in the 192.168.1.0/24 IP range. Even though ingress rules for VM 4 permit all incoming traffic, VM 3 cannot send TCP traffic to VM 4. However, VM 3 is free to send UDP traffic to VM 4 because the egress rule only applies to the TCP protocol. Additionally, VM 3 can send any traffic to other instances in the VPC network outside of the 192.168.1.0/24 IP range, as long as those other instances have ingress rules to permit such traffic. Because it does not have an external IP address, it has no path to send traffic outside of the VPC network.

What's next

• See Using Firewall Rules for instructions on creating and working with firewall rules.