Palo Alto Networks Knowledgebase: Nested Wildcard(*) in URLs May Severely Affect Performance
Nested Wildcard(*) in URLs May Severely Affect Performance
Created On 09/26/18 13:51 PM - Last Updated 02/07/19 23:47 PM
Commit warning message
The following warning displays during a commit if a block or allow list contains an entry using multiple wildcards:
Warning: Nested wildcard(*) in URLs may severely impact performance. It is recommended to use a single wildcard to cover multiple tokens or a caret(^) to target a single token.
Reason of warning message
The asterisk (*) character is used as a wildcard token in the FQDN and path for custom URL filtering. The Palo Alto Networks firewall accepts multiple wildcard tokens in the field (ex. *.*.domain.com) and processes them appropriately.
However, as the number of wildcard tokens increases, the load on the system CPU increases exponentially (for example, *.*.*.domain.com, or just *.*.domain.com). Therefore, we recommend to avoid Nested asterisk(*) for practical usage.
Below is Wildcard usage and its example
match with one or more subdomains
The asterisk (*) wildcard does not respect the period (.) as a delimiter and will continue as a wildcard until a subdomain, domain or top level domain is matched.
sub1.*.*.com will match sub1.sub2.sub3.com and *.*.sub3.com will match sub1.sub2.sub3.com. However, this should be avoided as a best practice as nested asterisks can create a performance impact on the device.
Instead, as a best practice you can use: sub1.*.com or *.sub3.com. This will match sub1.sub2.sub3.com
match with only one subdomains.
The caret (^) wildcard does respect the period (.) as a delimliter and will stop matching as a wildcard once a match has occurred.
are able to match with sub1.sub2.sub3.com
Hence, ^.sub3.com and sub1.^.com are not able to match with sub1.sub2.sub3.com, since "^" caret only matches with one subdomain.
If you'd like to replace "*" with "^", the following replacements are required:
x.*.net is partically covered by the following:
Nested carets has a practical limit of 9 carets for the same DP resource usage reason above.
Same limitation for Path
This limitation is applied to the pattern matching on path after FQDN. (i.e. http://<FQDN>/<path>), though we don't throw the commit warning message above for path.
Practical limit for nested asterisk in path is 2. But we highly recommend to use minimun number of asterisk for better DP utilization (CPU load/ Memory usage).
Currently we have limitation that asterisk and caret should not be used in the same configuration. As mentioned above, caret cannot be fully replaced with asterisk. Therefore replacing nested asterisks to single asterisk is considered best solution for most of customers practically.
"2" for nested asterisk in path and "9" for nested caret are practical number we suggest. Please consider to use lowest number as possible for better DP load (i.e. lower platform).