rad daemon cause problem with Web browsing

[MartinTzvetanov]

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.

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.

[stelaa]

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. 

[Jan_Kleinhans]

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

[MartinTzvetanov]

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. 

[Timothy_Hall]

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.

[MartinTzvetanov]

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.

[Alex-]

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.

[valeryw]

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.

[MartinTzvetanov]

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.

[valeryw]

Hello Martin,

Thanks you for update.

It is great new.

Valery

[phlrnnr]

@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!

[valeryw]

Hello,

The number Fix ID is PRHF-12463.

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

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

Valery