Virtual Private Cloud (VPC) firewall rules apply to a given project and network. If you want to apply firewall rules across an organization, see Firewall Policies. The rest of this page covers VPC firewall rules only.
VPC firewall rules let you allow or deny connections to or from your virtual machine (VM) instances based on a configuration that you specify. Enabled VPC firewall rules are always enforced, protecting your instances regardless of their configuration and operating system, even if they have not started up.
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 VPC firewall rules as existing not only between your instances and other networks, but also between individual instances within the same network.
For more information about firewalls, see Firewall (computing).
Firewall rules in Google Cloud
When you create a VPC firewall rule, you specify a VPC network and a set of components that define what the rule does. The components enable you to target certain types of traffic, based on the traffic's protocol, ports, sources, and destinations. For more information, see firewall rule components.
You create or modify VPC firewall rules by using the
Google Cloud 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.
In addition to firewall rules that you create, Google Cloud has other rules that can affect incoming (ingress) or outgoing (egress) connections:
Google Cloud doesn't allow certain IP protocols, such as egress traffic on TCP port 25 within a VPC network. For more information, see always blocked traffic.
Google Cloud always allows communication between a VM instance and its corresponding metadata server at
169.254.169.254. For more information, see always allowed traffic.
Every network has two implied firewall rules that permit outgoing connections and block incoming connections. Firewall rules that you create can override these implied rules.
The default network is pre-populated with firewall rules that you can delete or modify.
VPC firewall rules have the following characteristics:
Each firewall rule applies to incoming (ingress) or outgoing (egress) connection, not both. For more information, see direction of connection.
Firewall rules only support IPv4 connections. 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.
When you create a firewall rule, you must select a VPC network. While the rule is enforced at the instance level, its configuration is associated with a VPC network. This means that you cannot share firewall rules among VPC networks, including networks connected by VPC Network Peering or by using Cloud VPN tunnels.
VPC firewall rules are stateful.
- When a connection is allowed through the firewall in either direction, return traffic matching this connection is also allowed. You cannot configure a firewall rule to deny associated response traffic.
- Return traffic must match the 5-tuple (source IP, destination IP, source port, destination port, protocol) of the accepted request traffic, but with the source and destination addresses and ports reversed.
- Google Cloud associates incoming packets with corresponding outbound packets by using a connection tracking table.
- Google Cloud implements connection tracking regardless of whether the protocol supports connections. If a connection is allowed between a source and a target (for an ingress rule) or between a target and a destination (for an egress rule), all response traffic is allowed as long as the firewall's connection tracking state is active. A firewall rule's tracking state is considered active if at least one packet is sent every 10 minutes.
- ICMP response traffic, such as "ICMP TYPE 3, DESTINATION UNREACHABLE", generated in response to an allowed TCP/UDP connection is allowed through the firewall. This behavior is consistent with RFC 792.
VPC firewall rules do not reassemble fragmented TCP packets. Therefore, 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–8 vCPUs 130,000 connections per vCPU Instances with more than 8 vCPUs 1,040,000 (130,000×8) connections total
Every VPC network has two implied firewall rules. These rules exist, but are not shown in the Cloud Console:
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 Google Cloud. A higher priority firewall rule may restrict outbound access. Internet access is allowed if no other firewall rules deny outbound traffic and if the instance has an external IP address or uses a Cloud NAT instance. For more information, see Internet access requirements.
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 connections to them. A higher priority rule might allow incoming access. The default network includes some additional rules that override this one, allowing certain types of incoming connections.
The implied rules cannot be removed, but they have the lowest possible
priorities. You can create rules that override them as long as your rules have higher
priorities (priority numbers less than
deny rules take
allow rules of the same priority, an ingress
with a priority of
65535 never takes effect.
Pre-populated rules in the default network
The default network is pre-populated with firewall rules that allow incoming connections to instances. These rules can be deleted or modified as necessary:
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. This rule allows traffic in
10.255.255.254), a range that covers all subnets in the network.
Allows ingress connections on TCP port 22 from any source to any instance in the network. This rule has a priority of
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).
Allows ingress ICMP traffic from any source to any instance in the network. This rule has a priority of
65534, and it enables tools such as
Always blocked traffic
Google Cloud always blocks the traffic that is described in the following table. Your firewall rules cannot be used to allow any of this traffic.
|Always blocked traffic||Applies to|
|Certain GRE traffic (beta)||
• Traffic in Cloud VPN tunnels
• Traffic on Cloud Interconnect attachments (VLANs)
• Traffic for forwarding rules (load balacing or protocol forwarding)
GRE is allowed within a VPC network
|Protocols other than TCP, UDP, ICMP, AH, ESP, SCTP, and GRE to external IP addresses of Google Cloud resources||The type of resource further limits the protocol. For example, Network TCP/UDP Load Balancing supports only TCP and UDP. Also, a forwarding rule for protocol forwarding only processes a single protocol. Refer to the protocol forwarding documentation for a list of supported protocols.|
|Egress traffic to TCP destination port 25 (SMTP)||Traffic from:
• instances to external IP addresses on the internet
• instances to external IP addresses of instances
Always allowed traffic
Google Cloud runs a local metadata server alongside each instance at
169.254.169.254. This server is essential to the operation of the instance, so
the instance can access it regardless of any firewall rules that you configure. The
metadata server provides the following basic services to the instance:
- DNS resolution, following the name resolution order for the VPC network. Unless you have configured an alternative name server, DNS resolution includes looking up Compute Engine internal DNS and querying Cloud DNS zones and public DNS names.
- Instance metadata
- Network Time Protocol (NTP)
Firewall rule components
Each firewall rule consists of the following configuration components:
The direction of connection: ingress rules apply to incoming connections from specified sources to Google Cloud targets, and egress rules apply to connections going to specified destinations from targets.
A numerical priority, which determines whether the rule is applied. Only the highest priority (lowest priority number) rule whose other components match traffic is applied; conflicting rules with lower priorities are ignored.
An action on match, either
deny, which determines whether the rule permits or blocks connections.
The enforcement status of the firewall rule: You can enable and disable firewall rules without deleting them.
A target, which defines the instances (including GKE clusters and App Engine flexible environment instances) to which the rule applies.
A source for ingress rules or a destination for egress rules.
The protocol (such as TCP, UDP, or ICMP) and port.
|Ingress (inbound) rule|
|Priority||Action||Enforcement||Target (defines the destination)||Source||Protocols and ports|
||The target parameter specifies the destination; it can be one of the following:||One of the following:
||Specify a protocol or a protocol and a port.
If not set, the rule applies to all protocols.
|Egress (outbound) rule|
|Priority||Action||Enforcement||Target (defines the source)||Destination||Protocols and ports|
||The target parameter specifies the source; it can be one of the
||Any network or a specific range of IPv4 addresses; default is any (
||Specify a protocol or a protocol and a port.
If not set, the rule applies to all protocols.
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 connections 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, Google Cloud uses ingress.
Consider an example connection between two VMs in the same network. Traffic from VM1 to VM2 can be controlled by 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.
The firewall rule priority is an integer from
65535, inclusive. Lower
integers indicate higher priorities. If you do not specify a priority when
creating a rule, it is assigned a priority of
The relative priority of a firewall rule determines whether it is applicable when evaluated against others. The evaluation logic works as follows:
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
denyaction overrides another with an
allowaction only if the two rules have the same priority. Using relative priorities, it is possible to build
allowrules that override
denyrules that override
Rules with the same priority and the same action have the same result. However, the rule that is used during the evaluation is indeterminate. Normally, it doesn't matter which rule is used except when you enable Firewall Rules Logging. If you want your logs to show firewall rules being evaluated in a consistent and well- defined order, assign them unique priorities.
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
denyaction and a priority of
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
The priority of the second rule determines whether TCP traffic on port 80 is
allowed for the
If the priority of the second rule is set to a number greater than
1000, it has a lower priority, so the first rule denying all traffic applies.
If the priority of the second rule is set to
1000, the two rules have identical priorities, so the first rule denying all traffic applies.
If the priority of the second rule is set to a number less than
1000, it has a higher priority, thus allowing traffic on TCP 80 for the
webservertargets. Absent other rules, the first rule would still deny other types of traffic to the
webservertargets, and it would also deny all traffic, including TCP 80, to instances without the
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
Action on match
The action component of a firewall rule determines whether it permits or blocks traffic, subject to the other components of the rule:
allowaction permits connections that match the other specified components.
denyaction blocks connections that match the other specified components.
You can change whether a firewall rule is enforced by setting its state
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
The enforcement state for firewall rules can be changed from
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
enabled. When you need to perform maintenance, you can disable the rule. After you finish, enable the rule again.
For an ingress (inbound) rule, the target parameter designates the destination VM instances, including GKE clusters and App Engine flexible environment instances. For an egress (outbound) rule, the target designates the source instances. Thus, always use the target parameter to designate Google Cloud instances, 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 one of the following options:
All instances in the network. The firewall rule applies to all instances in the network.
Instances by target tags. The firewall rule applies only to instances with a matching network tag.
Instances by target service accounts. The firewall rule applies only to instances that use a specific service account. For the maximum number of target service accounts that you can apply per firewall rule, see VPC resource quotas.
For information about the benefits and limitations of target tags and target service accounts, see filtering by service account versus network tag.
Targets and IP addresses
The target of an ingress firewall rule applies to all traffic arriving on an instance's network interface (NIC) in the VPC network, regardless of how the target is specified. An ingress firewall rule takes effect on packets whose destinations match one of the following IP addresses:
The primary internal IP address assigned to the instance's network interface in the VPC network
Any configured alias IP ranges on the instance's network interface in the VPC network
The external IP address that's associated with the instance's network interface in the VPC network
An internal or external IP address associated with a forwarding rule, for load balancing or protocol forwarding, if the instance is a backend for the load balancer or is a target instance for protocol forwarding
The target of an egress firewall rule applies to all traffic leaving a VM instance's network interface (NIC) in the VPC network, regardless of how the target is specified:
- By default, IP forwarding is disabled. An egress firewall rule takes effect on
packets whose sources match any of the following:
- The primary internal IP address of an instance's NIC
- Any configured Alias IP range on an instance's NIC
- An internal or external IP address associated with a forwarding rule, for load balancing or protocol forwarding, if the instance is a backend for the load balancer or is a target instance for protocol forwarding
- When IP forwarding is enabled, the VM is permitted to send packets with any source.
Source or destination
You specify either a source or a destination, but not both, depending on the direction of the firewall that you create:
For ingress (inbound) rules, the target parameter specifies the destination instances 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 instances for traffic; you cannot use the source parameter. You specify the destination by using the destination parameter.
The source parameter is only applicable to ingress rules. It must be 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 addresses outside it. Source IP ranges can be used to define sources both inside and outside Google Cloud.
Source tags: You can define the source for packets as the primary internal IP address of the network interface of VM instances in the same VPC network, identifying those source instances by a matching network tag. Source tags only apply to traffic sent from the network interface of another applicable instance in your VPC network. A source tag cannot control packets whose sources are external IP addresses, even if the external IP addresses belong to instances. For the maximum number of source tags that you can apply per firewall rule, see VPC resource quotas.
Source service accounts: You can define the source for packets as the primary internal IP address of the network interface of instances in the same VPC network, identifying those source instances by the service accounts they use. Source service accounts only apply to traffic sent from the network interface of another applicable instance in your VPC network. A source service account cannot control packets whose sources are external IP addresses, even if the external IP addresses belong to instances. For the maximum number of source service accounts that you can apply per firewall rule, see VPC resource quotas.
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 source IP ranges, source tags, and source service accounts are omitted, Google Cloud defines the source as any IP address (
Sources and IP addresses
When you specify a source using one of the following methods, Google Cloud considers the source as only the primary internal IP address of the VM's network interface in the VPC network:
- Source tags
- Source service accounts
- A source specification that includes either source tags or source service accounts
Alias IP ranges for that NIC and IP addresses for associated forwarding rules are not included when using source tags or source service accounts.
If you need to include the alias IP ranges of a VM, add them to a source ranges list for an ingress rule. You can use source ranges and source tags together; and you can use source ranges and source service accounts together.
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 addresses outside it.
If you do not specify a destination range, Google Cloud defines the
destination to be all IP addresses (
Protocols and ports
You can narrow the scope of a firewall rule by specifying protocols or protocols and ports. You can specify a protocol or a combination of protocols and their ports. If you omit both protocols and ports, the firewall rule is applicable for all traffic on any protocol and any port.
To make a firewall rule specific, you must first specify a protocol. If the protocol supports ports, you can optionally specify a port number or port range. Not all protocols support ports, though. For example, ports exist for TCP and UDP, but not for ICMP. (ICMP does have different ICMP types, but they are not ports.)
You can specify a protocol by using its name (
ipip) or its
decimal IP protocol number.
Google Cloud firewall rules use port information to reference the destination port of a packet, not its source port:
For ingress (inbound) firewall rules, destination ports are ports on systems identified by the rule's target parameter. (For ingress rules, the target parameter specifies the destination VMs for traffic.)
For egress (outbound) firewall rules, destination ports represent ports on the systems identified by the rule's destination parameter.
The following table summarizes valid protocol and port specification combinations for Google Cloud firewall rules.
|No protocol and port||—||If you do not specify a protocol, the firewall rule applies to all protocols and their applicable ports.|
||If you specify a protocol without any port information, the firewall rule applies to that protocol and all its applicable ports.|
|Protocol and single port||
||If you specify a protocol and a single port, the firewall rule applies to that port of the protocol.|
|Protocol and port range||
||If you specify a protocol and a port range, the firewall rule applies to that port range for the protocol.|
||You can specify various combinations of protocols and ports to which the firewall rule applies. For more information, see creating firewall rules.|
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 in the same project as the firewall rule before you create a firewall rule that relies on it. While the system does not stop you from creating a rule that uses a service account from a different project, the rule is not enforced if the service account doesn't exist in the firewall rule's project.
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.
Filtering by service account versus 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 Identity and Access Management (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 by using a service account, that member must have the Service Account User role to at least that service account and 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).
If you specify targets by target tag or target service account, the following are invalid sources for ingress firewall rules.
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
Following are operational considerations for service accounts and network tags:
Changing a service account for an instance requires stopping and restarting it. Adding or removing tags can be done while the instance is running.
There are a maximum number of target service accounts, source service accounts, target network tags, and source network tags that can be specified for firewall rules. For more information, see VPC resource quotas.
If you identify instances by network tag, the firewall rule applies to the primary internal IP address of the instance.
Service account firewall rules apply to the GKE node, not the GKE Pod.
The following use cases demonstrate how firewall rules work. In these examples, all the firewall rules are enabled.
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 (
- 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 your VPC network,
including other sources on the internet, use a 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
The following diagram illustrates some examples where firewall rules can control ingress connections. The examples use the target parameter in rule assignments to apply rules to specific instances.
An ingress rule with priority
1000is 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 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 the implied deny ingress rule blocks external incoming traffic as well.
An ingress rule with priority
1000is 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 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 that 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
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 your network, including destinations on the internet.
The following diagram illustrates some examples where firewall rules can control egress connections. The examples use the target parameter in rule assignments to apply rules to specific instances.
VM 1 has no specified egress firewall rule, so the implied allow egress 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
1000is 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 network 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
1000is applicable to VM 3. This rule blocks its outgoing TCP traffic to any destination in the
192.168.1.0/24IP 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.
Also, VM 3 can send any traffic to other instances in the VPC network outside the
192.168.1.0/24IP 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 the VPC network.
- To create and work with firewall rules, see Using firewall rules.