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 in hierarchical firewall policies

You can use the following sources for ingress rules in hierarchical firewall policies:

  • 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 address ranges: A list of IPv4 addresses in CIDR format.

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

  • Geolocations: A list of one or more source geographic locations specified as two-letter country or region codes to filter incoming traffic. For more information, see Geolocation objects.

  • Source address groups: A list of one or more source address groups consisting of either IPv4 CIDRs or IPv6 CIDRs. For more information about address groups, see Address groups for firewall policies.

  • Source domain names: A list of one or more source domain names. For more information about domain names, see Domain name for firewall policies.

  • A valid source combination: You can specify various combinations of the preceding sources in the ingress rules. The effective source set is a union of these combinations.

    When you specify a combination of sources in an ingress rule, the rule is applied to a packet that matches at least one of the source parameter criteria.

    Follow these guidelines when defining source combinations for a rule:

    • Don't use both source IPv4 address ranges and source IPv6 address ranges in the same rule.
    • Don't use a source address group that contains IPv4 CIDRs with another source address group that contains IPv6 CIDRs in the same rule.
    • Don't use source IPv4 address ranges and a source address group that contains IPv6 CIDRs in the same rule.
    • Don't use source IPv6 address ranges and a source address group that contains IPv4 CIDRs in the same rule.

Sources for ingress rules in network firewall policies

You can use the following sources for ingress rules in global and regional network firewall policies:

  • 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 address ranges: A list of IPv4 addresses in CIDR format.

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

  • Geolocations: A list of one or more source geographic locations specified as two-letter country or region codes to filter incoming traffic. For more information, see Geolocation objects.

  • Source address groups: A list of one or more source address groups consisting of either IPv4 CIDRs or IPv6 CIDRs. For more information about address groups, see Address groups for firewall policies.

  • Source domain names: A list of one or more source domain names. For more information about domain names, see Domain name for firewall policies.

  • Source secure tags: One or more secure tags that identify network interfaces of VM instances in the same VPC network to which the network firewall policy applies, or in a VPC network connected to the firewall policy's network by using VPC Network Peering. Additionally, if the policy is a regional network firewall policy, the VM instances must be in the same region as the policy.

  • A valid source combination: You can specify various combinations of the preceding sources in the ingress rules. The effective source set is a union of these combinations.

    When you specify a combination of sources in an ingress rule, the rule is applied to a packet that matches at least one of the source parameter criteria.

    Follow these guidelines when defining source combinations for a rule:

    • Don't use both source IPv4 address ranges and source IPv6 address ranges in the same rule.
    • Don't use a source address group that contains IPv4 CIDRs with another source address group that contains IPv6 CIDRs in the same rule.
    • Don't use source IPv4 address ranges and a source address group that contains IPv6 CIDRs in the same rule.
    • Don't use source IPv6 address ranges and a source address group that contains IPv4 CIDRs in the same rule.

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. The secure tag can only be bound to a VM if that VM has a network interface in the same VPC network to which the secure tag is associated.

Ingress rules in a global and regional network policies apply to packets emitted from the network interface of a VM bound to the secure tag, where the VM meets one of the following criteria:

  • The VM's network interface uses the same VPC network as the firewall policy.

  • The VM's network interface uses a VPC network connected to the firewall policy's VPC network by using VPC Network Peering.

In addition to specifying a network interface, the following source IP addresses are resolved:

  • 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, the network interface bound to a secure tag is resolved to the same IP version as the destination IP range.

No other packet source IP addresses 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 whose sources include alias IP address ranges or external IPv4 addresses, use source IPv4 address ranges.

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

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

  • 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 address ranges: A list of IPv4 addresses in CIDR format.

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

  • Geolocations: A list of one or more destination geographic locations specified as two-letter country or region codes to filter incoming traffic. For more information, see Geolocation objects.

  • Destination address groups: A list of one or more destination address groups consisting of either IPv4 CIDRs or IPv6 CIDRs. For more information about address groups, see Address groups for firewall policies.

  • Destination domain names: A list of one or more destination domain names. For more information about domain names, see Domain name for firewall policies.

  • A valid destination combination: You can specify various combinations of the preceding destinations in the ingress rules. The effective destination set is a union of these combinations.

    When you specify a combination of destinations in an egress rule, the rule is applied to a packet that matches at least one of the destination parameter criteria.

    Follow these guidelines when defining destination combinations for a rule:

    • Don't use both destination IPv4 address ranges and destination IPv6 address ranges in the same rule.
    • Don't use a destination address group that contains IPv4 CIDRs with another destination address group that contains IPv6 CIDRs in the same rule.
    • Don't use destination IPv4 address ranges and a destination address group that contains IPv6 CIDRs in the same rule.
    • Don't use destination IPv6 address ranges and a destination address group that contains IPv4 CIDRs in the same rule.

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 Next Generation Firewall 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.

Threat Intelligence for firewall policy rules

Firewall policy rules let you secure your network by allowing or blocking traffic based on Threat Intelligence data. 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 Threat Intelligence data lists can include IPv4 addresses, IPv6 addresses, or both. To configure Threat Intelligence in your firewall policy rules, use the predefined 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 Threat Intelligence with other firewall policy rule filters

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

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

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

  • You can configure 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 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 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 Threat Intelligence lists in a single firewall rule.

  • You can add multiple 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 Threat Intelligence lists

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

  • Selective allow-listing: Suppose you have an ingress or egress firewall rule that denies packets from or to a Threat Intelligence list. To allow packets from or to a selected IP address within that 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 Threat Intelligence list. To deny packets from or to a selected IP address within that 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