This page describes the components of firewall rules that you create in oneof the followingfirewall policiesthat apply to aregular VPCnetwork:

• Hierarchical firewall policies
• Global network firewall policies
• Regional network firewall policies

For details about firewall rules and RDMA VPC networks, seeCloud NGFW for RoCE VPCnetworks.

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 sourcesto Google Cloud targets. Ingress rules apply to inbound packets that arrive onthe following types of targets:

• Network interfaces of virtual machine (VM) instances
• Managed Envoy proxies that power internal Application Load Balancers and internal proxy Network Load Balancers

An ingress rule with adeny action protects targets by blocking incomingconnections to them. A higher priority rule might allow incoming connections. Anautomatically created default network includes somepre-populatedVPC firewallrules, which allow ingress forcertain types of traffic.

Egress rules

Egress direction refers to the outbound traffic sent from a target VM networkinterface to a destination.

An egress rule with anallow action lets an instance send traffic to thedestinations specified in the rule. Egress can be denied by higher prioritydeny firewall rules. Google Cloud alsoblocks orlimits certain kinds of traffic.

Firewall policy rule components

When you create afirewall policy rule, you specify the components thatdefine what the rule does. In addition to the direction, you can specify source,destination, and Layer 4 characteristics such as protocol and destination port(if the protocol uses ports).

Priority

The priority of a rule in a firewall policy is an integer from 0 to2,147,483,547, inclusive. Lower integers indicate higher priorities. Thepriority of a rule in a firewall policy is similar to thepriority of aVPC firewallrule, with thefollowing 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 uniqueidentifier. Rules in firewall policies don't use names for identification.
• The priority of a rule in a firewall policy defines the evaluation orderwithin the firewall policy itself. VPC firewall rules andrules in hierarchical firewall policies, global network firewall policies,and regional network firewall policies are evaluated as described inApplyfirewall policies and rules to a network.

Action on match

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

Enforcement

You can choose whether a firewall policy rule isenforced by setting its stateto enabled or disabled. You set the enforcement state when you create a rule orwhen you update a rule.

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

Protocols and ports

Similar to VPC firewall rules, you must specify one or moreprotocol and port constraints when you create a rule. When specifying TCP or UDPin a rule, you can specify the protocol, the protocol and a destination port, orthe protocol and a destination port range; you cannot specify only a port orport range. Also, you can only specify destination ports. Rules based on sourceports aren't supported.

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

Many protocols use the same name and number in both IPv4 and IPv6, but someprotocols, such as ICMP, don't. To specify IPv4 ICMP, useicmp or protocolnumber1. To specify IPv6 ICMP, use protocol number58.

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

The IPv6 Hop-by-Hop protocol isn't supported in firewall rules.

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

Logging

Logging for firewall policy rules works the same as for VPCVPC firewall rules logging except for the following:

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

• Logs for firewall policy rules include atarget_resource field thatidentifies the VPC networks to which the rule applies.

• Logging can only be enabled forallow,deny, andapply_security_profile_group rules; logging cannot be enabled forgoto_nextrules.

Target, source, destination

Target, source, and destination parameters work together to determine the scope of a firewall rule.

• Target parameters: identify the resources that the firewall rule appliesto.

• Source and destination parameters: define the traffic criteria. Youcan specify both for ingress and egress rules. Valid options for source anddestination parameters depend on the target parameters and the direction ofthe firewall rule.

Targets

Thetarget type parameter and one or moretarget parameters define thetargets of a firewall rule. These targets of a firewall rule are the resourcesthat the firewall rule protects.

• If the target type is omitted or is set toINSTANCES, the firewall ruleapplies to the network interfaces of Compute Engine instances, includingGoogle Kubernetes Engine nodes and App Engine flexible environment instances.Both ingress and egress rules are supported.

  To specify which VM network interfaces the firewall rule applies to, usetarget parameters:

  • If you omit all target parameters, the firewall rule applies to thebroadest instance targets.

  • For target parameter and target parameter combination details, seeSpecific targets andSpecific targetcombinations.

• If the target type is set toINTERNAL_MANAGED_LB(Preview), the firewall rule applies tothe managed Envoy proxies used by internal Application Load Balancers and internal proxy Network Load Balancers.Only ingress rules are supported.

  • If you omit thetarget forwarding rules parameter, the firewall ruleapplies to thebroadest load balancer targets.

  • To restrict the firewall rule to a single load balancer, use the targetforwarding rules parameter. For more information, seeSpecifictargets.

Broadest instance targets

The broadest instance targets depend on the firewall policy type:

• Broadest instance targets for a rule in a hierarchical firewall policy:all VM network interfaces in a subnet in any region of anyVPC network that's located in a project under theResource Manager node (folder or organization) associated with the hierarchicalfirewall policy.

• Broadest instance targets for a rule in a global network firewallpolicy: all VM network interfaces in a subnet in any region of theVPC network that's associated with the global networkfirewall policy.

• Broadest instance targets for a rule in regional network firewallpolicy: all VM network interfaces in a subnet within the region andVPC network that are associated with the regional networkfirewall policy.

Broadest load balancer targets

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Regional network firewall policies are the only policies whose rules supportload balancer targets. The broadest load balancer targets are the forwardingrules for internal Application Load Balancers and internal proxy Network Load Balancers in the policy's region andassociated VPC network.

Specific targets

The following table lists the target parameters, the firewall policies thatsupport rules with each parameter, and the supported rule target types. If youdon't specify a target parameter, the rule uses either thebroadest instancetargets orbroadest load balancertargets, based on the rule's target type. Thecheckmark indicates that the parameter issupported, and thesymbol indicates that theparameter isn't supported.

Specific target combinations

Rules that support thetarget-resources parameter can combine it with anothertarget parameter to create a target parameter combination. The following table lists supported target parameter combinations, the firewallpolicies that support rules with each parameter, and the supported rule targettypes. If you don't specify a target parameter, the rule uses either thebroadest instance targets orbroadest load balancer targets, based on the rule'starget type.

Thecheckmark indicates that the parameter issupported, and thesymbol indicates that theparameter isn't supported.

Target forwarding rules format

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

When a firewall rule's target type is set toINTERNAL_MANAGED_LB(Preview), the target forwarding rulesparameter accepts values in the following formats:

• For regional internal Application Load Balancers and regional internal proxy Network Load Balancers:

  • https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME
  • projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME

• For cross-region internal Application Load Balancers and cross-region internal proxy Network Load Balancers:

  • https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_NAME
  • projects/PROJECT_ID/global/forwardingRules/FORWARDING_RULE_NAME

Targets and IP addresses for ingress rules

When a firewall rule target type is either omitted or set toINSTANCES, therule applies to packets that are routed to network interfaces of target VMs.

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

• If the ingress firewall rule doesnot include a destination IP addressrange, the packet's destination must match one of the following IPaddresses of each target VM:

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

  • Any configuredalias IP address ranges on theinstance's NIC.

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

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

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

  • An internal or external IP address associated with a forwarding ruleused for protocol forwarding, where the instance is referenced by atarget instance.

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

  • An IP address within the destination range of a custom static route thatuses an internal passthrough Network Load Balancer (next-hop-ilb) as a next hop if the VM is abackend for that load balancer.

When a firewall rule's target type is set toINTERNAL_MANAGED_LB(Preview), the rule filters packets routed tothe managed Envoy proxies associated with internal Application Load Balancers andinternal proxy Network Load Balancers. When using destination IP ranges in an ingress rule, makesure that the range includes the relevant load balancer forwarding rule IPaddress.

Targets and IP addresses for egress rules

When a firewall rule target type is either omitted or set toINSTANCES, therule applies to packets that are emitted by network interfaces of target VMs.

• If the target VM hasIP forwardingdisabled (default), the VM can only 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 assignedto the NIC.

  • An internal or external IP address associated with a forwarding rule,for pass-through load balancing or protocol forwarding. This is valid ifthe instance is a backend for an internal passthrough Network Load Balancer, an external passthrough Network Load Balancer, or isreferenced by a target instance.

  If the egress firewall ruleincludes source IP address ranges, the targetVMs are still limited to the source IP addresses mentioned previously, buta source parameter can be used to refine the sources. Use of a sourceparameter without enabling IP forwardingnever expands the set of possiblepacket source addresses.

  If the egress firewall rule doesnot include a source IP address range,all the source IP addresses mentioned previously are permitted.

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

Sources

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

Sources for ingress rules

This table lists the source parameters for ingress rules, the firewall policiesthat support each parameter, and the rule target types that are compatible witheach parameter. You must specify at least one source parameter. Thecheckmark indicates that the parameter issupported, and thesymbol indicates that theparameter isn't supported.

Ingress rule source combinations

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

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

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

• If the source combination doesnot include a source network type, packetsmatch the ingress rule if they match at least one source parameter in thesource combination.

• If the source combination includes a source network type, packetsmatch the ingress rule if they match the source network typeandat least one of the other source parameters in the source combination.

How source secure tags imply packet sources

An ingress firewall rule can use source secure tag values when its target typeis omitted or set toINSTANCES. Secure tag values identify network interfaces,not packet characteristics like IP addresses.

Packets sent from a network interface of a VM instance match an ingress rulethat uses a source secure tag value according to the following rules:

• If the ingress rule is in a regional network policy, the VM instance must belocated in a zone of the same region as the regional network firewallpolicy. Otherwise, the VM instance can be located in any zone.

• The VM instance must be associated with the same secure tag value that isused as a source secure tag in an ingress firewall rule.

• The secure tag value associated with the VM instance and used by the ingressfirewall rule must come from a tag key whosepurpose-data attributeidentifies at least one VPC network that contains anetwork interface of the VM instance:

  • If the tag key's purpose data specifies a single VPCnetwork, ingress firewall rules that use the source secure tag valueapply to the network interfaces of the VM instance that are in thatVPC network.

  • If the tag key's purpose data specifies the organization, ingressfirewall rules that use the source secure tag value apply to the networkinterfaces of the VM instance that are in any VPC networkof the organization.

• The identified VM network interface must meet one of the following criteria:

  • The VM network interface is in the same VPC network as theVPC network to which the firewall policy applies.
  • The VM network interface is in a VPC network that'sconnected, using VPC Network Peering, to the VPC networkto which the firewall policy applies.

For more information about secure tags for firewalls, seeSpecifications.

Sources for egress rules

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

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

• Source IPv4 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 anddestinationparameters in the egress rule, then the destinationparameters 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 sourceparameter and anFQDN object in thedestination parameter. If the FQDN resolves into both IPv4 and IPv6addresses, only the resolved IPv4 address is used during rule enforcement.

Destinations

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

Destinations for ingress rules

You can use the following destinations for ingress firewall rules in bothhierarchical and network firewall policies:

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

• Destination IPv4 address ranges: a list of IPv4 addresses in CIDRformat.

• Destination IPv6 address ranges: a list of IPv6 addresses in CIDRformat.

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 ingressrule, then the source parameters are resolved into the same IP version asthe destination IP version. To learn more about how to define a source foringress rules, seeSources for ingress rules in hierarchical firewallpolicies andSources for ingress rules in networkfirewall policies.

  For example, in an ingress rule, you have an IPv6 address range in thedestination parameter and ageolocation country codein the source parameter. During rule enforcement, only the mapped IPv6address is used for the specified source country code.

Destinations for egress rules

This table lists the destination parameters for egress rules, the firewallpolicies that support each parameter, and the rule target types that arecompatible with each parameter. You must specify at least one destinationparameter. Thecheckmark indicates that theparameter is supported, and thesymbol indicatesthat the parameter isn't supported.

Egress rule destination combinations

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

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

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

• If the destination combination doesnot include a destination network type,packets match the egress rule if they match at least one destination parameterin the destination combination.

• If the destination combination includes a destination network type, packetsmatch the egress rule if they match the destination network typeandat least one of the other destination parameters in the destination combination.

Network types

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

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

Network types

The following table shows how the four network types can be used in firewall rules.

The internet and non-internet network types are mutually exclusive. The VPCnetworks and intra-VPC network types are subsets of the non-internetnetwork type.

Internet network type

Theinternet network type (INTERNET) can be used as part of a sourcecombination of an ingress rule or as part of a destination combination of anegress rule:

• For an ingress rule, specify the internet type source and at least one othersource parameter, except for a secure tag source. Packets match the ingressrule if they match at least one of the other source parametersandinternetnetwork type criteria for ingresspackets.

• For an egress rule, specify the internet type destination and at least oneother destination parameter. Packets match the egress rule if they match atleast one of the other destination parametersandinternet network typecriteria for egresspackets.

Non-internet network type

Thenon-internet network type (NON-INTERNET) can be used as part of asource combination of an ingress rule or as part of a destination combinationof an egress rule:

• For an ingress rule, specify the non-internet type source and at least oneother source parameter, except for a secure geolocations or source Google Threat Intelligencelist. Packets match the ingress rule if they match at least one of the othersource parametersandnon-internet network type criteria for ingresspackets.

• For an egress rule, specify the non-internet type destination and at leastone other destination parameter. Packets match the egress rule if they match atleast one of the other destination parametersandnon-internetnetwork type criteria for egresspackets.

VPC networks type

TheVPC networks network type (VPC_NETWORKS) can only beused as part of a source combination of an ingress rule. To use theVPC networks type as part of a source combination of an ingressrule, 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 networklist.
   • A VPC network must exist before you can add it to the sourcenetwork 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'tneed to be connected to each other. Each VPC network can belocated in any project.
   • If a VPC network is deleted after it is added to the sourcenetwork list, the reference to the deleted network remains in the list.Cloud NGFW ignores deleted VPC networks whenenforcing an ingress rule. If all VPC networks in the sourcenetwork list are deleted, ingress rules that rely on the list are ineffectivebecause they don't match any packets.

2. You must specify at least one other source parameter, except for a Google Threat Intelligence list source or geolocation source.

Packets match the ingress rule if they match at least one of the other sourceparametersandcriteria for VPC networkstype.

Intra-VPC network type

Theintra-VPC networks network type (INTRA_VPC) can only beused as part of a source combination of an ingress rule. To use theintra-VPC networks type as part of a source combination of aningress rule, you must specify at least one other source parameter, exceptfor a Google Threat Intelligence listsource or geolocation source.

Packets match the ingress rule if they match at least one of the other sourceparametersandcriteria for intra-VPC networkstype.

Geolocation objects

Use geolocation objects in firewall policy rules to filter external IPv4 andexternal 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 thecountry 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 countryor region codes as defined in theISO 3166 alpha-2 countrycodes.

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

• Cloud NGFW lets you configure firewall rules for the followingterritories 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 isremoved. For example, in the country code listca,us,us, onlyca,us isretained.

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

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

  • IP address movement across geographic locations
  • Updates to theISO 3166 alpha-2 countrycodesstandard

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

  Note: Google's database is maintained based on input from various trusted sources. Google doesn't support customizations to this database based on individual customer requests.

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 theincoming or outgoing traffic that matches the union of all the specifiedfilters.

For information about how geolocation objects work with other source filters inthe ingress rules, seeSources for ingress rules in hierarchical firewallpolicies andSources for ingress rules in network firewallpolicies.

For information about how geolocation objects work with other destinationfilters in the egress rules, seeDestinations for egressrules.

Google Threat Intelligence for firewall policy rules

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

• Tor exit nodes:Tor is open sourcesoftware that enables anonymous communication. To exclude users who hidetheir identity, block the IP addresses of Tor exit nodes (endpoints at whichtraffic exits the Tor network).
• Known malicious IP addresses: IP addresses that are known to be theorigin of web application attacks. To improve your application's securityposture, 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 toavoid malicious automated tools from browsing web applications or allowed ifyour service uses other public clouds. This category is further divided intothe 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, orboth. To configure Google Threat Intelligence in your firewall policy rules, use thepredefined Google Threat Intelligence list names based on the category that you want toallow or block. These lists are continually updated, protecting services fromnew threats without additional configuration steps. The valid list names are asfollows.

Use Google Threat Intelligence with other firewall policy rule filters

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

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

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

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

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

  For information about how Google Threat Intelligence lists work with other sourcefilters in the ingress rules, seeSources for ingress rules in hierarchicalfirewall policies andSources for ingress rules innetwork firewall policies.

  For information about how Google Threat Intelligence lists work with otherdestination filters in the egress rules, seeDestinations for egressrules.

• Firewall logging is done at therule level. To make it easier for you to debug and analyze the effect ofyour firewall rules, don't include multiple Google Threat Intelligence lists in asingle 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 regardlessof the number of IP addresses or IP address ranges included in that list.For example, if you have included theiplist-tor-exit-nodes,iplist-known-malicious-ips, andiplist-search-engines-crawlers listnames in your firewall policy rule, the rule attribute count per firewallpolicy is increased by three. For more information about the rule attributecount, seeRule attribute count details.

Creating exceptions to Google Threat Intelligence lists

If you have rules that apply to Google Threat Intelligence lists, you can use thefollowing techniques to create exception rules that are applicable to certain IPaddresses within a Google Threat Intelligence list:

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

• Selective deny firewall rule: suppose you have an ingress or egress firewallrule that allows packets from or to a Google Threat Intelligence list. To denypackets from or to a selected IP address within that Google Threat Intelligencelist, create a higher-priority ingress or egress deny firewall rule thatspecifies 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 IPv6address ranges in CIDR format. You can use address groups to define consistentsources or destinations referenced by many firewall rules. Address groups can beupdated without modifying the firewall rules that use them. For more informationabout address groups, seeAddress groups for firewallpolicies.

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

For information about how source address groups work with other source filtersin the ingress rules, seeSources for ingress rules in hierarchical firewallpolicies andSources for ingress rules in network firewallpolicies.

For information about how destination address groups work with other destinationfilters in the egress rules, seeDestinations for egressrules.

FQDN objects

Fully qualified domain name (FQDN) objects contain domain names that you specifyin thedomain name format. You can use FQDN objectsas sources for ingress rules or as destinations for egress rules in ahierarchical firewall policy, global network firewall policy, or regionalnetwork firewall policy.

You can combine FQDNs with other parameters. For details about sourceparameter combinations in ingress rules, seeSources for ingress rules. For details about destination parametercombinations in egress rules, seeDestinations for egress rules.

FQDN objects supportCloud DNS response policies,VPC network-scoped managed private zones,Compute Engine internal DNS names, andpublic DNS zones. This support applies as long as the VPCnetwork doesn't haveanoutbound server policythat specifies analternative name server.For more information, seeVPC network resolution order.

Map FQDN objects to IP addresses

Cloud NGFW periodically resolves FQDN objects toIP addresses. Cloud NGFW follows the Cloud DNSVPC name resolution order inthe VPC network that contains the firewall rule's targets.

Cloud NGFW uses the following behavior for IP address resolution:

• Support CNAME chasing. Cloud NGFW uses Cloud DNSCNAME chasing if the answer to a FQDNobject query is a CNAME record.

• Program IP addresses. Cloud NGFW uses the resolvedIP addresses when it programs the firewall rules that use FQDNobjects. Each FQDN object can be mapped to a maximum of 32 IPv4addresses and 32 IPv6 addresses.

  If the DNS answer for an FQDN object query resolves to more than 32IPv4 addresses or more than 32 IPv6 addresses, Cloud NGFWlimits the programmed IP addresses in the firewall rules to thefirst 32 IPv4 addresses and the first 32 IPv6 addresses.

• Ignore FQDN objects. If Cloud NGFW cannot resolve an FQDNobject to an IP address, it ignores the FQDN object. In the followingsituations, Cloud NGFW ignores an FQDN object:

  • WhenNXDOMAIN answers are received.NXDOMAIN answers are explicitanswers from a name server indicating that no DNS record for theFQDN object query exists.

  • When no IP address exists in an answer. In this situation, an FQDNobject query doesn't result in an answer with an IP address thatCloud NGFW can use to program a firewall rule.

  • When Cloud DNS server is unreachable. Cloud NGFWignores FQDN objects if a DNS server that provides the answer isunreachable.

  When an FQDN object is ignored, Cloud NGFW programs theremaining portions of a firewall rule, if possible.

Considerations for FQDN objects

Consider the following for FQDN objects:

1. Because FQDN objects map to and are programmed as IP addresses,Cloud NGFW uses the following behavior when two or moreFQDN objects map to the same IP address. Assume you have the followingtwo firewall rules that apply to the same target:

   • Rule 1: priority100, ingress allow from source FQDNexample1.com
   • Rule 2: priority200, ingress allow from source FQDNexample2.com

   If bothexample1.com andexample2.com resolve to the same IP address,ingress packets from bothexample1.com andexample2.com matchthe first firewall rule because this rule has a higher priority.

2. Considerations for using FQDN objects include the following:

   • A DNS query can have unique answers based on the location of therequesting client.

   • DNS answers can be highly variable when a DNS-based load balancingsystem is involved.

   • A DNS answer might contain more than 32 IPv4 addresses.

   • A DNS answer might contain more than 32 IPv6 addresses.

   In the preceding situations, because Cloud NGFW performs DNS queriesin each region that contains the VM network interface to which thefirewall rule applies, the programmed IP addresses in firewall rules don'tcontain all possible IP addresses associated with the FQDN.

   Most Google domain names, such asgoogleapis.com, are subject to one ormore of these situations. Use IP addresses oraddress groups instead.

3. Avoid using FQDN objects with DNSA records that have atime to live (TTL) of less than 90 seconds.

Format domain names

FQDN objects must follow thestandard FQDN format.This format is definedinRFC 1035,RFC 1123, andRFC 4343. Cloud NGFWrejects FQDN objects that include a domain name that doesn't meet all of thefollowing formatting rules:

• Each FQDN object must be a domain name with at least two labels:

  • Each label must match a regular expression that includes only thesecharacters:[a-z]([-a-z0-9][a-z0-9])?..
  • Each label must have a length of 1-63 characters.
  • Labels must be concatenated with a dot (.).

  Consequently, FQDN objects don't support wildcard characters (*) ortop-level (or root) domain names, such as*.example.com. and.org,because these include only a single label.

• FQDN objects supportInternationalized Domain Names (IDNs). Youcan supply an IDN in either Unicode orPunycode format. Consider the following:

  • If you specify an IDN in Unicode format, Cloud NGFWconverts it to Punycode format before processing.

  • You can use theIDN converter to create the Punycode representation of an IDN.

  • The character limit of 1-63 per label applies to IDNs afterconversion to Punycode format.

• The encoded length of a fully qualified domain name (FQDN) cannot exceed 255 bytes (octets).

Cloud NGFW doesn't support equivalent domain names in the same firewallrule. For example, if the two domain names (or Punycode representations of IDNs) differ at mostby a terminal dot (.), Cloud NGFW considers them equivalent.

What's next

• Hierarchical firewall policies
• Global network firewall policies
• Regional network firewall policies