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

VPC firewall rules let you allow or deny connections to orfromvirtual machine (VM) instances in yourVPC network. Enabled VPC firewall rulesare always enforced, protecting your instances regardless of their configurationand operating system, even if they have not started up.

Every VPC network functions as a distributed firewall. Whilefirewall rules are defined at the network level, connections are allowed ordenied on a per-instance basis. You can think of the VPCfirewall rules as existing not only between your instances and other networks,but also between individual instances within the same network.

Note: This page is an overview of firewall rules. If you're looking for informationabout how to create and work with firewall rules, seeUse VPC firewall rules.

For more information about firewalls, seeFirewall (computing).

Best practices for firewall rules

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

• Implementleast-privilegeprinciples. Block all traffic by default and only allow the specific trafficyou need. This includes limiting the rule to just the protocols and ports youneed.
• Usehierarchical firewall policy rules to blocktraffic that should never be allowed at an organization or folder level.
• For "allow" rules, restrict them to specific VMs by specifying theservice account of the VMs.
• If you need to create rules based on IP addresses, try to minimize the numberof rules. It's easier to track one rule that allows traffic to a range of 16VMs than it is to track 16 separate rules.
• Usefirewall policies to groupfirewall rules for simplified configuration and deployment.Firewall policy rules provideseveral rule components that provide granular traffic control:
  • Useaddress groups to simplify using multiple IP address ranges in firewall rules.
  • UseFQDN objects in firewall policy to filter incoming or outgoing traffic from or tospecific domains. You might incurCloud Next Generation Firewall Standard data processing charges.
  • Usegeolocation objects in firewall policies when you need to filter external IPv4 and IPv6 trafficbased on specific geographic locations or regions. You might incurCloud Next Generation Firewall Standard processing charges.
• Turn onFirewall Rules Logging anduseFirewall Insightsto verify that firewall rules are being used in the intended way.Firewall Rules Logging can incurcosts, so you might want to consider usingit selectively.

Firewall rules in Google Cloud

When you create a VPC firewall rule, you specify aVPC network and a set of components that define what the ruledoes. The components enable you to target certain types of traffic, based onthe traffic's protocol, destination ports, sources, and destinations. For moreinformation, seefirewall rule components.

You create or modify VPC firewall rules by using theGoogle Cloud console, theGoogle Cloud CLI,and theREST API. When you create or modifya firewall rule, you can specify the instances to which it is intended to applyby using thetarget parameter of the rule. For firewall ruleexamples, seeOther configuration examples.

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

• Google Cloud blocks or limits certain traffic. For more information, seeBlocked and limited traffic.

• Google Cloud always allows communication between a VM instance and itscorresponding metadata server at169.254.169.254. For more information,seealways allowed traffic.

• Every network has twoimplied firewall rules thatpermit outgoing connections and block incoming connections. Firewall rulesthat you create can override these implied rules.

• The default network ispre-populated with firewall rulesthat 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, seedirection of connection.

• Firewall rules support IPv4 connections. IPv6 connections are also supportedin VPC networks that haveIPv6 enabled. When specifying a source ordestination for an ingress or egress rule by address, you canspecify 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 eitherallow ordeny.The rule applies to connections as long as it isenforced. Forexample, 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 isassociated with a VPC network. This means that you cannot sharefirewall rules among VPC networks, including networks connectedbyVPC Network Peering or by usingCloud VPN tunnels.

• VPC firewall rules arestateful:

  • When a connection is allowed through the firewall in either direction,return traffic matching this connection is also allowed. You cannotconfigure 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 outboundpackets by using a connection tracking table. IPv4 connectionssupport TCP, UDP, SCTP, and ICMP protocols. IPv6 connectionssupport TCP, UDP, SCTP, and ICMPv6 protocols.
  • Google Cloud implements connection tracking regardless of whetherthe protocol supports connections. If a connection is allowed between asource and a target (for an ingress rule) or between a target and adestination (for an egress rule), all response traffic is allowed as longas the firewall's connection tracking state is active. A firewall rule'stracking state is considered active if at least one packet is sent every10 minutes.
  • When a fragmented connection is allowed through the firewall,Google Cloud uses connection tracking to allow only the firstfragment of return traffic. To allow subsequent return fragments, youmust add a firewall rule.
  • ICMP response traffic, such as "ICMP TYPE 3, DESTINATION UNREACHABLE",generated in response to an allowed TCP/UDP connection is allowedthrough the firewall. This behavior is consistent withRFC792.

• VPC firewall rules do not reassemble fragmented TCP packets.Therefore, a firewall rule applicable to the TCP protocol can only applyto the first fragment because it contains the TCP header. Firewall rulesapplicable to the TCP protocol do not apply to the subsequent TCP fragments.

• The maximum number of tracked connections in the firewall rule table dependson the number of stateful connections supported by the machine type of theinstance. If the maximum number of tracked connections is exceeded, trackingis stopped for the connections that have the longest idle interval to let newconnections 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 rules

Every VPC network has two implied IPv4 firewall rules. If IPv6 isenabled in a VPC network, the network also has two implied IPv6firewall rules. These rules are not shown in the Google Cloud console.

Implied IPv4 firewall rules are present in all VPC networks,regardless of how the networks are created, and whether they areauto mode orcustom mode VPC networks. The default networkhas the same implied rules.

• Implied IPv4 allow egress rule. An egress rule whose action isallow,destination is0.0.0.0/0, and priority is the lowest possible (65535) letsany instance send traffic to any destination, except for trafficblocked by Google Cloud. A higher priority firewallrule may restrict outbound access. Internet access is allowed ifno other firewall rules deny outbound traffic and if the instance has anexternal IP address or uses a Cloud NAT instance. For more information, seeInternet access requirements.

  For information about routing requirements, seeInternet accessrequirements.

• Implied IPv4 deny ingress rule. An ingress rule whose action isdeny,source is0.0.0.0/0, and priority is the lowest possible (65535) protectsall instances by blocking incoming connections to them. A higher priority rulemight allow incoming access. The default network includes someadditional rules that override this one, allowingcertain types of incoming connections.

If IPv6 is enabled, the VPC network also has these two impliedrules:

• Implied IPv6 allow egress rule. An egress rule whose action isallow,destination is::/0, and priority is the lowest possible (65535) letsany instance send traffic to any destination, except for trafficblocked by Google Cloud. A higher priority firewallrule might restrict outbound access. For information about routingrequirements, seeInternet accessrequirements.

• Implied IPv6 deny ingress rule. An ingress rule whose action isdeny,source is::/0, and priority is the lowest possible (65535) protectsall instances by blocking incoming connections to them. A higher priority rulemight allow incoming access.

The implied rulescannot be removed, but they have the lowest possiblepriorities. You can create rules that override them as long as your rules havehigher priorities (priority numbersless than65535). Becausedeny rulestake precedence overallow rules of the same priority, an ingressallow rulewith a priority of65535 never takes effect.

Pre-populated rules in the default network

The default network is pre-populated with firewall rules that allow incomingconnections 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 asssh,scp, orsftp.
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 asping.

You can create similar firewall rules for networks other than the defaultnetwork. SeeConfigure firewall rules for common use cases for more information.

Blocked and limited traffic

Separate from VPC firewall rules and hierarchical firewallpolicies, Google Cloud blocks or limits certain traffic as described inthe 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'smachine type defines its maximum possible egress rate; however, you can only achieve that maximum possible egress rate in specific situations. For details, seeNetwork 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 sourcesexcept for DHCP packets coming fromthe 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, andexternal passthrough Network Load Balancers only processthe protocols andports configured on the forwarding rule. Cloud VPN gateways only acceptVPN 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 aGoogle Cloud sales specialist. This block does not apply to egress packets sent to TCP destination port 25 of aninternal 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. Theimplied 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. Thesystem-generated default routes meet this requirement. The instance sending packets to the external IP address must meet theinternet 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 andhierarchical firewallpolicies do not apply to the following:

• Packetssent to and received from the Google Cloud metadataserver

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

  • The primary internal IPv4 address of the NIC
  • Any internal IPv4 address from analias IP range ofthe NIC
  • If IPv6 is configured on the subnet, any of the IPv6 addresses assigned tothe NIC
  • An internal or external IPv4 address associated with a forwarding rule,for load balancing or protocol forwarding, if the instance is a backendfor the load balancer or is a target instance for protocol forwarding
  • Loopback addresses
  • Addresses configured as part of networking overlay software you run withinthe instance itself

Google Cloud metadata server

Google Cloud runs a local metadata server alongside each instance. Theserver is accessible at169.254.169.254 (for IPv4) andfd20:ce::254 (forIPv6). This server is essential to the operation of the instance, so theinstance can access it regardless of any firewall rules that you configure. Themetadata server provides the following basic services to the instance:

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

Product interactions

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

Firewall rules and passthrough load balancers

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

• Firewall rules in the external passthrough Network Load Balancerdocumentation
• Firewall rules in the internal passthrough Network Load Balancerdocumentation

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, VPCfirewall rules and hierarchical firewall policies donot control whichprotocols and ports are accepted by the proxy load balancer's forwarding rule IPaddress. The forwarding rule alone determines which protocols and ports areaccepted by the proxy load balancer.

VPC firewall rules and hierarchical firewall policies docontrol how these proxy load balancers communicate to their backends. Fordetails, see:

• Firewall rules in the external Application Load Balancerdocumentation
• Firewall rules in the internal Application Load Balancerdocumentation
• Firewall rules in the internal proxy Network Load Balancerdocumentation
• Firewall rules in the external proxy Network Load Balancerdocumentation

Firewall rules and Cloud VPN

Firewall rules and hierarchical firewall policies donot control whichprotocols and ports are accepted by the Cloud VPN gateway.

Cloud VPN gateways only accept packets for the protocols and ports describedin theCloud VPNspecifications.

Firewall rules and GKE

Google Kubernetes Engine creates and manages firewall rules automatically when you createa cluster or resources in the cluster (including Services and Ingresses). Formore information, seeAutomatically created firewallrules in the Google Kubernetes Enginedocumentation.

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, seeAI Hypercomputer overview.

Firewall rule components

Each firewall rule consists of the following configuration components:

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

• A numericalpriority, whichdetermines whether the rule is applied. Only the highest priority (lowestpriority number) rule whose other components match traffic is applied;conflicting rules with lower priorities are ignored.

• Anaction on match, eitherallow ordeny, whichdetermines whether the rule permits or blocks connections.

• Theenforcement status of the firewall rule: You can enableand disable firewall rules without deleting them.

• Atarget, which defines the instances (includingGKE clusters and App Engine flexible environment instances)to which the rule applies.

• Asource or destination filter forpacket characteristics.

• Theprotocol (such as TCP, UDP, or ICMP) anddestination port.

• A booleanlogs option which logsconnections that match the rule into Cloud Logging.

Components summary

Ingress (inbound) rule
Priority	Action	Enforcement	Target parameter	Source and destination filters	Protocols and ports
Integer from0 to65535, inclusive; default1000	allow ordeny	enabled (default) ordisabled	Specifies the instances thatreceive packets.	Sources for ingress rules Destinations for ingress rules	Specify a protocol or a protocol and a destination port. If not set, the rule applies to all protocols and destination ports. For more information, seeProtocols and ports.
Egress (outbound) rule
Priority	Action	Enforcement	Target parameter	Source and destination filters	Protocols and ports
Integer from0 to65535, inclusive; default1000	allow ordeny	enabled (default) ordisabled	Specifies the instances thatsend packets.	Sources for egress rules Destinations for egress rules	Specify a protocol or a protocol and a destination port. If not set, the rule applies to all protocols and destination ports. For more information, seeProtocols and ports.

Direction of traffic

You can create firewall rules that apply to ingress or egress traffic. A singlerule cannot apply to both ingress and egress traffic. However, you can createmultiple rules to define the ingress and egress traffic that you allow ordeny through the firewall.

• Ingress (inbound) describes packetsentering a network interface of atarget.

• Egress (outbound) describes packetsleaving a network interface of atarget.

• If you don't specify a direction, Google Cloud uses ingress.

Priority

The firewall rule priority is an integer from0 to65535, inclusive.Lowerintegers indicate higher priorities. If you do not specify a priority whencreating a rule, it is assigned a priority of1000.

The relative priority of a firewall rule determines whether it is applicable whenevaluated against others. The evaluation logic works as follows:

• The highest priority rule applicable to a target for a given type of traffictakes precedence. Target specificity does not matter. For example, a higherpriority ingress rule for certain destination ports and protocols intendedfor all targets overrides a similarly defined rule with lower priority for thesame destination ports and protocols intended for specific targets.

• The highest priority rule applicable for a given protocol and destinationport definition takes precedence, even when the protocol and destinationport definition is more general. For example, a higher priority ingress ruleallowing traffic for all protocols and destination ports intended for giventargets overrides a lower priority ingress rule denying TCP 22 for the sametargets.

• A rule with adeny action overrides another with anallow actiononly ifthe two rules have the same priority. Using relative priorities, it ispossible to buildallow rules that overridedeny rules, anddeny rulesthat overrideallow rules.

• 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 enableFirewall Rules Logging. If you wantyour 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 sources0.0.0.0/0 (any IPv4 address) applicable to all targets,all protocols, and all destination ports, having adeny action and apriority of1000.

• An ingress rule from sources0.0.0.0/0 (any IPv4 address) applicable to specifictargets with the network tagwebserver, for traffic on TCP 80, with anallowaction.

The priority of the second rule determines whether TCP traffic to port 80 isallowed for thewebserver targets:

• If the priority of the second rule is set to a numbergreater than1000,it has alower priority, so the first rule denying all traffic applies.

• If the priority of the second rule is set to1000, the two rules haveidentical priorities, so the first rule denying all traffic applies.

• If the priority of the second rule is set to a numberless than1000,it has ahigher priority, thus allowing traffic on TCP 80 for thewebserver targets. Absent other rules, the first rule would still deny othertypes of traffic to thewebserver targets, and it would also deny alltraffic, including TCP 80, to instanceswithout thewebserver network tag.

The previous example demonstrates how you can use priorities to create selectiveallow rules and globaldeny rules to implement a security best practice ofleast privilege.

Note: Every network has two non-removable, low-priority, implied firewall rules,and the default network comes with additional removable firewall rules. For moreinformation, seedefault and implied rules.

Action on match

The action component of a firewall rule determines whether it permits or blockstraffic, subject to the other components of the rule:

• Anallow action permits connections that match the other specifiedcomponents.

• Adeny action blocks connections that match the other specified components.

Note: A firewall rule can only have one action component. Bothallow anddenycannot be specified in the same rule. To define the order in which therules should be applied, create separate firewall rules with differentpriorities.

Enforcement

You can choose whether a firewall rule isenforced by setting its statetoenabled ordisabled. You set the enforcement state when youcreate a rule or when youupdate a rule.

If you don't set an enforcement state when you create a new firewall rule, thefirewall rule is automaticallyenabled.

Use cases

Disabling and enabling are useful for troubleshooting and performingmaintenance. Consider changing the enforcement of a firewall rule in the following situations:

• For troubleshooting: In conjunction withFirewall RulesLogging, you can temporarily disable afirewall rule to determine if the rule is responsible for blocking or allowingtraffic. This is useful for situations where multiple firewall rules apply tothe same traffic. Disabling and enabling rules is more useful than deletingand re-creating rules because none of the other components of the rule arelost.

• For maintenance: Disabling firewall rules can simplify periodic maintenance.For example, you might choose to enable an ingress firewall rule that allowsSSH access only at times when you need to perform maintenance using SSH. Whenyou're not performing maintenance, you can disable the rule.

Effects on existing traffic

When you change a firewall rule's enforcement state, create a newenforcedrule, or modify firewall rules to deny traffic that was previously allowed,Cloud NGFW enforces this change only on new connections. Existingconnections persist, and their associated traffic remains unaffected.

Protocols and ports

You can narrow the scope of a firewall rule by specifying protocols orprotocols and destination ports. You can specify a protocol or a combination ofprotocols and their destination ports. If you omit both protocols and ports, thefirewall rule is applicable for all traffic on any protocol and any destinationport. Rules based on source ports are not supported.

Not all protocols support ports. For example, ports exist for TCP and UDP, butnot for ICMP. ICMP does have differentICMP types, but they are not portsand cannot be specified in a firewall rule.

You can use the following protocol names in firewall rules:tcp,udp,icmp(for IPv4 ICMP),esp,ah,sctp, andipip. For all other protocols, you mustuse theIANA protocol numbers.

Many protocols use the same name and number in both IPv4 and IPv6, but someprotocols, such as ICMP, do not.

The IPv6 Hop-by-Hop protocol is not supported in firewall rules.

The following table summarizes valid protocol and destination port specificationcombinations for Google Cloud firewall rules.

Specification	Example	Explanation
No protocol and port	—	If you do not specify a protocol, the firewall rule applies to all protocols and their applicable destination ports.
Protocol	tcp	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	tcp:80	If you specify a protocol and a single destination port, the firewall rule applies to that destination port of the protocol.
Protocol and port range	tcp:20-22	If you specify a protocol and a port range, the firewall rule applies to that destination port range for the protocol.
Combinations	icmp,tcp:80 tcp:443 udp:67-69	You can specify various combinations of protocols and destination ports to which the firewall rule applies. For more information, seeCreate firewall rules.

Important: A port cannot be specified by itself. If you only specify a number,Google Cloud interprets that as a decimal IPprotocol. For example,if you specify80 by itself, Google Cloud interprets that as IP protocol80 (ISO-IP), which is not the same as TCPport 80 (tcp:80).

Target, source, destination

Targets identify the network interfaces of instances to which the firewall ruleapplies.

You can specify both source and destination parameters that apply to the packetsources or destinations for both ingress and egress firewall rules. Thedirection of the firewall rule determines the possiblevalues for the source and destination parameters.

Target parameter

Thetarget parameter identifies the network interfaces of theCompute Engine instances, including GKE nodes andApp Engine flexible environment instances.

You can define the following targets for both ingress or egress rules. Thetarget, source, and destination parameters work together as described inSource, destination, target.

• Default target—all instances in the VPC network. Whenyou omit a target specification, the firewall ruleapplies to all instances in the VPC network.

• Instances by target network tags. The firewall rule only applies toinstances with network interfaces in the firewall rule's VPCnetwork if the instances have anetworktag that matches at least one of thefirewall rule's target network tags. For the maximum number of target networktags that you can specify per firewall rule, seeper firewall rulelimits.

• Instances by target service accounts. The firewall rule only applies toinstances with network interfaces in the firewall rule's VPCnetwork if the instances use aservice account thatmatches at least one of the firewall rule's target service accounts. For themaximum number of target service accounts that you can specify per firewallrule, seeper firewall rule limits.

For information about the benefits and limitations of target network tags andtarget service accounts, seefiltering by service account versus networktag.

Targets and IP addresses for ingress rules

The packets routed to the network interface of a target VM are processed basedon the following conditions:

• If the ingress firewall ruleincludes a destination IP address range,the packet's destination must fit within one of the explicitly defineddestination IP address ranges.

• If the ingress firewall ruledoes not include a destination IP address range,the packet's destination must match one of the following IP addresses:

  • The primary internal IPv4 address assigned to the instance's NIC.

  • Any configuredalias IP ranges on theinstance's NIC.

  • The external IPv4 address that's associated with the instance's NIC.

  • If IPv6 is configured on the subnet, any of the IPv6 addresses assigned tothe NIC.

  • An internal or external IP address associated with a forwarding rule usedfor pass-through load balancing, where the instance is a backend for aninternal passthrough Network Load Balancer or an external passthrough Network Load Balancer.

  • An internal or external IP address associated with a forwarding rule usedfor protocol forwarding, where the instance is referenced by a targetinstance.

  • An IP address within the destination range of a custom static route that uses the instance as a next hop VM (next-hop-instance ornext-hop-address).

  • An IP address within the destination range of a custom static route usingan internal passthrough Network Load Balancer (next-hop-ilb) next hop, if the VM is a backend forthat load balancer.

Targets and IP addresses for egress rules

The processing of packets emitted from the network interface of a target depends on theIP forwarding configurationon the target VM. IP forwarding is disabled by default.

• When the target VM has IP forwarding disabled, the VM can emit packets with thefollowing sources:

  • The primary internal IPv4 address of an instance's NIC.

  • Any configured alias IP range on an instance's NIC.

  • If IPv6 is configured on the subnet, any of the IPv6 addresses assigned tothe NIC.

  • An internal or external IP address associated with a forwarding rule, forpass-through load balancing or protocol forwarding, if the instance is abackend for an internal passthrough Network Load Balancer, an external passthrough Network Load Balancer, or is referenced bya target instance.

  If the egress firewall ruleincludes source IP address ranges, the targetVMs are still limited to the source IP addresses mentioned previously, but thesource parameter can be used to refine that set. Use of a source parameterwithout enabling IP forwardingdoes not expand the set of possible packetsource addresses.

  If the egress firewall ruledoes not include a source IP address range, allthe source IP addresses mentioned previously are permitted.

• When the target VM has IP forwarding enabled, the VM can emit packets witharbitrary source addresses. You can use the source parameter to moreprecisely define the set of allowed packet sources.

Source parameter

Source parameter values depend on the direction of the firewall rule.

Sources for ingress rules

You can use the following sources for ingress firewall rules:

• Default source range: When you omit a source specification in an ingress rule,Google Cloud uses the default source IPv4 address range0.0.0.0/0 (any IPv4 address). The default value does not include IPv6sources.

• Source IPv4 ranges: A list of IPv4 addresses in CIDR format.

• Source IPv6 ranges: A list of IPv6 addresses in CIDR format.

• Source network tags: One or morenetworktags that identify network interfaces ofVM instances in the same VPC network as the firewall rule. Forthe maximum number of source network tags per firewall rule, seeper firewallrule limits. For details abouthow packet source addresses are matched when using this implicit sourcespecification, seeHow source network tags and source service accounts implypacket sources.

• Source service accounts: One or moreservice accountsthat identify network interfaces of VM instances in the sameVPC network as the firewall rule. For the maximum number ofsource service accounts per firewall rule, seeper firewall rulelimits. For details about how packetsource addresses are matched when using this implicit source specification,seeHow source network tags and source service accounts imply packetsources.

• A valid source combination: For all of the following combinations, theeffective source set is theunion of the IPv4 or IPv6 addresses that areexplicitly specified and the IP address ranges that are implied by sourcenetwork tag or source service account:

  • A combination ofsource IPv4 ranges andsource network tags.
  • A combination ofsource IPv6 ranges andsource network tags.
  • A combination ofsource IPv4 ranges andsource service accounts.
  • A combination ofsource IPv6 ranges andsource service accounts.

Important: Network tags and service accounts cannot be used in the same firewallrule. For more information, seefiltering by service account versus networktag.

How source network tags and source service accounts imply packet sources

When an ingress firewall rule uses a source network tag, the packets must beemitted from a network interface that meets the following criteria:

• The network interface must be in the VPC network where thefirewall rule is defined, and
• The network interface must be associated with a VM that has a network tag thatmatches at least one of the firewall rule's source network tags.

When an ingress firewall rule uses a source service account, the packets mustbe emitted from a network interface that meets the following criteria:

• The network interface must be in the VPC network where thefirewall rule is defined, and
• The network interface must be associated with a VM that has a service accountthat matches one of the firewall rule's source service accounts.

In addition to specifying a network interface, when an ingress firewall rule useseither a source network tag or a source service account, packets emitted from the networkinterface of the VM must use one of the following valid source IP addresses:

• The primary internal IPv4 address of that network interface.
• Any IPv6 addresses assigned to that network interface.

If an ingress firewall rule also containsdestination IP address ranges,the network interface bound to a network tag is resolved to the same IPversion as the destination IP range.

No other packet source IP addresses are implied when using source network tags orsource service accounts. For example, alias IP ranges and external IPv4address associated with the network interface are excluded. If you need tocreate ingress firewall rules whose sources include alias IP address rangesor external IPv4 addresses, use source IPv4 ranges.

Sources for egress rules

You can use the following sources for egress firewall rules:

• Default—implied by target. If you omit the source parameter from anegress rule, packet sources are defined implicitly as described inTargetsand IP addresses for egress rules.

• Source IPv4 ranges. A list of IPv4 addresses in CIDR format.

• Source IPv6 ranges. A list of IPv6 addresses in CIDR format.

Follow these guidelines to add source IP address ranges for egress rules:

• If a VM interface has both internal and external IPv4 addresses assigned,only the internal IPv4 address is used during rule evaluation.

• If you specify both source and destination parameters in an egress rule,use the same IP version for both parameters. You can use either anIPv4 address range or an IPv6 address range, but not both. For details, seeDestinations for egress rules.

Destination parameter

Destinations can be specified by using IP address ranges, which are supported byboth ingress and egress rules. The default destination behavior depends on thedirection of the rule.

Destinations for ingress rules

You can use the following destinations for ingress firewall rules:

• Default—implied by target. If you omit the destination parameter froman ingress rule, packet destinations are defined implicitly as described inTargets and IP addresses for ingress rules.

• Destination IPv4 ranges. A list of IPv4 addresses in CIDR format.

• Destination IPv6 ranges. A list of IPv6 addresses in CIDR format.

Follow these guidelines to add destination IP address ranges for ingress rules:

• If a VM interface has both internal and external IPv4 addresses assigned,only the internal IPv4 address is used during rule evaluation.

• If you specify both source and destination parameters in an ingress rule,then the source parameters are resolved into the same IP version asthe destination IP address range. To learn more abouthow to define sources for ingress rules, seeSources for ingress rules.

Destinations for egress rules

You can use the following destinations for egress firewall rules:

• Default destination range. When you omit a destination specification in anegress rule, Google Cloud uses the default destination IPv4 address range0.0.0.0/0 (any IPv4 address). The default value does not include IPv6destinations.

• Destination IPv4 ranges. A list of IPv4 addresses in CIDR format.

• Destination IPv6 ranges. A list of IPv6 addresses in CIDR format.

Source and target filtering by service account

You can useservice accounts to create firewallrules that are more specific in nature:

• For both ingress and egress rules, you can use service accounts to specifytargets.

• For ingress rules, you can specify the source for incoming packets as theprimary internal IP address of any VM in the network where the VM uses aparticular service account.

The service account must becreated in the same projectas the firewall rulebefore you create a firewall rule that relies on it.While the system does not stop you from creating a rule that uses a serviceaccount from a different project, the rule is not enforced if the serviceaccount doesn't exist in the firewall rule's project.

Note: You cannot useWorkload Identity Federation for GKEservice accounts in the VPC firewall rules for source and target filtering.

Firewall rules that use service accounts to identify instances apply to bothnew instances created and associated with the serviceaccountand existing instances if youchange their serviceaccounts.Changing the service account associated with an instance requires that youstop and restart it. You can associate service accounts with individualinstances and with instance templates used bymanaged instancegroups.

Note: In projects with a standalone VPC (a VPCthat does not participate in Shared VPC), you can only use serviceaccounts from that project as firewall rule criteria. In projects usingShared VPC, you can use service accounts from the hostproject or any service project as firewall rule criteria. If you create afirewall rule that uses service accounts that do not match these two scenarios,the firewall rule will not be enforced.

Filter by service account versus network tag

This section highlights key points to consider when deciding if you should useservice accounts or network tags to define targets and sources (for ingressrules).

If you need strict control over how firewall rules are applied to VMs, usetarget service accounts and source service accounts instead of target network tags andsource network tags:

• A network tag is an arbitrary attribute. One or morenetwork tags can beassociated with an instance by anyIdentity and Access Management (IAM) principal who has permission to edit it.IAM principals with theCompute Engine InstanceAdmin role to a projecthave this permission. IAM principals who can edit an instance can change itsnetwork tags, which could change the set of applicable firewall rules for thatinstance.

• A service account represents an identity associated with an instance. Onlyone service account can be associated with an instance. You control access tothe service account by controlling the grant of theService Account User role for otherIAM principals. For an IAM principal to start an instanceby using a service account, that principal must have the Service Account User roleto at least use that service account and appropriate permissions to createinstances (for example, having the Compute Engine Instance Admin role tothe project).

You cannot mix and match service accounts and network tags in any firewall rule:

• You cannot use target service accounts and target network tags together in anyfirewall rule (ingress or egress).

• If you specify targets by target network tag or target service account, the followingare invalid sources for ingress firewall rules.

  Targets	Invalid sources
  Target network tags	Source service accounts Combination of source IP ranges and source service accounts
  Target service account	Source network tags Combination of source IP ranges and source network tags

Following are operational considerations for service accounts and network tags:

• Changing a service account for an instance requires stopping and restartingit. Adding or removing network tags can be done while the instance is running.

• There are a maximum number of target service accounts, source serviceaccounts, target network tags, and source network tags that can be specifiedfor firewall rules. For more information, seeper firewall rulelimits.

• If you identify instances by network tag, the firewall rule applies to theprimary internal IP address of the instance.

• Service account firewall rules apply to the GKE node, not theGKE Pod.

Roles and permissions

The following table describes the Identity and Access Management (IAM) permissions thatyou need for working with VPC firewall rules.

Task	Required permission	Sample role
Create a firewall rule	compute.firewalls.create	Compute Security Admin role (roles/compute.securityAdmin)
Delete a firewall rule	compute.firewalls.delete	Compute Security Admin (roles/compute.securityAdmin)
Make changes to firewall rules	compute.firewalls.update	Compute Security Admin role (roles/compute.securityAdmin)
View details about a firewall rule	compute.firewalls.get	Compute Network Viewer role (roles/compute.networkViewer)
View a list of firewall rules	compute.firewalls.list	Compute Network Viewer role (roles/compute.networkViewer)

Use cases

The following use cases demonstrate how firewall rules work. In these examples,all the firewall rules are enabled.

Ingress cases

Ingress firewall rules control incoming connections from a source to targetinstances in your VPC network. The source for an ingress rule canbe defined as one of the following:

• A range of IPv4 or IPv6 addresses; the default is any IPv4 address(0.0.0.0/0)
• Other instances in your VPC network identified by networktags
• Other instances in your VPC network identified by serviceaccount
• Other instances in your VPC network identified by range ofIPv4 or IPv6 addressand by network tag
• Other instances in your VPC network identified by range ofIPv4 or IPv6 addressesand by service account

The default source is any IPv4 address (0.0.0.0/0). If you want to controlincoming connections for sources outside your VPC network,including other sources on the internet, use a range of IP addresses in CIDR format.

Ingress rules with anallow action permit incoming traffic based on the othercomponents of the rule. In addition to specifyingthe source and target for the rule, you can limit the rule to apply to specificprotocols and destination ports. Similarly, ingress rules with adeny actioncan be used to protect instances by blocking incoming traffic based on thefirewall rule components.

Caution: You can also use target service accounts or target network tags to specify theingress destinations. If you do that, you limit how you can specify the sourcefor the rule. For more information, seefiltering by service account versus networktag.

Ingress examples

Figure 1 illustrates some examples where firewall rules can controlingress connections. The examples use thetargetparameter in rule assignments to apply rules to specific instances.

• An ingress rule with priority1000 is applicable toVM 1. This ruleallows incoming TCP traffic from any IPv4 source (0.0.0.0/0). TCP traffic fromother instances in the VPC network is allowed, subject toapplicable egress rules for those other instances.VM 4 is able tocommunicate withVM 1 over TCP becauseVM 4 has no egress rule blockingsuch communication (only the implied allow egress rule is applicable). BecauseVM 1 has an external IP, this rule also permits incoming TCP traffic fromexternal hosts on the internet and fromVM 2 via external IP addresses.

• VM 2 has no specified ingress firewall rule, so the implied deny ingressrule blocks all incoming traffic. Connections from other instances inthe network are blocked, regardless of egress rules for the other instances.BecauseVM 2 has an external IP, there is apath to it from externalhosts on the internet, but the implied deny ingress rule blocks externalincoming traffic as well.

• An ingress rule with priority1000 is applicable toVM 3. This ruleallows TCP traffic from instances in the network with the network tagclient, such asVM 4. TCP traffic fromVM 4 toVM 3 is allowedbecauseVM 4 has no egress rule blocking such communication (only theimplied allow egress rule is applicable). BecauseVM 3 does not have anexternal IP, there is no path to it from external hosts on the internet.

Egress cases

Egress firewall rules control outgoing connections from target instances in yourVPC network. Egress rules with anallow action permit trafficfrom instances based on the othercomponents of therule. For example, you can permit outbound trafficto specific destinations, such as a range of IPv4 addresses, on protocols anddestination ports that you specify. Similarly, egress rules with adenyaction block traffic based on the other components of the rule.

Every egress rule needs adestination. The default destination is any IPv4address (0.0.0.0/0), but you can create a more specific destination by using arange of IPv4 or IPv6 addresses in CIDR format. When specifying a range of IPaddresses, you can control traffic to instances in your network and todestinations outside your network, including destinations on the internet.

Egress examples

Figure 2 illustrates some examples where firewall rules can controlegress connections. The examples use thetargetparameter in rule assignments to apply rules to specific instances.

• VM 1 has no specified egress firewall rule, so the implied allow egressrule lets it send traffic to any destination. Connections to other instances inthe VPC network are allowed, subject to applicable ingress rulesfor those other instances.VM 1 is able to send traffic toVM 4 becauseVM 4 has an ingress rule allowing incoming traffic from any IP addressrange. BecauseVM 1 has an external IP address, it is able to send trafficto external hosts on the internet. Incoming responses to traffic sent byVM1 are allowed because firewall rules are stateful.

• An egress rule with priority1000 is applicable toVM 2. This ruledenies all outgoing traffic to all IPv4 destinations (0.0.0.0/0). Outgoing trafficto other instances in the VPC network is blocked, regardless ofthe ingress rules applied to the other instances. Even thoughVM 2 has anexternal IP address, this firewall rule blocks its outgoing traffic to externalhosts on the internet.

• An egress rule with priority1000 is applicable toVM 3. This ruleblocks its outgoing TCP traffic to any destination in the192.168.1.0/24 IPrange. Even though ingress rules forVM 4 permit all incoming traffic,VM3 cannot send TCP traffic toVM 4. However,VM 3 is free to send UDPtraffic toVM 4 because the egress rule only applies to the TCP protocol.

  Also,VM 3 can send any traffic to other instances in theVPC network outside the192.168.1.0/24 IP range, as long asthose other instances have ingress rules to permit such traffic. Because it doesnot have an external IP address, it has no path to send traffic outside the VPCnetwork.

What's next

• To create and work with firewall rules, seeUse VPC firewall rules.

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how Cloud NGFW performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Try Cloud NGFW free