Firewall Rules Overview

Google Cloud Platform (GCP) firewall rules 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.

Configuration of GCP firewalls is supported via the Google Cloud Platform Console, gcloud command line tool, and REST API.

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.

  • allow rules allow connections matching the specified conditions to arrive or leave instances, depending on the direction of the rule.
  • deny rules deny connections matching the specified conditions from arriving at or leaving instances, depending on the direction of the rule.

You cannot specify both allow and deny in the same firewall rule. However, you can specify multiple overlapping or conflicting allow and 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 deny 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 ingress connections.

  • 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 only to specific protocols or specific combinations of protocols and ports. 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.

The protocol can be specified as one of the following well known protocol strings (tcp, udp, icmp, esp, ah, sctp) or as the IP protocol number. If no protocols are specified, the rule applies to all 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 the global 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 0 through 65535, both inclusive. When unspecified, a priority value of 1000 is given. A lower priority "number" indicates higher priority, so a rule with a priority of 1 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.

Specifications

  • 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
Ingress

Optional
(default: 1000)
Mandatory Optional
(Default: All ports)
Optional
Src IP CIDR OR
SourceTags
(Default: 0.0.0.0/0)
NOT ALLOWED Mandatory Optional
(Default:
no target tag)
Mandatory
ALLOW
OR
DENY
Egress

Optional
(default: 1000)
Mandatory Optional
(Default: All ports)
NOT ALLOWED Optional
Dst IP CIDR
(Default: 0.0.0.0/0)
Mandatory Optional
(Default:
no target tag)
Mandatory
ALLOW
OR
DENY

Supported parameter combinations are as follows:

  • ingress and egress cannot be specified simultaneously in a single rule.
  • The ingress direction and destination combination are not supported in a single rule.
  • egress direction and source combination are not supported in a single rule.
  • allow and deny cannot 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.

  • [NETWORK-NAME]-allow-egress
    Allows all egress connections. Rule has a priority of 65535.
  • [NETWORK-NAME]-deny-ingress
    Deny all ingress connection. Rule has a priority of 65535

[NETWORK-NAME] is the name of the network containing the rule. In the default network, the names would be default-allow-egress and default-deny-ingress.

In addition, a project's default network is created with the following default firewall rules.

  • default-allow-internal
    Allows ingress network connections of any protocol and port between instances on the network. Rule has a priority of 65534.
  • default-allow-ssh
    Allows ingress TCP connections from any source to any instance on the network over port 22. Rule has a priority of 65534.
  • default-allow-icmp
    Allows ingress ICMP traffic from any source to any instance on the network. Rule has a priority of 65534.
  • default-allow-rdp
    Allows ingress remote desktop protocol traffic to TCP port 3389. Rule has a priority of 65534.

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.

If the 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 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 from VM instance (click to enlarge)
Egress from VM instance (click to enlarge)

Egress connections from a VM instance can be controlled as follows.

Conditions: Matching outbound connection are constructed using:

  • Destination CIDR ranges
  • Protocols
  • Ports

Action:

  • allow: permit the matching egress connection
  • deny: block the matching egress connection

Ingress cases

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.

Ingress from external address to VM instance (click to enlarge)
Ingress to VM instance (click to enlarge)

Conditions: Matching inbound connections are constructed using:

  • Source CIDR ranges
  • Protocols
  • Ports
  • SourceTags on instances (Only for VM-VM connections. Tag resolves to VM primary IP)

Action:

  • allow: permit the matching ingress connection
  • deny: block the matching ingress connection

Connection limits

GCP uses a connection tracking table to support stateful firewall filtering. The maximum number of connections in the table depends on the instance type. Current maximum connections are as follows:

  • 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

What's next

Send feedback about...

Compute Engine Documentation