Create a Post
Showing results for 
Search instead for 
Did you mean: 

rad daemon cause problem with Web browsing


In the end of May we upgraded our GW to R80.40 and patch it with JHF 48. We have all the blades enabled. Immediately we faced a problem with slow Internet browsing. We though that there was a problem with the ISP but that was not the case. The following log is observed every 2-3 minutes.


Also logs similar to this are also observed


Today we disabled Antibot and Antivirus blades and browsing works like a charm.

There are a lot of logs under /opt/CPsuite-R80.40/fw1/log/rad_events on the gateway saying something like rad_curl_task.cpp:103] CRadCurlTask::run: [ERROR] handle: 0x92dc768 curl_easy_perform() failed: Timeout was reached

GW is directly connected to Internet, no proxy

There is another thread with the same issue but still no fix is provided, except one with a radical decision to change the vendor.

Let me know if you faced the same issue and how to proceed.

Labels (1)
Tags (1)
0 Kudos
6 Replies

Hi @MartinTzvetanov ,

It is required to check connectivity to the cloud not related to RAD.

You can do it with:





Used For (Version)

Verifying Connectivity (Run command listed below. You will get a response if connectivity is OK.)


Security Gateway,
Security Management Server,
SMB Gateways

Social Media Widget Detection (R75 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v

URL Filtering Cloud Categorization (R75.20 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v

Virus Detection (R75.40 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v

Bot Detection (R75.40 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v


Anyway, I suggest opening a support ticket for a deeper investigation. 

0 Kudos

Hello Martin,

we have the same problems. But also have other problems. Are you using VSX? Does the problem stop if you cpstop the standby member?

We see this problem after a failover and can stop it by turning off the standby member. Also waiting some time (last time 15 minutes when nearly nobody was browsing) does seem to solve the issue.

Also we have the problem that the standby member cannot reach the internet. This seems to have something to do with this problem.

Have you solved your problem?


Best regards,


0 Kudos

Hi Jan,


This is our office firewall - it's just a gateway, no VSX. The only problem we observe (we are 7 people at the office) slow browsing to some sites (not any particular site) just some random site. And trying to dig in the logs it pops up the RAD that is trying to categorize the resource but fails. Checking the connection to the CP cloud is like shooting flies in the air. 

0 Kudos

I assume when you say "random" sites don't work that they are new ones that do not currently have a categorization cached locally from the ThreatCloud.  If you go to the same website over and over from different users/workstations does it have problems?  My guess is no.  Your code level should have the new rad multi-threading present (sk163793: How to scale up requests/responses RAD handling rates) so I doubt it is a capacity issue.  Double check all the DNS servers defined in /etc/resolv.conf with nslookup, are ALL defined DNS servers reachable and responding quickly?  If not that can cause some problematic rad process behavior. 

Any rad core dumps in /var/log/dump/usermode?

You can also have rad capture statistics about its behavior and interaction with the ThreatCloud, check out the rad_admin stats on command and the Advanced...RAD screen of cpview.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at
0 Kudos

Hi Timothy,

Last time I observed such behavior (maybe a month later) it was with . I played with this site for 2-3 weeks and the slow browsing was observed when clicking on the next section of the site, so it's not a new site.  Around this time my colleagues also observed slow browsing on some sites and we stopped anti-malware and anti-bot blades and it worked smooth.  In /etc/resolv.conf we have only our internal dns configured. Can't tell if there were a problem with the connection with external  dns servers. We didn't have enough time to go deep in this problem.

0 Kudos

I've had the same issue with R80.40 and VSX. First RAD errors where users would complain Internet was slow, then no HTTP or HTTPS connectivity anymore until I disabled the TP blades.

Actually, I wanted first to deploy a R80.30 VSX cluster and upgrade to R80.40 when there were more hotfixes available, but the R80.40 Smart Console decided otherwise and since the management was ready and the boxes were there, I just had to proceed with R80.40. I also have a TAC case which I think got R&D involved and I hope they're working full steam on a resolution.

I have R80.40 Take 67.

0 Kudos