Firewall policy rules

When you create a firewall policy rule, you specify a set of components that define what the rule does. These components specify traffic direction, source, destination, and Layer 4 characteristics such as protocol and destination port (if the protocol uses ports).

Each firewall policy rule applies to incoming (ingress) or outgoing (egress) connections, not both.

Ingress rules

Ingress direction refers to the incoming connections sent from specific sources to Google Cloud targets. Ingress rules apply to inbound packets, where the destination of the packets is the target.

An ingress rule with a deny action protects all instances by blocking incoming connections to them. A higher priority rule might allow incoming access. An automatically created default network includes some pre-populated VPC firewall rules, which allow ingress for certain types of traffic.

Egress rules

Egress direction refers to the outbound traffic sent from a target to a destination. Egress rules apply to packets for new connections where the source of the packet is the target.

An egress rule with an allow action lets an instance send traffic to the destinations specified in the rule. Egress can be denied by higher priority deny firewall rules. Google Cloud also blocks or limits certain kinds of traffic.

Firewall policy rule components

Rules in hierarchical firewall policies, global network firewall policies, and regional network firewall policies use the components described in this section. The term firewall policy refers to any of these three types of policies. For more information about the types of firewall policies, see Firewall policies.

Firewall policy rules generally work the same as VPC firewall rules, but there are a few differences as described in the following sections.

Priority

The priority of a rule in a firewall policy is an integer from 0 to 2,147,483,647, inclusive. Lower integers indicate higher priorities. The priority of a rule in a firewall policy is similar to the priority of a VPC firewall rule, with the following differences:

  • Each rule in a firewall policy must have a unique priority.
  • The priority of a rule in a firewall policy serves as the rule's unique identifier. Rules in firewall policies don't use names for identification.
  • The priority of a rule in a firewall policy defines the evaluation order within the firewall policy itself. VPC firewall rules and rules in hierarchical firewall policies, global network firewall policies, and regional network firewall policies are evaluated as described in Policy and rule evaluation order.

Action on match

A rule in a firewall policy can have one of the following actions:

  • allow permits traffic and stops further rule evaluation.
  • deny disallows traffic and stops further rule evaluation.
  • apply_security_profile_group transparently intercepts the traffic and sends it to the configured firewall endpoint for Layer 7 inspection.

Enforcement

You can choose whether a firewall policy rule is enforced by setting its state to enabled or disabled. You set the enforcement state when you create a rule or when you update a rule.

If you don't set an enforcement state when you create a new firewall rule, the firewall rule is automatically enabled.

Protocols and ports

Similar to VPC firewall rules, you must specify one or more protocol and port constraints when you create a rule. When specifying TCP or UDP in a rule, you can specify the protocol, the protocol and a destination port, or the protocol and a destination port range; you cannot specify only a port or port range. Also, you can only specify destination ports. Rules based on source ports are not supported.

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, use the IANA protocol numbers.

Many protocols use the same name and number in both IPv4 and IPv6, but some protocols, such as ICMP, don't. To specify IPv4 ICMP, use icmp or protocol number 1. For IPv6 ICMP, use protocol number 58.

Firewall rules don't support specifying ICMP types and codes, just the protocol.

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

If you don't specify protocol and port parameters, the rule applies to all protocols and destination ports.

Logging

Logging for firewall policy rules works the same as for VPC Firewall Rules Logging except for the following:

  • The reference field includes the firewall policy ID and a number indicating the level of the resource to which the policy is attached. For example, 0 means that the policy is applied to an organization, and 1 means that the policy is applied to a top-level folder under the organization.

  • Logs for firewall policy rules include a target_resource field that identifies the VPC networks to which the rule applies.

  • Logging can only be enabled for allow,deny, and apply_security_profile_group rules; it cannot be enabled for goto_next rules.

Target, source, destination

Target parameters identify the network interfaces of instances to which a firewall rule applies.

You can specify both source parameters 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.

The target, source, and destination parameters work together.

Targets

The target parameter identifies the network interfaces of the Compute Engine instances, including GKE nodes and App Engine flexible environment instances.

You can define targets for both ingress or egress rules. Valid target options depend on the type of firewall policy.

Targets for hierarchical firewall policy rules

Hierarchical firewall policy rules support the following targets:

  • Default broadest target: When you omit the target specification in a hierarchical firewall policy rule, the firewall rule applies to all instances in all VPC networks in all the projects under the Resource Manager node (folder or organization) associated with the firewall policy. This is the broadest set of targets.

  • Specific networks: If you specify one or more VPC networks by using the target-resources parameter, the broadest set of targets is narrowed to VMs with a network interface in at least one of the specified VPC networks.

  • Instances identified by service account: If you specify one or more service accounts by using the target-service-accounts parameter, the broadest set of targets is narrowed to VMs that use one of the specified service accounts.

  • Specific networks and instances identified by service account: If you specify both the target-resources parameter and the target-service-accounts parameter, the broadest set of targets is narrowed to the VMs that meet both of the following criteria:

    • The VMs have a network interface in one of the specified VPC networks.
    • The VMs use one of the specified service accounts.

Targets for global network firewall policy rules

Global network firewall policy rules support the following targets:

  • Default target—all instances in the VPC network: When you omit the target specification in a global network firewall policy rule, the firewall rule applies to instances that have a network interface in the VPC network associated with the policy. The instances can be located in any region. This is the broadest set of targets.

  • Instances by target secure tags: If you specify target tags with the target-secure-tags parameter, the broadest set of targets is narrowed to include only those VMs bound to the tags.

  • Instances by target service accounts: If you specify service accounts with the target-service-accounts parameter, the broadest set of targets is narrowed to include only those VMs that use one of the specified service accounts.

Targets for regional network firewall policy rules

Regional network firewall policy rules support the following targets:

  • Default target—all instances in the region and VPC network: When you omit the target specification in a regional network firewall policy rule, the firewall rule applies to instances that have a network interface in the VPC network associated with the policy. The instances must be located in the same region as the policy. This is the broadest set of targets.

  • Instances by target secure tags: If you specify target tags with the target-secure-tags parameter, the broadest set of targets is narrowed to include only those VMs bound to the tags.

  • Instances by target service accounts: If you specify service accounts with the target-service-accounts parameter, the broadest set of targets is narrowed to include only those VMs that use one of the specified service accounts.

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 address ranges 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 (next-hop-instance or next-hop-address) as a next hop VM.

    • An IP address within the destination range of a custom static route that uses an internal passthrough Network Load Balancer (next-hop-ilb) as a 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 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 address 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. This is valid 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.

Sources

Source parameter values depend on the following:

  • The type of firewall policy that contains the firewall rule
  • The direction of the firewall rule

Sources for ingress rules

The following table lists source parameters that can be used individually or in combination with each other in a single ingress firewall policy rule. Cloud NGFW requires that you specify at least one source parameter.

Ingress rule source parameter Support in hierarchical firewall policies Support in global and regional network firewall policies
Source IP address ranges

A simple list consisting of IPv4 addresses in CIDR format or IPv6 addresses in CIDR format. The list is stored within the firewall policy rule itself.
Source address groups

Reusable collections of IPv4 addresses in CIDR format or IPv6 addresses in CIDR format. The firewall rule references the collection. For more information, see Address groups for firewall policies.
Source domain names

A list of one or more source domain names. For more information, including how domain names are converted to IP addresses, see FQDN objects.
Source secure tags

A list of one or more source secure tags. For more information, see How source secure tags imply packet sources.
Source geolocations

A list of one or more source geographic locations specified as two-letter country or region codes. For more information, see Geolocation objects.
Source Google Threat Intelligence lists

A list of one or more predefined Google Threat Intelligence list names. For more information, see Google Threat Intelligence for firewall policy rules.
Source network scope

A constraint that defines a security boundary. For more information, see Network scopes.

In a single ingress rule, you can use two or more source parameters to produce a source combination. Cloud NGFW enforces the following constraints on source combinations of each ingress rule:

  • Source IP address ranges must contain either IPv4 or IPv6 CIDRs, not a combination of both.
  • A source address group that contains IPv4 CIDRs cannot be used with a source address group that contains IPv6 CIDRs.
  • A source IP address range that contains IPv4 CIDRs cannot be used with a source address group that contains IPv6 CIDRs.
  • A source IP address range that contains IPv6 CIDRs cannot be used with a source address group that contains IPv4 CIDRs.
  • The internet network scope cannot be used with the source secure tags.
  • Non-internet scope, VPC networks scope, and inter-VPC scope cannot be used with source Google Threat Intelligence lists or source geolocations.

Cloud NGFW applies the following logic to match the packets to an ingress rule that uses a source combination:

  • If the source combination doesn't include a source network scope, packets match the ingress rule if they match at least one source parameter in the source combination.

  • If the source combination includes a source network scope, packets match the ingress rule if they match the source network scope and at least one of the other source parameters in the source combination.

How source secure tags imply packet sources

Ingress rules in global and regional network firewall policies can specify sources by using secure tags. Each secure tag is associated with a single VPC network, and a secure tag can only be bound to a VM that has a network interface in the VPC network to which the secure tag is associated.

Packets sent from a network interface of a VM match an ingress rule that uses a secure tag source when the following conditions are true:

  • If the ingress rule is in a regional network policy, the VM must be located in a zone of the network firewall policy's region. If the ingress rule is in a global network firewall policy, the VM can be located in any zone.

  • The network interface of the VM that sends the packets meets one of the following criteria:

    • VM network interface is in the same VPC network as the VPC network to which the global or regional network firewall policy applies.
    • VM network interface is in a VPC network that's connected, using VPC Network Peering, to the VPC network to which the global or regional network firewall policy applies.
    • The VPC network that's used by the VM network interface and the VPC network to which the global or regional network firewall policy applies are both VPC spokes on the same Network Connectivity Center hub.

  • The source IP address of the packet is one of the following:

    • The primary internal IPv4 address of the network interface.
    • Any IPv6 address (internal or external) assigned to the network interface.

No other source IP addresses of the packet are resolved when using source secure tags. For example, alias IP address ranges and external IPv4 addresses associated with the network interface are excluded. If you need to create ingress firewall rules with sources that include alias IP address ranges or external IPv4 addresses, use a source address range or source address group instead.

Sources for egress rules

You can use the following sources for egress rules in both hierarchical firewall policies and network firewall policies:

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

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

  • Source IPv6 address 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 have a source IP address range and destination parameters in the egress rule, then the destination parameters are resolved into the same IP version as the source IP version.

    For example, in an egress rule, you have an IPv4 address range in the source parameter and an FQDN object in the destination parameter. If the FQDN resolves into both IPv4 and IPv6 addresses, only the resolved IPv4 address is used during rule enforcement.

Destinations

Destinations can be specified by using IP address ranges, which are supported by both ingress and egress rules in both hierarchical and network firewall policies. 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 in both hierarchical and network firewall policies:

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

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

  • Destination IPv6 address 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 have both source and destination parameters defined in an ingress rule, then the source parameters are resolved into the same IP version as the destination IP version. To learn more about how to define a source for ingress rules, see Sources for ingress rules in hierarchical firewall policies and Sources for ingress rules in network firewall policies.

    For example, in an ingress rule, you have an IPv6 address range in the destination parameter and a geolocation country code in the source parameter. During rule enforcement, only the mapped IPv6 address is used for the specified source country code.

Destinations for egress rules

The following table lists destination parameters that can be used individually or in combination with each other in a single egress firewall policy rule. Cloud NGFW requires that you specify at least one destination parameter.

Egress rule destination parameter Support in hierarchical firewall policies Support in global and regional network firewall policies
Destination IP address ranges

A simple list consisting of IPv4 addresses in CIDR format or IPv6 addresses in CIDR format. The list is stored within the firewall policy rule itself.
Destination address groups

Reusable collections of IPv4 addresses in CIDR format or IPv6 addresses in CIDR format. The firewall policy rule references the collection. For more information, see Address groups for firewall policies.
Destination domain names

A list of one or more source domain names. For more information, including how domain names are converted to IP addresses, see FQDN objects.
Destination geolocations

A list of one or more source geographic locations specified as two-letter country or region codes. For more information, see Geolocation objects.
Destination Google Threat Intelligence lists

A list of one or more predefined Google Threat Intelligence list names. For more information, see Google Threat Intelligence for firewall policy rules.
Destination network scope

A constraint that defines a security boundary. For more information, see Network scopes.

In a single egress rule, you can use two or more destination parameters to produce a destination combination. Cloud NGFW enforces the following constraints on destination combinations of each egress rule:

  • Destination IP address ranges must contain either IPv4 or IPv6 CIDRs, not a combination of both.
  • A destination address group that contains IPv4 CIDRs cannot be used with a destination address group that contains IPv6 CIDRs.
  • A destination IP address range that contains IPv4 CIDRs cannot be used with a destination address group that contains IPv6 CIDRs.
  • A destination IP address range that contains IPv6 CIDRs cannot be used with a destination address group that contains IPv4 CIDRs.
  • Destination Google Threat Intelligence lists or destination geolocations cannot be used with destination non-internet network scope.

Cloud NGFW applies the following logic to match the packets to an egress rule that uses a destination combination:

  • If the destination combination doesn't include a destination network scope, packets match the egress rule if they match at least one destination parameter in the destination combination.

  • If the destination combination includes a destination network scope, packets match the egress rule if they match the destination network scope and at least one of the other destination parameters in the destination combination.

Network scopes

Network scopes help you meet your security goals by using fewer firewall policy rules more efficiently. Cloud NGFW supports four types of network scopes that can be used to create a source combination or destination combination in a rule of a hierarchical firewall policy, global network firewall policy, or regional network firewall policy.

Network scope types

The following table lists the four types of network scopes and whether a scope type can be used in a source combination of an ingress rule, in a destination combination of an egress rule, or in both.

Network scope type Sources for ingress rules Destinations for egress rules
Internet (INTERNET)
Non-internet (NON_INTERNET)
VPC networks (VPC_NETWORKS)
Intra-VPC (INTRA_VPC)

The internet and non-internet scopes are mutually exclusive. The VPC networks and intra-VPC scopes are subsets of the non-internet scope.

Internet scope

The internet scope (INTERNET) can be used as part of a source combination of an ingress rule or as part of a destination combination of an egress rule:

  • For an ingress rule, specify the internet scope source and at least one other source parameter, except for a secure tag source. Packets match the ingress rule if they match at least one of the other source parameters and match the internet scope source parameter.

  • For an egress rule, specify the internet scope destination and at least one other destination parameter. Packets match the egress rule if they match at least one of the other destination parameters and match the internet scope destination parameter.

The rest of this section describes the criteria Cloud NGFW uses to determine whether a packet belongs to the internet scope.

Internet scope for ingress packets

Ingress packets routed to a VM network interface by a Google Maglev are considered in the internet scope. Packets are routed by a Maglev to a VM network interface when the packet destination matches one of the following:

  • A regional external IPv4 address of a VM network interface, forwarding rule of an external passthrough Network Load Balancer, or forwarding rule for external protocol forwarding.
  • A regional external IPv6 address of a VM network interface, forwarding rule of an external passthrough Network Load Balancer, or forwarding rule for external protocol forwarding, and the packet was not routed using a subnet route imported by VPC Network Peering or from a VPC spoke on a Network Connectivity Center hub.

For more information about packets routed by Maglev to backend VMs for an external passthrough Network Load Balancer or external protocol forwarding, see Paths for external passthrough Network Load Balancers and external protocol forwarding.

Internet scope for egress packets

Egress packets sent by the VM network interfaces and routed by using static routes that use the default internet gateway next hop are considered in the internet scope. However, if the destination IP address of these egress packets is for Google APIs and services, these packets are considered in the non-internet scope. For more information about connectivity to Google APIs and services, see Non-internet scope.

When the packets are routed using a static route that uses the default internet gateway next hop, any packets sent by the VM network interfaces to the following destinations are considered in the internet scope:

  • An external IP address destination outside of Google's network.
  • A regional external IPv4 address destination of a VM network interface, forwarding rule of a regional external load balancer, or forwarding rule for external protocol forwarding.
  • A regional external IPv6 address destination of a VM network interface, forwarding rule of a regional external load balancer, or forwarding rule for external protocol forwarding.
  • A global external IPv4 and IPv6 address destination of a forwarding rule of a global external load balancer.

Packets sent by the VM network interfaces to Cloud VPN and Cloud NAT gateways are considered in the internet scope:

  • Egress packets sent from a network interface of a VM running VPN software to a Cloud VPN gateway's regional external IPv4 address are considered in the internet scope.
  • Egress packets sent from one Cloud VPN gateway to another Cloud VPN gateway aren't considered in any network scope because firewall rules only apply to VMs.
  • For Public NAT, response packets sent from a VM network interface to a Cloud NAT gateway's regional external IPv4 address are considered in the internet scope.

If VPC networks are connected using VPC Network Peering or if VPC networks participate as VPC spokes on the same Network Connectivity Center hub, IPv6 subnet routes can provide connectivity to regional external IPv6 address destinations of VM network interfaces, regional external load balancer forwarding rules, and external protocol forwarding rules. When the connectivity to those regional external IPv6 address destinations is provided using a subnet route, the destinations are in the non-internet scope instead.

Non-internet scope

The non-internet scope (NON-INTERNET) can be used as part of a source combination of an ingress rule or as part of a destination combination of an egress rule:

  • For an ingress rule, specify the non-internet scope source and at least one other source parameter, except for a threat intelligence list source or a geolocation source. Packets match the ingress rule if they match at least one of the other source parameters and match the non-internet scope source parameter.

  • For an egress rule, specify the non-internet scope destination and at least one other destination parameter. Packets match the egress rule if they match at least one of the other destination parameters and match the non-internet scope destination parameter.

The rest of this section describes the criteria Cloud NGFW uses to determine whether a packet belongs to the non-internet scope.

Non-internet scope for ingress packets

Ingress packets routed to a VM network interface using next hops within a VPC network or from Google APIs and services are considered in the non-internet scope.

Packets are routed by using next hops within a VPC network or from Google APIs and services in the following scenarios:

  • The packet destination matches one of the following:

    • A regional internal IPv4 or IPv6 address of a VM network interface, forwarding rule of an internal passthrough Network Load Balancer, or forwarding rule for internal protocol forwarding.
    • A regional external IPv6 address of a VM network interface, forwarding rule of an external passthrough Network Load Balancer, or forwarding rule for external protocol forwarding, and the packet was routed using a local subnet route, a peering subnet route, or an Network Connectivity Center subnet route.
    • Any address within the destination range of a static route where the receiving VM is either a next hop VM or a backend VM of a next hop internal passthrough Network Load Balancer.

  • The packet source matches one of the following:

Non-internet scope for egress packets

Egress packets either sent by the VM network interfaces and routed within a VPC network or sent to Google APIs and services are considered in the non-internet scope.

Packets are routed by using next hops within a VPC network or to Google APIs and services in the following scenarios:

VPC networks scope

The VPC networks scope (VPC_NETWORKS) can only be used as part of a source combination of an ingress rule. You cannot use the VPC networks scope as part of a destination combination of an egress rule.

To use the VPC networks scope as part of a source combination of an ingress rule, do the following:

  1. You must specify a list of source VPC networks:

    • The source network list must contain at least one VPC network. You can add a maximum of 250 VPC networks to the source network list.
    • A VPC network must exist before you can add it to the source network list.
    • You can add the network by using either its partial or full URL identifier.
    • VPC networks that you add to the source network list don't need to be connected to each other. Each VPC network can be located in any project.
    • If a VPC network is deleted after it is added to the source network list, the reference to the deleted network remains in the list. Cloud NGFW ignores deleted VPC networks when enforcing an ingress rule. If all VPC networks in the source network list are deleted, ingress rules that rely on the list are ineffective because they don't match any packets.

  2. You must specify at least one other source parameter, except for a threat intelligence list source or geolocation source.

A packet matches an ingress rule that uses the VPC networks scope in its source combination if all of the following conditions are true:

  • The packet matches at least one of the other source parameters.

  • The packet is sent by a resource located in one of the source VPC networks.

  • The source VPC network and the VPC network to which the firewall policy containing the ingress rule applies are the same VPC network, or are connected either by using VPC Network Peering or as VPC spokes on a Network Connectivity Center hub.

The following resources are located in a VPC network:

  • VM network interfaces
  • Cloud VPN tunnels
  • Cloud Interconnect VLAN attachments
  • Router appliances
  • Envoy proxies in a proxy-only subnet
  • Private Service Connect endpoints
  • Serverless VPC Access connectors

Intra-VPC scope

The intra-VPC network scope (INTRA_VPC) can only be used as part of a source combination of an ingress rule. You cannot use the intra-VPC scope as part of a destination combination of an egress rule.

To use the intra-VPC scope as part of a source combination of an ingress rule, you must specify at least one other source parameter, except for a threat intelligence list source or geolocation source.

A packet matches an ingress rule that uses the intra-VPC scope in its source combination if all of the following conditions are true:

  • The packet matches at least one of the other source parameters.

  • The packet is sent by a resource located in the VPC network to which the firewall policy containing the ingress rule applies.

The following resources are located in a VPC network:

  • VM network interfaces
  • Cloud VPN tunnels
  • Cloud Interconnect VLAN attachments
  • Router appliances
  • Envoy proxies in a proxy-only subnet
  • Private Service Connect endpoints
  • Serverless VPC Access connectors

Geolocation objects

Use geolocation objects in firewall policy rules to filter external IPv4 and external IPv6 traffic based on specific geographic locations or regions.

You can apply rules with geolocation objects to ingress and egress traffic. Based on the direction of the traffic, the IP addresses associated with the country codes are matched against the source or destination of the traffic.

  • You can configure geolocation objects for hierarchical firewall policies, global network firewall policies, and regional network firewall policies.

  • To add geolocations to the firewall policy rules, use the two-letter country or region codes as defined in the ISO 3166 alpha-2 country codes.

    For example, if you want to allow incoming traffic only from the US into the network, create an ingress firewall policy rule with the source country code set to US and the action set to allow. Similarly, if you want to allow outbound traffic only to the US, configure an egress firewall policy rule with the destination country code set to US and the action set to allow.

  • Cloud NGFW lets you configure firewall rules for the following territories subject to comprehensive US sanctions:

    Territories Assigned code
    Crimea XC
    So-Called Donetsk People's Republic and Luhansk People's Republic XD

  • If there are any duplicate country codes included in a single firewall rule, only one entry for that country code is retained. The duplicate entry is removed. For example, in the country code list ca,us,us, only ca,us is retained.

  • Google maintains a database with IP addresses and country code mappings. Google Cloud firewalls use this database to map the IP addresses of source and destination traffic to the country code, and then apply the matching firewall policy rule with geolocation objects.

  • Sometimes, IP address assignments and country codes change due to the following conditions:

    Because it takes some time for these changes to be reflected in Google's database, you might see some traffic disruptions and changes in behavior for certain traffic being blocked or allowed.

Use geolocation objects with other firewall policy rule filters

You can use geolocation objects along with other source or destination filters. Depending on the rule direction, the firewall policy rule is applied to the incoming or outgoing traffic that matches the union of all the specified filters.

For information about how geolocation objects work with other source filters in the ingress rules, see Sources for ingress rules in hierarchical firewall policies and Sources for ingress rules in network firewall policies.

For information about how geolocation objects work with other destination filters in the egress rules, see Destinations for egress rules.

Google Threat Intelligence for firewall policy rules

Firewall policy rules let you secure your network by allowing or blocking traffic based on Google Threat Intelligence data. Google Threat Intelligence data includes lists of IP addresses based on the following categories:

  • Tor exit nodes: Tor is open source software that enables anonymous communication. To exclude users who hide their identity, block the IP addresses of Tor exit nodes (endpoints at which traffic exits the Tor network).
  • Known malicious IP addresses: IP addresses that are known to be the origin of web application attacks. To improve your application's security posture, block these IP addresses.
  • Search engines: IP addresses that you can allow to enable site indexing.
  • Public cloud IP address ranges: This category can be either blocked to avoid malicious automated tools from browsing web applications or allowed if your service uses other public clouds. This category is further divided into the following subcategories:
    • IP address ranges used by Amazon Web Services
    • IP address ranges used by Microsoft Azure
    • IP address ranges used by Google Cloud
    • IP address ranges used by Google services

The Google Threat Intelligence data lists can include IPv4 addresses, IPv6 addresses, or both. To configure Google Threat Intelligence in your firewall policy rules, use the predefined Google Threat Intelligence list names based on the category that you want to allow or block. These lists are continually updated, protecting services from new threats without additional configuration steps. The valid list names are as follows.

List name Description
iplist-tor-exit-nodes Matches IP addresses of TOR exit nodes
iplist-known-malicious-ips Matches IP addresses known to attack web applications
iplist-search-engines-crawlers Matches IP addresses of search engine crawlers
iplist-vpn-providers Matches IP addresses that belong to low-reputation VPN providers
iplist-anon-proxies Matches IP addresses that belong to open anonymous proxies
iplist-crypto-miners Matches IP addresses that belong to cryptocurrency mining sites
iplist-public-clouds
  • iplist-public-clouds-aws
  • iplist-public-clouds-azure
  • iplist-public-clouds-gcp
  • iplist-public-clouds-google-services
 Matches IP addresses belonging to public clouds
  • Matches IP address ranges used by Amazon Web Services
  • Matches IP address ranges used by Microsoft Azure
  • Matches IP address ranges used by Google Cloud
  • Matches IP address ranges used by Google services

Use Google Threat Intelligence with other firewall policy rule filters

To define a firewall policy rule with Google Threat Intelligence, follow these guidelines:

  • For egress rules, specify the destination by using one or more destination Google Threat Intelligence lists.

  • For ingress rules, specify the source by using one or more source Google Threat Intelligence lists.

  • You can configure Google Threat Intelligence lists for hierarchical firewall policies, global network firewall policies, and regional network firewall policies.

  • You can use these lists along with other source or destination rule filter components.

    For information about how Google Threat Intelligence lists work with other source filters in the ingress rules, see Sources for ingress rules in hierarchical firewall policies and Sources for ingress rules in network firewall policies.

    For information about how Google Threat Intelligence lists work with other destination filters in the egress rules, see Destinations for egress rules.

  • Firewall logging is done at the rule level. To make it easier for you to debug and analyze the effect of your firewall rules, don't include multiple Google Threat Intelligence lists in a single firewall rule.

  • You can add multiple Google Threat Intelligence lists to a firewall policy rule. Each list name included in the rule is counted as one attribute irrespective of the number of IP addresses or IP address ranges included in that list. For example, if you have included the iplist-tor-exit-nodes, iplist-known-malicious-ips, and iplist-search-engines-crawlers list names in your firewall policy rule, the rule attribute count per firewall policy is increased by three. For more information about the rule attribute count, see Quotas and limits.

Creating exceptions to Google Threat Intelligence lists

If you have rules that apply to Google Threat Intelligence lists, you can use the following techniques to create exception rules applicable to certain IP addresses within a Google Threat Intelligence list:

  • Selective allow-listing: Suppose you have an ingress or egress firewall rule that denies packets from or to a Google Threat Intelligence list. To allow packets from or to a selected IP address within that Google Threat Intelligence list, create a separate higher-priority ingress or egress allow firewall rule that specifies the exception IP address as a source or destination.

  • Selective deny-listing: Suppose you have an ingress or egress firewall rule that allows packets from or to a Google Threat Intelligence list. To deny packets from or to a selected IP address within that Google Threat Intelligence list, create a higher-priority ingress or egress deny firewall rule that specifies the exception IP address as a source or destination.

Address groups for firewall policies

Address groups are a logical collection of either IPv4 address ranges or IPv6 address ranges in CIDR format. You can use address groups to define consistent sources or destinations referenced by many firewall rules. Address groups can be updated without modifying the firewall rules that use them. For more information about address groups, see Address groups for firewall policies.

You can define source and destination address groups for ingress and egress firewall rules respectively.

For information about how source address groups work with other source filters in the ingress rules, see Sources for ingress rules in hierarchical firewall policies and Sources for ingress rules in network firewall policies.

For information about how destination address groups work with other destination filters in the egress rules, see Destinations for egress rules.

FQDN objects

Use fully qualified domain name (FQDN) objects in firewall policy rules to filter incoming or outgoing traffic from or to specific domains.

You can apply firewall policy rules that use FQDN objects to both ingress traffic and egress traffic. Based on the direction of the traffic, the IP addresses associated with the domain names are matched against the source or destination of the traffic.

  • You can configure FQDN objects in firewall policy rules for hierarchical firewall policies, global network firewall policies, and regional network firewall policies.

  • You must specify FQDN objects in standard FQDN syntax

    For more information about domain name formats, see Domain name format.

  • At periodic intervals, Cloud NGFW updates the firewall policy rules that contain FQDN objects with the latest domain name resolution results.

  • The domain names specified in firewall policy rules are resolved into IP addresses based on the VPC name resolution order of Cloud DNS. Cloud DNS notifies the Cloud NGFW if there are any changes in the domain name resolution results, also known as domain name system (DNS) records.

  • If two domain names resolve to the same IP address, the firewall policy rule applies to that IP address, not just one domain. In other words, the FQDN objects are Layer 3 entities.

  • If the FQDN object in the egress firewall policy rule includes a domain that has CNAMEs in the DNS record, you must configure your egress firewall policy rule with all domain names that your VMs can query—including all potential aliases—to ensure reliable firewall rule behavior. If your VMs query CNAMEs that are not configured in the egress firewall policy rule, the policy might not work during the DNS records change.

  • You can also use Compute Engine internal DNS names in your network firewall policy rules. However, make sure that your network is not configured to use an alternative name server in the outbound server policy.

  • If you want to add custom domain names in your network firewall policy rules, you can use Cloud DNS managed zones for domain name resolution. However, make sure that your network is not configured to use an alternative name server in the outbound server policy. For more information about zone management, see Create, modify, and delete zones.

Limitations

The following limitations are applicable to both ingress and egress firewall rules that use FQDN objects:

  • FQDN objects don't support wildcard (*) and top-level (root) domain names. For example, *.example.com. and .org are not supported.

You can use FQDN objects in ingress firewall policy rules. You must take the following limitations into consideration when defining FQDN objects for ingress rules:

  • A domain name can resolve to a maximum of 32 IPv4 addresses and 32 IPv6 addresses. DNS queries that resolve to more than 32 IPv4 and 32 IPv6 addresses are truncated to include just 32 IPv4 or IPv6 addresses of those resolved IP addresses. Therefore, don't include domain names that resolve to more than 32 IPv4 and IPv6 addresses in the ingress firewall policy rules.

  • Some domain name queries have unique answers based on the location of the requesting client. The location from which the firewall policy rule's DNS resolution is performed is the Google Cloud region that contains the VM to which the firewall policy rule applies.

  • Don't use ingress rules that use FQDN objects if the domain name resolution results are highly variable or domain name resolution uses a form of DNS-based load balancing. For example, many Google domain names use a DNS-based load-balancing scheme.

You can use FQDN objects in egress firewall policy rules, but we don't recommend using FQDN objects with DNS A records that have a TTL (time-to-live) of less than 90 seconds.

Use FQDN objects with other firewall policy rule filters

In a firewall policy rule, you can define FQDN objects along with other source or destination filters.

For information about how FQDN objects work with other source filters in the ingress rules, see Sources for ingress rules in hierarchical firewall policies and Sources for ingress rules in network firewall policies.

For information about how FQDN objects work with other destination filters in the egress rules, see Destinations for egress rules.

Domain name format

VPC firewalls support the domain name format as defined in RFC 1035 , RFC 1123 , and RFC 4343.

To add domain names to firewall policy rules, follow these formatting guidelines:

  • The domain name must contain at least two labels described as follows:

    • Each label matches regular expressions that include only these characters: [a-z]([-a-z0-9][a-z0-9])?..
    • Each label is 1-63 characters long.
    • Labels are concatenated with a dot (.).

  • The maximum encoded length of the domain name must not exceed 255 bytes (octets).

  • You can also add an Internationalized Domain Name (IDN) to firewall policy rules.

  • Domain names must be in Unicode or Punycode formats.

  • If you specify an IDN in Unicode format, the Google Cloud firewall converts it to Punycode format before processing. Alternatively, you can use the IDN Converter Tool to obtain Punycode representation of IDN.

  • The Google Cloud firewall does not support equivalent domain names in the same firewall policy rule. After converting the domain name to Punycode, if the two domain names differ at most by a trailing dot, they are considered equivalent.

FQDN exception scenarios

When you use FQDN objects in the firewall policy rules, you might encounter the following exceptions during DNS name resolution:

  • Bad domain name: If you specify one or more domain names that use an invalid format when creating a firewall policy rule, you receive an error. The firewall policy rule cannot be created unless all domain names are formatted properly.

  • Domain name does not exist (NXDOMAIN): If the domain name does not exist, Google Cloud ignores the FQDN object from the firewall policy rule.

  • No IP address resolution: If the domain name does not resolve to any IP address, the FQDN object is ignored.

  • Cloud DNS server is not reachable: If a DNS server is not reachable, the firewall policy rules that use FQDN objects apply only if the previously cached DNS resolution results are available. The rule's FQDN objects are ignored if there are no cached DNS resolution results or the cached DNS results have expired.

What's next