Behavioral differences in firewall rules with FQDNs and IPs defined directly vs as referenced objects

Cloud-gen Firewall (CFW) provides a two main ways of defining policy for domains and IP addresses. Both exhibit different behaviors based on which method is used:

  1. Define them directly into a CFW rule
  2. Reference a URL Category (custom category) object in a CFW rule

CFW behavior with “IP Address or FQDN” defined directly in a rule

An FQDN value is immediately resolved to an IP address at rule activation with the assigned IP entry persisting to the DNS TTL*2 (TTL multiplied by 2). The CFW runs multiple DNS requests until no new IPs show up in 2 sequential responses (a “resolution batch”). CFW runs these batches based on TTL but not sooner than once a minute.

An IP address doesn’t need resolution of course and is active immediately.

Additionally when defined as an FQDN value, this value is then examined in any HTTP and FTP header requests and HTTPS SNIs. Any match on either the IP or header or SNI evaluates the condition to “true” and CFW rule triggers the defined action (“block” for example).

CFW behavior using “URL Categories”

URL category in a CFW rule works by parsing the domain/host value (domain, subdomain etc) or – when an IP address is input directly into this object – the IP value of the custom URL category object as it passes through ZIA in an HTTP/FTP header or HTTPS SNI. It is not pre-resolved to an IP address since it examines the values inside HTTP/FTP and HTTPS protocols.

An important further note that while any custom category can take domains along with the full URL paths, if there is a path portion to the URL then this is ignored by the CFW. Only the domain portions are examined as part of CFW policy. So in the example “”, the portion “path/path.htm” is ignored when the CFW examines HTTP/FTP headers or HTTPS SNIs.

If the same custom category object with a complete URL including a path portion (“”) is referenced in SWG policy then the complete URL is evaluated as one would expect.

One gotcha using APIs for the above

When using the direct method of blocking an IP or FQDN in a CFW rule via an API or even manually, it is important to keep in mind both the sequence of operations resulting in no condition value. A CFW rule without any conditions will match on all conditions and take the resulting rule action which can lead to a “block all” or “allow all” situation.

For example, if a rule says “if IP x or IP y then block” then the conditions of traffic going to either of those two IP addresses needs to be met in order for the block action to fire. If a user or API action deletes the two IP addresses as conditions and then saves this rule then the result will be “if anything then block”. This is a valid default block (or default allow in non-zero trust security situations) rule but one that would have tragic consequences to all allow rules that follow it in the rule order. It is therefore important that programmatic and manual changes to rules does not unintentionally result in this condition.