VPC firewall rules

Virtual Private Cloud (VPC) firewall rules apply to a given project and network. If you want to apply firewall rules to multiple VPC networks in an organization, see Firewall policies and rules. The rest of this page covers VPC firewall rules only.

VPC firewall rules let you allow or deny connections to or from virtual machine (VM) instances in your VPC network. 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).

Best practices for firewall rules

When designing and evaluating your firewall rules, keep in mind the following best practices:

• Implement least-privilege principles. Block all traffic by default and only allow the specific traffic you need. This includes limiting the rule to just the protocols and ports you need.
• Use hierarchical firewall policy rules to block traffic that should never be allowed at an organization or folder level.
• For "allow" rules, restrict them to specific VMs by specifying the service account of the VMs.
• If you need to create rules based on IP addresses, try to minimize the number of rules. It's easier to track one rule that allows traffic to a range of 16 VMs than it is to track 16 separate rules.
• Use firewall policies to group firewall rules for simplified configuration and deployment. Firewall policy rules provide several rule components that provide granular traffic control:
  • Use address groups to simplify using multiple IP address ranges in firewall rules.
  • Use FQDN objects in firewall policy to filter incoming or outgoing traffic from or to specific domains. You might incur Cloud Next Generation Firewall Standard data processing charges.
  • Use geolocation objects in firewall policies when you need to filter external IPv4 and IPv6 traffic based on specific geographic locations or regions. You might incur Cloud Next Generation Firewall Standard processing charges.
• Turn on VPC firewall rules logging and use Firewall Insights to verify that firewall rules are being used in the intended way. VPC firewall rules logging can incur costs, so you might want to consider using it selectively.

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, destination ports, sources, and destinations. For more information, see firewall rule components.

You create or modify VPC firewall rules by using the Google Cloud console, the Google Cloud CLI, and the 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 parameter of the rule. For firewall rule examples, see Other configuration examples.

In addition to firewall rules that you create, Google Cloud has other rules that can affect incoming (ingress) or outgoing (egress) connections:

• Google Cloud blocks or limits certain traffic. For more information, see Blocked and limited 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.

• VPC firewall rules are evaluated along with rules in firewall policies according to the Firewall rule evaluation process. As a last step, Cloud NGFW enforces an implied action if no explicit action applied to the traffic.

• The default network is pre-populated with firewall rules that you can delete or modify.

Specifications

VPC firewall rules have the following characteristics:

• Each firewall rule applies to incoming (ingress) or outgoing (egress) connections, not both. For more information, see direction of connection.

• Firewall rules support IPv4 connections. IPv6 connections are also supported in VPC networks that have IPv6 enabled. When specifying a source or destination for an ingress or egress rule by address, you can specify IPv4 or IPv6 addresses or blocks in CIDR notation.

• Each firewall rule can contain either IPv4 or IPv6 ranges, but not both.

• Each firewall rule's action is either allow or deny. The rule applies to connections as long as it is enforced. For example, you can disable a rule for troubleshooting purposes.

• 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. IPv4 connections support TCP, UDP, SCTP, and ICMP protocols. IPv6 connections support TCP, UDP, SCTP, and ICMPv6 protocols.
  • 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.
  • When a fragmented connection is allowed through the firewall, Google Cloud uses connection tracking to allow only the first fragment of return traffic. To allow subsequent return fragments, you must add a firewall rule.
  • 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. If the maximum number of tracked connections is exceeded, tracking is stopped for the connections that have the longest idle interval to let new connections be tracked.

  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

Implied actions

If no VPC firewall rule applies to a target, the firewall rule evaluation process might reach the last step. At this step, Cloud NGFW uses an implied action. The implied action depends on the traffic direction and the target resource type.

For more information, see Firewall rule evaluation process.

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:

Rule name	Direction	Priority	Source ranges	Action	Protocols and ports	Description
default-allow-internal	ingress	65534	10.128.0.0/9	allow	tcp:0-65535 udp:0-65535 icmp	Permits incoming connections to VM instances from other instances within the same VPC network.
default-allow-ssh	ingress	65534	0.0.0.0/0	allow	tcp:22	Lets you connect to instances with tools such as ssh, scp, or sftp.
default-allow-rdp	ingress	65534	0.0.0.0/0	allow	tcp:3389	Lets you connect to instances using the Microsoft Remote Desktop Protocol (RDP).
default-allow-icmp	ingress	65534	0.0.0.0/0	allow	icmp	Lets you use tools such as ping.

You can create similar firewall rules for networks other than the default network. See Configure firewall rules for common use cases for more information.

Blocked and limited traffic

Separate from VPC firewall rules and hierarchical firewall policies, Google Cloud blocks or limits certain traffic as described in the following table.

Traffic type	Details
Packet rate and bandwidth Applies to: All egress packets All ingress packets	Google Cloud accounts for bandwidth per VM instance, for each network interface (NIC) or IP address. A VM's machine type defines its maximum possible egress rate; however, you can only achieve that maximum possible egress rate in specific situations. For details, see Network bandwidth in the Compute Engine documentation.
DHCP offers and acknowledgments Applies to: Ingress packets to UDP port 68 (DHCPv4) Ingress packets to UDP port 546 (DHCPv6)	Google Cloud blocks incoming DHCP offers and acknowledgments from all sources except for DHCP packets coming from the metadata server.
Protocols supported by Google Cloud external IP addresses Applies to: Ingress packets to external IP addresses	External IPv4 and IPv6 addresses only accept TCP, UDP, ICMP, IPIP, AH, ESP, SCTP, and GRE packets. Resources that use external IP addresses impose additional protocol restrictions: Forwarding rules for protocol forwarding, external Application Load Balancers, external proxy Network Load Balancers, and external passthrough Network Load Balancers only process the protocols and ports configured on the forwarding rule. Cloud VPN gateways only accept VPN protocols.
SMTP (port 25) traffic Applies to: Egress packets to external IP addresses on TCP port 25	To help prevent spam, by default Google Cloud blocks egress packets sent to TCP destination port 25 of an external IP address (including an external IP address of another Google Cloud resource). Google Cloud automatically removes this block once it determines a project is at low risk of sending large volumes of email over unencrypted connections. Google Cloud excludes SMTP traffic over TLS on port 465 or 587 from this block. To find out if your project permits this traffic, go to the VPC networks page or the Firewall policies page in the Google Cloud console. A banner message on both pages indicates whether your project permits this traffic. For more information, contact a Google Cloud sales specialist. This block does not apply to egress packets sent to TCP destination port 25 of an internal IP address, including a privately used public IP address in a VPC network or an on-premises network. If external SMTP egress on port 25 is allowed in your project, and you want to send this type of traffic, the following additional conditions must be met: Egress firewall rules in the VPC network and hierarchical firewall policies applicable to the VPC network must allow egress to the external IP address on TCP port 25. The implied allow egress rules meet this requirement because they allow egress to (and established inbound responses from) any IP address. The applicable route for the destination must use the default internet gateway next hop. The system-generated default routes meet this requirement. The instance sending packets to the external IP address must meet the internet access requirements. You can prevent external SMTP egress by creating egress deny VPC firewall rules or hierarchical firewall policies.

Always allowed traffic

For VM instances, VPC firewall rules and hierarchical firewall policies do not apply to the following:

• Packets sent to and received from the Google Cloud metadata server

• Packets sent to an IP address assigned to one of the instance's own network interfaces (NICs) where packets stay within the VM itself. IP addresses assigned to an instance's NIC include:

  • The primary internal IPv4 address of the NIC
  • Any internal IPv4 address from an alias IP range of the NIC
  • If IPv6 is configured on the subnet, any of the IPv6 addresses assigned to the NIC
  • An internal or external IPv4 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
  • Loopback addresses
  • Addresses configured as part of networking overlay software you run within the instance itself

Google Cloud metadata server

Google Cloud runs a local metadata server alongside each instance. The server is accessible at 169.254.169.254 (for IPv4) and fd20:ce::254 (for IPv6). 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:

• DHCP
• DNS resolution, following the DNS name resolution order for the VPC network.
• Instance metadata
• Network Time Protocol (NTP)

Product interactions

The following sections describe how firewall rules and hierarchical firewall policies interact with other Google Cloud products.

Firewall rules and passthrough load balancers

VPC firewall rules and hierarchical firewall policies do control which of the forwarding rule's supported protocols and ports are allowed to access the passthrough load balancer's backends. For details, see:

• Firewall rules in the regional external passthrough Network Load Balancer documentation
• Firewall rules in the internal passthrough Network Load Balancer documentation

Firewall rules and proxy load balancers

For external Application Load Balancers, internal Application Load Balancers, internal proxy Network Load Balancers, and external proxy Network Load Balancers, VPC firewall rules and hierarchical firewall policies do not control which protocols and ports are accepted by the proxy load balancer's forwarding rule IP address. The forwarding rule alone determines which protocols and ports are accepted by the proxy load balancer.

VPC firewall rules and hierarchical firewall policies do control how these proxy load balancers communicate to their backends. For details, see:

• Firewall rules in the external Application Load Balancer documentation
• Firewall rules in the internal Application Load Balancer documentation
• Firewall rules in the internal proxy Network Load Balancer documentation
• Firewall rules in the external proxy Network Load Balancer documentation

Firewall rules and Cloud VPN

Firewall rules and hierarchical firewall policies do not control which protocols and ports are accepted by the Cloud VPN gateway.

Cloud VPN gateways only accept packets for the protocols and ports described in the Cloud VPN specifications.

Firewall rules and GKE

Google Kubernetes Engine creates and manages firewall rules automatically when you create a cluster or resources in the cluster (including Services and Ingresses). For more information, see Automatically created firewall rules in the Google Kubernetes Engine documentation.

Firewall rules and AI Hypercomputer

You can create VPC firewall rules when you create the VPC networks required for creating VMs in AI Hypercomputer. Use the firewall rules to specify the protocols and ports that are allowed for your VPC networks. For more information, see AI Hypercomputer overview.

Firewall rule components

Each firewall rule consists of the following configuration components:

• A direction from the perspective of the target. Direction can be either ingress or egress.

• 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 allow or 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