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](https://docs.cloud.google.com/firewall/docs/firewall-policies-overview.md.txt). 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](https://docs.cloud.google.com/vpc/docs/vpc.md.txt#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. > [!NOTE] > **Note:** This page is an overview of firewall rules. If you're looking for information about how to create and work with firewall rules, see [Use VPC firewall rules](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt). For more information about firewalls, see [Firewall (computing)](https://wikipedia.org/wiki/Firewall_(computing)). ## Best practices for firewall rules When designing and evaluating your firewall rules, keep in mind the following best practices: - Implement [least-privilege](https://en.wikipedia.org/wiki/Principle_of_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](https://docs.cloud.google.com/firewall/docs/firewall-policies.md.txt) 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#serviceaccounts) 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](https://docs.cloud.google.com/firewall/docs/firewall-policies-overview.md.txt) to group firewall rules for simplified configuration and deployment. [Firewall policy rules](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-details.md.txt) provide several rule components that provide granular traffic control: - Use [address groups](https://docs.cloud.google.com/firewall/docs/address-groups-firewall-policies.md.txt) to simplify using multiple IP address ranges in firewall rules. - Use [FQDN objects](https://docs.cloud.google.com/firewall/docs/fqdn-objects-overview.md.txt) 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](https://cloud.google.com/firewall/pricing). - Use [geolocation objects](https://docs.cloud.google.com/firewall/docs/geolocation-objects-overview.md.txt) 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](https://cloud.google.com/firewall/pricing). - Turn on [VPC firewall rules logging](https://docs.cloud.google.com/firewall/docs/vpc-firewall-rules-logging-overview.md.txt) and use [Firewall Insights](https://docs.cloud.google.com/network-intelligence-center/docs/firewall-insights/concepts/overview.md.txt) to verify that firewall rules are being used in the intended way. VPC firewall rules logging can incur [costs](https://cloud.google.com/vpc/pricing#network-telemetry), 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#firewall_rule_components). You create or modify VPC firewall rules by using the [Google Cloud console](https://console.cloud.google.com/), the [Google Cloud CLI](https://docs.cloud.google.com/sdk/gcloud/reference/compute/firewall-rules), and the [REST API](https://docs.cloud.google.com/compute/docs/reference/v1/firewalls). 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#rule_assignment) of the rule. For firewall rule examples, see [Other configuration examples](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt#other-config-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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#blockedtraffic). - 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#alwaysallowed). - VPC firewall rules are evaluated along with rules in firewall policies according to the [Firewall rule evaluation process](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-eval-order#default-rule-evaluation). 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#more_rules_default_vpc) 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#direction_of_the_rule). - Firewall rules support IPv4 connections. IPv6 connections are also supported in VPC networks that have [IPv6 enabled](https://docs.cloud.google.com/vpc/docs/subnets.md.txt#ipv6-ranges). 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`](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#action_of_the_rule). The rule applies to connections as long as it is [enforced](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#enforcement). 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](https://docs.cloud.google.com/vpc/docs/vpc-peering.md.txt) or by using [Cloud VPN tunnels](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/choosing-networks-routing.md.txt#dynamic-routing). - VPC firewall rules are [stateful](https://wikipedia.org/wiki/Stateful_firewall): - 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](https://tools.ietf.org/html/rfc792). - 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](https://docs.cloud.google.com/compute/docs/machine-types#sharedcore) | 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](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-eval-order#default-rule-evaluation). ### 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](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt#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](https://docs.cloud.google.com/compute/docs/machine-types) defines its maximum possible egress rate; however, you can only achieve that maximum possible egress rate in specific situations. For details, see [Network bandwidth](https://docs.cloud.google.com/compute/docs/network-bandwidth.md.txt) 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#gcp-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](https://docs.cloud.google.com/load-balancing/docs/https.md.txt), [external proxy Network Load Balancers](https://docs.cloud.google.com/load-balancing/docs/tcp.md.txt), and [external passthrough Network Load Balancers](https://docs.cloud.google.com/load-balancing/docs/network) only process [the protocols](https://docs.cloud.google.com/load-balancing/docs/forwarding-rule-concepts.md.txt#protocol-specifications) and [ports](https://docs.cloud.google.com/load-balancing/docs/forwarding-rule-concepts.md.txt#port_specifications) configured on the forwarding rule. - [Cloud VPN](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/overview.md.txt) gateways only accept [VPN protocols](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/overview.md.txt#specifications). | | **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](https://console.cloud.google.com/networking/networks/list) page or the [Firewall policies](https://console.cloud.google.com/net-security/firewall-manager/firewall-policies/list) 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](https://cloud.google.com/contact). 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#default_firewall_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](https://docs.cloud.google.com/vpc/docs/routes.md.txt#routingpacketsinternet) meet this requirement. - The instance sending packets to the external IP address must meet the [internet access requirements](https://docs.cloud.google.com/vpc/docs/vpc.md.txt#internet_access_reqs). 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](https://docs.cloud.google.com/firewall/docs/firewall-policies) do not apply to the following: - Packets [sent to and received from the Google Cloud metadata server](https://docs.cloud.google.com/firewall/docs/firewalls#gcp-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](https://docs.cloud.google.com/vpc/docs/alias-ip.md.txt) 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](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) - DNS resolution, following the [DNS name resolution order](https://docs.cloud.google.com/dns/docs/vpc-name-res-order) for the VPC network. - [Instance metadata](https://docs.cloud.google.com/compute/docs/storing-retrieving-metadata) - [Network Time Protocol (NTP)](https://en.wikipedia.org/wiki/Network_Time_Protocol) ## 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 global external passthrough Network Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/network/global-networklb-architecture#firewall-rules) - [Firewall rules in the regional external passthrough Network Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/network/networklb-backend-service#firewall_rules) - [Firewall rules in the internal passthrough Network Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/internal#firewall_rules) ### 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](https://docs.cloud.google.com/load-balancing/docs/https#firewall-rules) - [Firewall rules in the internal Application Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/l7-internal#firewall_rules) - [Firewall rules in the internal proxy Network Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/tcp/internal-proxy#firewall_rules) - [Firewall rules in the external proxy Network Load Balancer documentation](https://docs.cloud.google.com/load-balancing/docs/tcp#firewall-rules) ### 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](https://docs.cloud.google.com/network-connectivity/docs/vpn/concepts/overview#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](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/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](https://docs.cloud.google.com/ai-hypercomputer/docs/overview.md.txt). ## Firewall rule components Each firewall rule consists of the following configuration components: - A [direction](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#direction_of_the_rule) from the perspective of the target. Direction can be either ingress or egress. - A numerical [priority](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#priority_order_for_firewall_rules), 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](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#action_of_the_rule), either `allow` or `deny`, which determines whether the rule permits or blocks connections. - The [enforcement status](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#enforcement) of the firewall rule: You can enable and disable firewall rules without deleting them. - A [target](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#rule_assignment), which defines the instances (including GKE clusters and App Engine flexible environment instances) to which the rule applies. - A [source or destination](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#sources_or_destinations_for_the_rule) filter for packet characteristics. - The [protocol](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#protocols_and_ports) (such as TCP, UDP, or ICMP) and destination port. - A boolean [logs](https://docs.cloud.google.com/firewall/docs/vpc-log-format.md.txt) option which logs connections 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 from `0` to `65535`, inclusive; default `1000` | `allow` or `deny` | `enabled` (default) or `disabled` | Specifies the instances that *receive* packets. | [Sources for ingress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#source_parameter_ingress_rule) [Destinations for ingress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#destination_parameter_ingress_rule) | 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, see [Protocols and ports](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#protocols_and_ports). | | Integer from `0` to `65535`, inclusive; default `1000` | `allow` or `deny` | `enabled` (default) or `disabled` | Specifies the instances that *send* packets. | [Sources for egress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#source_parameter_egress_rule) [Destinations for egress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#destination_parameter_egress_rule) | 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, see [Protocols and ports](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#protocols_and_ports). | ### Direction of traffic You can create firewall rules that apply to ingress or egress traffic. A single rule cannot apply to both ingress and egress traffic. However, you can create multiple rules to define the ingress and egress traffic that you allow or deny through the firewall. - Ingress (inbound) describes packets *entering* a network interface of a [target](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#rule_assignment). - Egress (outbound) describes packets *leaving* a network interface of a [target](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#rule_assignment). - If you don't specify a direction, Google Cloud uses ingress. ### Priority The priority of a VPC firewall rule is similar to the [priority](https://docs.cloud.google.com/firewall/docs/firewall-policies-rule-details.md.txt#priority) of a rule in a firewall policy, with the following differences: | Feature | Firewall policy rule | VPC firewall rule | |---|---|---| | Range | 0 to 2,147,483,547 | 0 to 65,535 | | Default priority number | None | 1000 (default) | | Uniqueness | Must be unique within the policy | Can be shared across rules | 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 destination ports and protocols intended for all targets overrides a similarly defined rule with lower priority for the same destination ports and protocols intended for specific targets. - The highest priority rule applicable for a given protocol and destination port definition takes precedence, even when the protocol and destination port definition is more general. For example, a higher priority ingress rule allowing traffic for all protocols and destination ports intended for given targets overrides a lower priority ingress rule denying TCP 22 for the same targets. - A rule with a `deny` action overrides another with an `allow` action *only if the two rules have the same priority.* Using relative priorities, it is possible to build `allow` rules that override `deny` rules, and `deny` rules that override `allow` 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 enable [VPC firewall rules logging](https://docs.cloud.google.com/firewall/docs/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` (any IPv4 address) applicable to all targets, all protocols, and all destination ports, having a `deny` action and a priority of `1000`. - An ingress rule from sources `0.0.0.0/0` (any IPv4 address) applicable to specific targets with the network tag `webserver`, for traffic on TCP 80, with an `allow` action. The priority of the second rule determines whether TCP traffic to port 80 is allowed for the `webserver` targets: - 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 `webserver` targets. Absent other rules, the first rule would still deny other types of traffic to the `webserver` targets, and it would also deny all traffic, including TCP 80, to instances *without* the `webserver` network tag. 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 least privilege. ### 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: - An `allow` action permits connections that match the other specified components. - A `deny` action blocks connections that match the other specified components. > [!NOTE] > **Note:** A firewall rule can only have one action component. Both `allow` and `deny` *cannot* be specified in the same rule. To define the order in which the rules should be applied, create separate firewall rules with different priorities. ### Enforcement You can choose whether a firewall rule is *enforced* by setting its state to `enabled` or `disabled`. You set the enforcement state when you [create a rule](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt#creating_firewall_rules) or when you [update a rule](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt#updating_firewall_rules). If you don't set an enforcement state when you create a new firewall rule, the firewall rule is automatically `enabled`. #### Use cases Disabling and enabling are useful for troubleshooting and performing maintenance. Consider changing the enforcement of a firewall rule in the following situations: - For troubleshooting: In conjunction with [VPC firewall rules logging](https://docs.cloud.google.com/firewall/docs/firewall-rules-logging), you can temporarily disable a firewall rule to determine if the rule is responsible for blocking or allowing traffic. This is useful for situations where multiple firewall rules apply to the same traffic. Disabling and enabling rules is more useful than deleting and re-creating rules because none of the other components of the rule are lost. - For maintenance: Disabling firewall rules can simplify periodic maintenance. For example, you might choose to enable an ingress firewall rule that allows SSH access only at times when you need to perform maintenance using SSH. When you're not performing maintenance, you can disable the rule. #### Effects on existing traffic When you change a firewall rule's enforcement state, create a new `enforced` rule, or modify firewall rules to deny traffic that was previously allowed, Cloud NGFW enforces this change only on new connections. Existing connections persist, and their associated traffic remains unaffected. ### Protocols and ports You can narrow the scope of a firewall rule by specifying protocols or protocols and destination ports. You can specify a protocol or a combination of protocols and their destination ports. If you omit both protocols and ports, the firewall rule is applicable for all traffic on any protocol and any destination port. Rules based on source ports are not supported. Not all protocols support ports. For example, ports exist for TCP and UDP, but not for ICMP. ICMP does have different *ICMP types*, but they are not ports and 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`, and `ipip`. For all other protocols, you must use the [IANA protocol numbers](http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). Many protocols use the same name and number in both IPv4 and IPv6, but some protocols, 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 specification combinations 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, see [Create firewall rules](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt#creating_firewall_rules). | > [!IMPORTANT] > **Important:** A port cannot be specified by itself. If you only specify a number, Google Cloud interprets that as a decimal IP *protocol* . For example, if you specify `80` by itself, Google Cloud interprets that as IP protocol `80` (ISO-IP), which is not the same as TCP *port* 80 (`tcp:80`). ## Target, source, destination Targets identify the network interfaces of instances to which the firewall rule applies. You can specify both source and destination parameters that apply to the packet sources or destinations for both ingress and egress firewall rules. The direction of the firewall rule determines the possible values for the source and destination parameters. ### Target parameter The *target* parameter identifies the network interfaces of the Compute Engine instances, including GKE nodes and App Engine flexible environment instances. You can define the following targets for both ingress or egress rules. The target, source, and destination parameters work together as described in [Source, destination, target](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#sources_or_destinations_for_the_rule). - **Default target---all instances in the VPC network.** When you omit a target specification, the firewall rule applies to all instances in the VPC network. - **Instances by target network tags.** The firewall rule only applies to instances with network interfaces in the firewall rule's VPC network if the instances have a [network tag](https://docs.cloud.google.com/vpc/docs/add-remove-network-tags) that matches at least one of the firewall rule's target network tags. For the maximum number of target network tags that you can specify per firewall rule, see [per firewall rule limits](https://docs.cloud.google.com/firewall/docs/quotas#per-firewall-rule). - **Instances by target service accounts.** The firewall rule only applies to instances with network interfaces in the firewall rule's VPC network if the instances use a [service account](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#serviceaccounts) that matches at least one of the firewall rule's target service accounts. For the maximum number of target service accounts that you can specify per firewall rule, see [per firewall rule limits](https://docs.cloud.google.com/firewall/docs/quotas.md.txt#per-firewall-rule). For information about the benefits and limitations of target network tags and target service accounts, see [filtering by service account versus network tag](https://docs.cloud.google.com/firewall/docs/firewalls#service-accounts-vs-tags). #### Targets and IP addresses for ingress rules The packets routed to the network interface of a target VM are processed based on the following conditions: - If the ingress firewall rule *includes* a destination IP address range, the packet's destination must fit within one of the explicitly defined destination IP address ranges. - If the ingress firewall rule *does 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 configured [alias IP ranges](https://docs.cloud.google.com/vpc/docs/alias-ip.md.txt) on the instance'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 to the NIC. - An internal or external IP address associated with a forwarding rule used for pass-through load balancing, where the instance is a backend for an internal passthrough Network Load Balancer or an external passthrough Network Load Balancer. - An internal or external IP address associated with a forwarding rule used for protocol forwarding, where the instance is referenced by a target instance. - An IP address within the destination range of a custom static route that uses the instance as a next hop VM (`next-hop-instance` or `next-hop-address`). - An IP address within the destination range of a custom static route using an internal passthrough Network Load Balancer (`next-hop-ilb`) next hop, if the VM is a backend for that load balancer. #### Targets and IP addresses for egress rules The processing of packets emitted from the network interface of a target depends on the [IP forwarding](https://docs.cloud.google.com/vpc/docs/using-routes.md.txt#canipforward) configuration on the target VM. IP forwarding is disabled by default. - When the target VM has IP forwarding disabled, the VM can emit packets with the following 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 to the NIC. - An internal or external IP address associated with a forwarding rule, for pass-through load balancing or protocol forwarding, if the instance is a backend for an internal passthrough Network Load Balancer, an external passthrough Network Load Balancer, or is referenced by a target instance. If the egress firewall rule *includes* source IP address ranges, the target VMs are still limited to the source IP addresses mentioned previously, but the source parameter can be used to refine that set. Use of a source parameter without enabling IP forwarding *does not expand* the set of possible packet source addresses. If the egress firewall rule *does not include* a source IP address range, all the source IP addresses mentioned previously are permitted. - When the target VM has IP forwarding enabled, the VM can emit packets with arbitrary source addresses. You can use the source parameter to more precisely 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 range `0.0.0.0/0` (any IPv4 address). The default value does not include IPv6 sources. - **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 more [network tags](https://docs.cloud.google.com/vpc/docs/add-remove-network-tags) that identify network interfaces of VM instances in the same VPC network as the firewall rule. For the maximum number of source network tags per firewall rule, see [per firewall rule limits](https://docs.cloud.google.com/firewall/docs/quotas#per-firewall-rule). For details about how packet source addresses are matched when using this implicit source specification, see [How source network tags and source service accounts imply packet sources](https://docs.cloud.google.com/firewall/docs/firewalls#sources-and-ips). - **Source service accounts:** One or more [service accounts](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#serviceaccounts) that identify network interfaces of VM instances in the same VPC network as the firewall rule. For the maximum number of source service accounts per firewall rule, see [per firewall rule limits](https://docs.cloud.google.com/firewall/docs/quotas#per-firewall-rule). For details about how packet source addresses are matched when using this implicit source specification, see [How source network tags and source service accounts imply packet sources](https://docs.cloud.google.com/firewall/docs/firewalls#sources-and-ips). - **A valid source combination:** For all of the following combinations, the effective source set is the *union* of the IPv4 or IPv6 addresses that are explicitly specified and the IP address ranges that are implied by source network tag or source service account: - A combination of *source IPv4 ranges* and *source network tags*. - A combination of *source IPv6 ranges* and *source network tags*. - A combination of *source IPv4 ranges* and *source service accounts*. - A combination of *source IPv6 ranges* and *source service accounts*. > [!IMPORTANT] > **Important:** Network tags and service accounts cannot be used in the same firewall rule. For more information, see [filtering by service account versus network > tag](https://docs.cloud.google.com/firewall/docs/firewalls#service-accounts-vs-tags). **How source network tags and source service accounts imply packet sources** When an ingress firewall rule uses a source network tag, the packets must be emitted from a network interface that meets the following criteria: - The network interface must be in the VPC network where the firewall rule is defined, and - The network interface must be associated with a VM that has a network tag that matches at least one of the firewall rule's source network tags. When an ingress firewall rule uses a source service account, the packets must be emitted from a network interface that meets the following criteria: - The network interface must be in the VPC network where the firewall rule is defined, and - The network interface must be associated with a VM that has a service account that matches one of the firewall rule's source service accounts. In addition to specifying a network interface, when an ingress firewall rule uses either a source network tag or a source service account, packets emitted from the network interface 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 contains [destination IP address ranges](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#destination_parameter_ingress_rule), the network interface bound to a network tag is resolved to the same IP version as the destination IP range. No other packet source IP addresses are implied when using source network tags or source service accounts. For example, alias IP ranges and external IPv4 address associated with the network interface are excluded. If you need to create ingress firewall rules whose sources include alias IP address ranges or 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 an egress rule, packet sources are defined implicitly as described in [Targets and IP addresses for egress rules](https://docs.cloud.google.com/firewall/docs/firewalls#targets_and_ips_egress). - **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 an IPv4 address range or an IPv6 address range, but not both. For details, see [Destinations for egress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#destination_parameter_egress_rule). ### Destination parameter Destinations can be specified by using IP address ranges, which are supported by both ingress and egress rules. The default destination behavior depends on the direction 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 from an ingress rule, packet destinations are defined implicitly as described in [Targets and IP addresses for ingress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#targets_and_ips_ingress). - **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 as the destination IP address range. To learn more about how to define sources for ingress rules, see [Sources for ingress rules](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#source_parameter_ingress_rule). #### Destinations for egress rules You can use the following destinations for egress firewall rules: - **Default destination range.** When you omit a destination specification in an egress rule, Google Cloud uses the default destination IPv4 address range `0.0.0.0/0` (any IPv4 address). The default value does not include IPv6 destinations. - **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 use [service accounts](https://docs.cloud.google.com/iam/docs/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](https://docs.cloud.google.com/iam/docs/creating-managing-service-accounts) 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. > [!NOTE] > **Note:** You cannot use [Workload Identity Federation for GKE](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/workload-identity.md.txt) service accounts in the VPC firewall rules for source and target filtering. Firewall rules that use service accounts to identify instances apply to both [new instances created and associated with the service account](https://docs.cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#createanewserviceaccount) and existing instances if you [change their service accounts](https://docs.cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes). 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](https://docs.cloud.google.com/compute/docs/instance-groups). > [!NOTE] > **Note:** In projects with a standalone VPC (a VPC that does not participate in Shared VPC), you can only use service accounts from that project as firewall rule criteria. In projects using [Shared VPC](https://docs.cloud.google.com/vpc/docs/shared-vpc.md.txt), you can use service accounts from the host project or any service project as firewall rule criteria. If you create a firewall 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 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 network tags and source network tags: - *A network tag is an arbitrary attribute.* One or more [network tags can be associated](https://docs.cloud.google.com/vpc/docs/add-remove-network-tags) with an instance by any Identity and Access Management (IAM) principal who has permission to edit it. IAM principals with the [Compute Engine Instance Admin role](https://docs.cloud.google.com/iam/docs/roles-permissions/compute#compute-engine-roles) to a project have this permission. IAM principals 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](https://docs.cloud.google.com/iam/docs/roles-permissions/iam.md.txt#iam.serviceAccountUser) for other IAM principals. For an IAM principal to start an instance by using a service account, that principal must have the Service Account User role to at least use 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 network tags together in any firewall rule (ingress or egress). - If you specify targets by target network tag or target service account, the following are 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 restarting it. Adding or removing network 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 [per firewall rule limits](https://docs.cloud.google.com/firewall/docs/quotas#per-firewall-rule). - 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. ## Roles and permissions The following table describes the IAM permissions that you need for working with VPC firewall rules. | Task | Required permission | Sample role | |---|---|---| | Create a firewall rule | `compute.firewalls.create` | [Compute Security Admin role](https://docs.cloud.google.com/iam/docs/roles-permissions/compute.md.txt#compute.securityAdmin) (`roles/compute.securityAdmin`) | | Delete a firewall rule | `compute.firewalls.delete` | [Compute Security Admin](https://docs.cloud.google.com/compute/docs/access/iam.md.txt#compute.securityAdmin) (`roles/compute.securityAdmin`) | | Make changes to firewall rules | `compute.firewalls.update` | [Compute Security Admin role](https://docs.cloud.google.com/iam/docs/roles-permissions/compute.md.txt#compute.securityAdmin) (`roles/compute.securityAdmin`) | | View details about a firewall rule | `compute.firewalls.get` | [Compute Network Viewer role](https://docs.cloud.google.com/iam/docs/roles-permissions/compute.md.txt#compute.networkViewer) (`roles/compute.networkViewer`) | | View a list of firewall rules | `compute.firewalls.list` | [Compute Network Viewer role](https://docs.cloud.google.com/iam/docs/roles-permissions/compute.md.txt#compute.networkViewer) (`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 target instances in your VPC network. The source for an ingress rule can be 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 network tags - Other instances in your VPC network identified by service account - Other instances in your VPC network identified by range of IPv4 or IPv6 address *and* by network tag - Other instances in your VPC network identified by range of IPv4 or IPv6 addresses *and* by service account The default source is any IPv4 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 IP addresses in CIDR format. Ingress rules with an `allow` action permit incoming traffic based on the other [components of the rule](https://docs.cloud.google.com/firewall/docs/firewalls.md.txt#firewall_rule_components). In addition to specifying the source and target for the rule, you can limit the rule to apply to specific protocols and destination ports. Similarly, ingress rules with a `deny` action can be used to protect instances by blocking incoming traffic based on the firewall rule components. > [!CAUTION] > **Caution:** You can also use target service accounts or target network tags to specify the ingress destinations. If you do that, you limit how you can specify the source for the rule. For more information, see [filtering by service account versus network > tag](https://docs.cloud.google.com/firewall/docs/firewalls#service-accounts-vs-tags). #### Ingress examples Figure 1 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. [![In this example VPC network, the allow ingress firewall rules override the implied deny ingress rule for some VMs.](https://docs.cloud.google.com/static/firewall/images/firewalls/firewall_overview_ingress_examples.svg)](https://docs.cloud.google.com/static/firewall/images/firewalls/firewall_overview_ingress_examples.svg) **Figure 1.** In this example VPC network, the allow ingress firewall rules override the implied deny ingress rule for some VMs (click to enlarge). - An ingress rule with priority `1000` is applicable to **VM 1** . This rule allows incoming TCP traffic from any IPv4 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 and from **VM 2** via external IP addresses. - **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 `1000` is 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 cases 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](https://docs.cloud.google.com/firewall/docs/firewalls#firewall_rule_components). For example, you can permit outbound traffic to specific destinations, such as a range of IPv4 addresses, on protocols and destination 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 IPv4 address (`0.0.0.0/0`), but you can create a more specific destination by using a range of IPv4 or IPv6 addresses in CIDR format. When specifying a range of IP addresses, you can control traffic to instances in your network and to destinations outside your network, including destinations on the internet. #### Egress examples Figure 2 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. [![In this example VPC network, the deny egress firewall rules override the implied allow egress rule for some VMs.](https://docs.cloud.google.com/static/firewall/images/firewalls/firewall_overview_egress_examples.svg)](https://docs.cloud.google.com/static/firewall/images/firewalls/firewall_overview_egress_examples.svg) **Figure 2.** In this example VPC network, the deny egress firewall rules override the implied allow egress rule for some VMs (click to enlarge). - **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 `1000` is applicable to **VM 2** . This rule denies all outgoing traffic to all IPv4 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 `1000` is applicable to **VM 3** . This rule blocks its outgoing TCP traffic to any destination in the `192.168.1.0/24` IP 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/24` IP 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. ## What's next - To create and work with firewall rules, see [Use VPC firewall rules](https://docs.cloud.google.com/firewall/docs/using-firewalls.md.txt).