Support Center > Search Results > SecureKnowledge Details
Latency on HTTPS traffic when using URL Filtering Technical Level
Symptoms
  • High latency for HTTPS traffic when using URL Filtering.
  • Web Categorization mode is set to Hold. If you set it to background then the latency disappears.
  • All categorization is failing due to "could not connect to cws.checkpoint.com".
  • Fail-open causes high latency. Fail-close causes all web traffic to fail.
  • Running: "curl_cli cws.checkpoint.com" on the Security Gateway shows that the domain can be resolved successfully.
  • When reviewing the Security Gateway's DNS activity in packet captures, there is a mixture of successful DNS resolutions and DNS replies stating "no such name A cws.checkpoint.com".
  • Running: rad_admin install under RAD debugs (sk92743) will show the following output in rad.elg:
    Sock_Input: got a UDP packet
    Sock_Input: ParseResponce result is r_name_error

    CRadHttpRequest::getLocation: [INFO] enter to ...
    CRadHttpRequest::getLocation: [INFO] Host or Port are zero, trying to retrieve them again
    CRadFetcher::fetch: [INFO] IPv4:0
    CRadFetcher::fetch: [WARN] Empty host. The resolution failed or not completed yet...
Cause

RAD resolves cws.checkpoint.com on policy installation and holds the IP address for categorization.

If the first DNS reply that the RAD daemon receives when querying cws.checkpoint.com is "no such name A cws.checkpoint.com", it considers this a failure and ignores further DNS replies even if the latter were successful. As a result, future URL categorization attempts will fail because RAD does not have an IP address registered for cws.checkpoint.com.

 

Note: RAD will query all DNS servers in /etc/resolv.conf. This can include other DNS servers that were not configured in clish. Doing packet captures only for the DNS servers configured in clish or in the webUI may be misleading.


Solution
Note: To view this solution you need to Sign In .