Speed of URL
The system cannot filter URLs before:
A monitored connection is established between a client and server.
The system identifies the HTTP or HTTPS application in the session.
The system identifies the requested URL (for encrypted sessions, from either the ClientHello message or the server certificate).
This identification should occur within 3 to 5 packets, or after
the server certificate exchange in the SSL handshake if the traffic is
If early traffic
matches all other rule conditions but identification is incomplete, the system
allows the packet to pass and the connection to be established (or the SSL
handshake to complete). After the system completes its identification, the
system applies the appropriate rule action to the remaining session traffic.
For access control, these passed packets are inspected by the
access control policy’s
intrusion policy—not the
default action intrusion policy nor the almost-matched
rule’s intrusion policy.
Before Application and Other Rules
For the most
effective URL matching, place rules that include URL conditions before other
rules, particularly if the URL rules are block rules and the other rules meet
both of the following criteria:
If the system does not know the category and reputation of a URL, browsing to that website does not match rules with category and reputation-based URL conditions. You cannot assign categories and reputations to URLs manually.
When you build a URL rule, you first choose the category you want to match. If you explicitly choose Uncategorized URLs, you cannot further constrain by reputation, because uncategorized URLs do not have reputations.
When manually filtering specific URLs, carefully consider other
traffic that might be affected. To determine whether network traffic matches a
URL condition, the system performs a simple substring match. If the requested
URL matches any part of the string, the URLs are considered to match.
for Encrypted Web Traffic
When performing URL filtering on encrypted web traffic, the
Disregards the encryption protocol; a rule matches both HTTPS
and HTTP traffic if the rule has a URL condition but not an application
condition that specifies the protocol.
Does not use
URL lists. You must use URL objects and groups instead.
Matches HTTPS traffic based on the subject common name in the
public key certificate used to encrypt the traffic, and disregards subdomains
within the subject common name.
display an HTTP response page for encrypted connections blocked by access
control rules (or any other configuration); see
Limitations to HTTP Response Pages.
Parameters in URLs
The system does not use search query parameters in the URL to
match URL conditions. For example, consider a scenario where you block all
shopping traffic. In that case, using a web search to search for amazon.com is
not blocked, but browsing to amazon.com is.
Memory Limitations for Selected Device Models
Due to memory limitations, some device models perform most URL filtering with a smaller, less granular, set of categories and reputations. For example, even if a parent URL's subsites have different URL categories and reputations, some devices may only store the parent URL's data. For web traffic handled by these devices, the system may perform cloud lookups to determine category and reputation for sites not in the local database.
Lower-memory devices include:
ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, and ASA 5516-X
ASA 5512-X, ASA 5515-X, and ASA 5525-X
If you are using NGIPSv, see the Firepower System Virtual
Installation Guide for information on allocating the correct amount of memory to perform category and reputation-based URL filtering.