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.

  • There is no logging mechanism for firewall rules.

  • 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. In other words, firewall rules allow bidirectional communication once a session is established. 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 130000
Instances with 1 to 8 CPUs 130000 connections per CPU
Instances with more than 8 CPUs 1040000 (130000×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. 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).

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.

Always-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, unless explicitly allowed through protocol forwarding
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
Egress traffic on TCP port 465 or 587 (SMTP over SSL/TLS) Traffic from:
• instances to the Internet, except for traffic destined for known Google SMTP servers
• 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 Kubernetes Engine 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

  • (Beta) 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
Not applicable to ingress rules. The target is 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
Not applicable to egress rules. The target is 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.

Direction of traffic

The direction component of a firewall rule determines if it applies to incoming or outgoing traffic, from the perspective of the target. Ingress and egress rules may allow or deny traffic, depending on the associated action.

  • The ingress direction applies to new, incoming connections to targets from a source. The default source is any address (0.0.0.0/0), but you can make it more specific by using a range of IP addresses in CIDR format, or by identifying other instances in the network by service account or network tag.

  • The egress direction applies to traffic leaving from targets to specified destinations. The default destination is any address (0.0.0.0/0), but you can make it more specific with a range of IP addresses in CIDR format.

When creating firewall rules intended to control traffic among instances, it's important to define the target of the rule. The relationship between the direction and the target can be summarized as follows:

  • If the direction is ingress, the target is the destination for incoming traffic from a specified source.

  • If the direction is egress, the target is the source for outgoing traffic to a specified destination.

Consider example, a connection from an instance named VM1 to another instance named VM2 in the same network could be controlled using either of these firewall rules:

  • An ingress rule where the target is defined as VM2 (by tag or service account) and the source is defined as VM1 (by its IP address or service account).

  • An egress rule where the target is defined as VM1 (by tag or service account) and the destination is defined as VM2 by its IP address.

Action on match

The action component of a firewall rule determines if it will permit or block traffic, if traffic matches the other components of the rule. The action and direction components are used together to build rules that allow or deny incoming or outgoing connections.

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

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

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, 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 choose to create a rule in a disabled state instead.

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 network tag), and that rule is usually enabled. When you need to perform mainteance, you can disable the rule. After you finish, enable the rule again.

Target

The target component of a firewall rule defines the instances to which it is intended to apply, including Kubernetes Engine clusters and App Engine Flex instances. Choices for targets are:

  • All instances in the network: The firewall rule is intended apply to all instances in the network.

  • Specific instances by target tag: The firewall rule is intended apply only to instances if they have a matching network tag.

  • Specific instances by service account: The firewall rule is intended apply only to instances using a service account.

Firewall rules can be layered to create exceptions for specific instances.

For example, suppose you have a firewall rule with a priority of 1000 to block (deny action) incoming access (ingress direction) to instances from the Internet (any IP, source 0.0.0.0/0). You have certain instances that need to be able to respond to incoming Internet connections. You can create a second firewall rule with a higher priority (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 instances needing incoming Internet connections because its priority is higher. To scope the second rule, specify a target using a service account or network tag. Either method for specifying the target is a valid way to identify the instances to which it should apply; however, these two methods are designed for different use cases. Refer to filtering by service account vs. network tag for details about the benefits and limitations for each.

In the previous example, the two firewall rules work together, blocking incoming traffic to all instances, except for specific traffic to instances identified by service accounts or tags.

Sources and destinations

Every firewall rule has either a source or destination component depending on its direction.

  • An ingress rule must have an associated source. The default source is all incoming traffic (0.0.0.0/0). To narrow the source, use a source filter, which can be a range of IP addresses (either inside or outside of GCP), or instances identified by service accounts or network tags. Refer to filtering by service account vs. network tag for details about the benefits, limitations, and use cases for each type of identification method.

  • An egress rule must have an associated destination. The default destination is any IP address (0.0.0.0/0). To narrow the destination, you can specify a range of IP addresses (either inside or outside of GCP) with a destination filter.

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 a port or range of ports, a combination of protocols and ports, or nothing.

  • If neither a protocol nor a port are specified, the firewall rule will apply 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 will apply 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)

Source and target filtering by service account

You can limit the target and source (for ingress rules only) to GCP resources by using an IAM service account. Rules scoped in this way apply apply to new instances created and associated with the service account and existing instances if you modify their service account associations.

A service account must be created before you create a firewall rule that relies on it for a target or source. Service accounts can be defined in the same project where the firewall is created, or they can be sourced from a host project if the project where the firewall rule is created is connected to it using Shared VPC.

You cannot use service accounts that come from other projects if you are connecting to networks in those other projects using VPC Network Peering.

Service accounts can be associated with manually created instances and those that are created automatically, such as from a managed instance group using autoscaling.

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 limit the target or source (for ingress rules only) for a firewall rule:

  • A service account represents an identity associated with an instance. Only one service account can be associated with an instance.

  • Associating a service account with an instance requires that a user explictly be granted the Compute Engine Service Account User role for that service account, as well as have permission to edit the instance to which it will be associated (such as having the Compute Engine Instance Admin role as well).

  • A tag is an arbitrary attribute assigned to an instance. One or more tags may be associated with an instance by any user who has permission to edit the instance (having just the Compute Engine Instance Admin role, for example).

  • Changing a service account for an instance requires stopping and restarting it. Adding or removing tags for an instance can be done without interrupting it, because tags are simply metadata attributes.

  • Only one service account can be specified for the target or source component in a firewall rule.

  • One or more network tags can be specified for the target or source component in a firewall rule.

  • When identifying instances by network tag, the firewall rule will apply to the primary internal IP address of the instance.

If you need strict control over the application of firewall rules, use service accounts to limit their applicability to targets or sources instead of network tags. Any user with the instance admin role can apply arbitrary tags to instances, even after their instances are running. If firewall rules are scoped by network tag, this means that instance admins can change which firewall rules apply to their instances, potentially circumventing organizational security policies. Firewall rules scoped to service accounts provide an authenticated mechanism because instance admins must also be granted the Compute Engine Service Account User role for any service account they intend to associate with their instances.

Use cases

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

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:

Egress firewall rules example (click to enlarge)
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, 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, 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.

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.

Ingress examples

The following diagram illustrates some examples of ingress connections which can be controlled by firewall rules:

Ingress firewall rules example (click to enlarge)
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 1 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.

What's next