Google Cloud Platform (GCP)
protects your virtual machine (VM) instances from unapproved connections,
both inbound (
ingress) and outbound (
egress). You can create
firewall rules to allow or deny specific connections based on a combination
of IP addresses, ports, and protocol.
To learn more about firewall rules in general, read the firewall documentation on the Networking page.
Firewall rules in GCP
Every GCP network also functions as a managed, distributed firewall. While firewall rules are applied to the network as a whole, the connections are allowed or denied at the instance level. You can think of the firewall as existing not only between your instances and other networks, but between individual instances within the same network.
Unless you specify otherwise, GCP applies every rule to every instance in the given network. For example, a firewall rule that denies connections from a range of IP addresses will deny those connections for all instances in the network.
You can restrict which instances a rule applies to by using target tags. For example, you can create a firewall rule that allows only instances marked with a particular tag to reach certain IP ranges.
If all firewall rules in a network are deleted, there is still an implied "Deny all" ingress rule and an implied "Allow all" egress rule for the network.
Firewall rule components
You can express your desired firewall configuration as a set of firewall rules. Conceptually, a firewall rule is composed of the parameters described in the following sections.
Action of the rule
A rule can either allow or deny connections that match the rest of the rule.
allowrules allow connections matching the specified conditions to arrive or leave instances, depending on the
directionof the rule.
denyrules deny connections matching the specified conditions from arriving at or leaving instances, depending on the
directionof the rule.
You cannot specify both
deny in the same firewall
rule. However, you can specify multiple overlapping or conflicting
deny firewall rules. If two rules conflict, then the rule with the highest
priority is used. If both rules have the same
priority, then the
rule is used.
Direction of the rule
You can specify that a rule only applies to inbound (
ingress) or outbound
egress) connections. If not specified, then the rule applies only to
- For the ingress direction, sources can be specified as part of the rule.
- For the egress direction, destinations can be specified as part of the rule.
Sources or destinations for the rule
An ingress rule may be configured to only affect connections coming from particular sources, indicated by source IP addresses or source tags.
An egress rule may be configured to only affect connections headed for particular destinations, indicated by destination IP addresses.
If sources or destinations are unspecified, then the rule applies to all sources and destinations.
Protocols and ports
Any rule may be restricted to apply to specified protocols, or protocols and
ports, only. For example, a rule that blocks traffic from a certain IP address,
but which doesn't specify a protocol or port, blocks traffic from all protocols
and ports from that IP address. A rule that blocks
tcp:80 traffic from that
IP address will block only TCP traffic on port
80 from that address.
If protocols are unspecified, the rule applies to all protocols. If ports are unspecified, then the rule applies to all ports for any specified protocols.
Instances to which the rule is applied
By default, every rule governs every instance in the network. So, if a rule
allows inbound traffic on a particular port, every instance in the network
will be able to receive traffic on that port. However, you can assign
targetTags to certain instances and assign the same tag to a firewall
rule. In this way, you can apply that rule only to the instances with that tag.
If no tag is specified, then the rule applies to all instances in the network.
Specifying priority order for firewall rules
Two rules may conflict, such as a case when one rule denies certain
connections from all instances but a second rule allows those connections
for a certain subset of instances. Relative priority determines the
precedence of the rules. In this case, the rule allowing the
connections for the subset of instances should have a higher priority
than the other rule so that the limited
allow rule is evaluated first. If
deny rule had higher priority, then it would be evaluated first
and the selective
allow rule would never be evaluated, blocking connections
that should be permitted.
Priority may be any integer value from
inclusive. When unspecified, a priority value of
1000 is given. A lower
priority "number" indicates higher priority, so a rule with a priority of
has a higher priority than, and is evaluated before, a rule with a priority of
2. If a connection matches conflicting rules with same priority, the deny
policy takes precedence.
See Default firewall rules for a list of default rules and their priorities.
- Only IPv4 addresses are supported in a firewall rule.
- Fragmented packet will not match a TCP port rule because the firewall is not re-assembling the packet before checking the firewall rule. Only the first fragment, which contains the TCP header, can match the firewall rule.
- GCP firewall cannot log as an action. It can only accept or reject a connection. GCP does not collect statistics per rule at this time.
- Firewall rules are specific to a network. They cannot be shared between networks.
GCP firewall rule summary table
The following table summarizes firewall behavior. The phrase “all traffic” as used here refers to all traffic of the specified protocol and specified ports or port ranges (if any).
|GCP firewall rule Direction||GCP firewall rule order||GCP firewall rule conditions||GCP firewall rule applied to||GCP firewall action|
|Priority||Protocol||Port||Source||Destination||GCP Virtual Network||TargetTag||Allow OR deny|
(Default: All ports)
Src IP CIDR OR
no target tag)
(Default: All ports)
Dst IP CIDR
no target tag)
Supported parameter combinations are as follows:
egresscannot be specified simultaneously in a single rule.
- The ingress direction and destination combination are not supported in a single rule.
egressdirection and source combination are not supported in a single rule.
denycannot be specified simultaneously in a single rule.
Default firewall rules
There are default firewall rules that are created by each GCP virtual network.
All networks have certain rules. The
default network that is automatically
created with every project has additional rules. This section
describes the firewall rules that exist in both kinds of networks.
Default rules have a very low priority. Rules you create will take precedence over these rules unless you explicitly give your rules a low priority as well.
All networks, whether a project's
default network or a manually
created network, have the following firewall rules.
Allows all egress connections. Rule has a priority of
Deny all ingress connection. Rule has a priority of
[NETWORK-NAME] is the name of the network containing the rule. In the
network, the names would be
In addition, a project's
default network is created with the following
default firewall rules.
Allows ingress network connections of any protocol and port between instances on the network. Rule has a priority of
Allows ingress TCP connections from any source to any instance on the network over port 22. Rule has a priority of
Allows ingress ICMP traffic from any source to any instance on the network. Rule has a priority of
Allows ingress remote desktop protocol traffic to TCP port 3389. Rule has a priority of
These last rules only automatically exist in the
default network. They
must be manually created in other networks, if desired.
If all rules, including the
[NETWORK-NAME]-deny-ingress rule, are deleted and
no rules are configured at all, an implicit "Deny-all" still
applies to the ingress direction. In other words, even if you delete the default
"Deny-all" rule, you must still create an
allow rule to allow inbound
traffic. If you create an "Allow-all" rule without deleting the default
"Deny-all" rule, then traffic is still denied if the two have the same priority.
If you create an
allow rule with a higher priority than the "Deny-all"
rule, then that traffic is allowed.
default-allow-egress rule is deleted and no other rule is configured,
and implicit "Allow-all" still applies in the egress direction.
GCP firewall use cases
Egress firewall rules control outgoing connections originated inside
your GCP network. Egress
allow rules allow outbound connections that match
specific protocol, ports, and IP addresses. Egress
deny rules prevent
instances from initiating connections that match
non-permitted port, protocol, and IP range combinations.
For egress firewall rules, destinations to which a rule applies may be specified using IP CIDR ranges.
You can use destination ranges to protect from undesired connections initiated by a VM instance towards an external destination (e.g., certain IP addresses in the Internet) or towards specific GCP CIDR ranges (e.g., towards a specific subnet).
Egress connections from a VM instance to an internal or external address
This diagrams illustrate a VM connecting to an external address and a VM connecting to another VM in the same network.
Egress connections from a VM instance can be controlled as follows.
Conditions: Matching outbound connection are constructed using:
- Destination CIDR ranges
allow: permit the matching egress connection
deny: block the matching egress connection
Ingress firewall rules protect against incoming connections to the instance
from any source. Ingress
allow rules allow specific protocol, ports and
IP addresses to connect in. The firewall prevents instances from receiving
connections on non-permitted ports or protocols. Rules can be restricted
to only affect particular sources by either of the following:
- Source CIDR ranges
- Source Tags on VM instances (resolve to instance primary internal IP address)
Source CIDR ranges can be used to protect from undesired connections coming to an instance either from external networks or from GCP IP CIDR ranges. In addition, Source Tags can be used to protect from undesired connections coming from specific VM instances that are tagged with a matching tag.
Secure ingress connections
This diagrams illustrate a VM receiving a connection from an external address and another VM receiving a connection from a VM in the same network.
Conditions: Matching inbound connections are constructed using:
- Source CIDR ranges
- SourceTags on instances (Only for VM-VM connections. Tag resolves to VM primary IP)
allow: permit the matching ingress connection
deny: block the matching ingress connection
- 130000 per instance for instances with shared-core machine types
- 130000 per CPU for instances with 1 to 8 CPUs
- 130000*8 (1040000) per instance for instances with >8 CPUs