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

rad daemon cause problem with Web browsing

Hello,

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.

pic1.JPG

Also logs similar to this are also observed

pic2.JPG

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.

0 Kudos
11 Replies
stelaa
Employee Alumnus
Employee Alumnus

Hi @MartinTzvetanov ,

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

You can do it with:

 

Hostname

Protocol

From

Used For (Version)

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

cws.checkpoint.com

http

Security Gateway,
Security Management Server,
SMB Gateways

Social Media Widget Detection (R75 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v http://cws.checkpoint.com/APPI/SystemStatus/type/short

URL Filtering Cloud Categorization (R75.20 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v http://cws.checkpoint.com/URLF/SystemStatus/type/short

Virus Detection (R75.40 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v http://cws.checkpoint.com/AntiVirus/SystemStatus/type/short

Bot Detection (R75.40 and above)

curl_cli [--proxy <IP_or_HostName:Port>] -v http://cws.checkpoint.com/Malware/SystemStatus/type/short

 

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

0 Kudos
Jan_Kleinhans
Advisor

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,

Jan

0 Kudos
MartinTzvetanov
Advisor

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
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
MartinTzvetanov
Advisor

Hi Timothy,

Last time I observed such behavior (maybe a month later) it was with https://portswigger.net/ . 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
Alex-
Advisor
Advisor

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
valeryw
Employee
Employee

Hello Martin, 

Recently we were releasing JHF, that should solve the issue for timeout you have mentioned.

It recomended to install latest JHF  mentioned in sk165456. Could you install JHF and update us with results.

0 Kudos
MartinTzvetanov
Advisor

We applied the latest JHF on our R80.40 and we don't observe the problem. 

I have a customer with the same problem in R80.30. I will try to patch it to the latest JHF at some point soon.

0 Kudos
valeryw
Employee
Employee

Hello Martin,

Thanks you for update.

It is great new.

Valery

0 Kudos
phlrnnr
Advisor

@valeryw What JHF is this fix included in?  I am running R80.40 JHF 77, and see a lot of the anti-bot errors shown here.  Also, what is the Fix ID (PMTR/PRJ, etc) that resolved this?  Thanks!

0 Kudos
valeryw
Employee
Employee

 

Hello,

The number Fix ID is PRHF-12463.

The fix will be included in R80.40 JHF that ETA for release is : Sept 24th.

Sorry it was mistake, when I have mentioned , it was already released. 

Valery

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events