| Frustrating combination of lack in performance and features [message #148390] |
Sat, 04 July 2020 00:46  |
CristianoIera
Messages: 5
Registered: February 2014
|
|
|
|
Kerio control has a really "hystorical" weak ppoint: the very well known problem of the single-thread, single-core SNORT implementation, limiting the throughput in NAT with IPS at unacceptable speed, much lower than most of the ultrawideband internet connections available on the market at really cheap prices.
A bad workaround is to use some kind of new and very powerful (and of course expensive) hardware appliance to improve the performances of SNORT to an acceptable level. But there's a problem: 99% of new hardware platforms supports ONLY UEFI boot, and it's absolutely unsupported in the current version of Kerio control, though UEFI is supported in linux since 2012.
Moreover, it's a really bad limiting factor in small and medium business implementations that require high sustained transfer speed for business purposes (cloud applications, cloud backups and similar).
We are GFI/Kerio partners, and I notice that selling your product turned into a big hassle, because most of the competitors have much better performances at lower prices and using cheaper hardware, though the usability and learning curve of kerio control remain unsurpassed.
These two issues (SNORT and UEFI) combined are really a pain the ass with this product. We are compelled to look for valid competitors and I'm really disappointed of this, because we invested in advertising your product among our customers and now we have to hear claims from customers for better performances, because they can identify clearly the problem in the firewall: asking their internet providers to improve the connection speed, they are invited to make a speed test with a PC directly connected without firewall and the speedtest says 980Mbit/sec without kerio control and less than 400 (sometimes 100-150 in less performing machines or VM) with kerio control. At that point they call the firewall supplier...
I think it could be avoided with a little effort by your development team.
|
|
|
|
|
|
| Re: Frustrating combination of lack in performance and features [message #148428 is a reply to message #148423] |
Wed, 15 July 2020 01:50  |
CristianoIera
Messages: 5
Registered: February 2014
|
|
|
|
Thank you very much for the insider info.
It could be amazing if both these upgrades will be available in 2020.
I know that in some implementations the multithreaded implementation of SNORT is accomplished by paralleling some instances of the process on different streams, but while this should be good in large environments, it does not solve the problem of the single stream speed limit. I hope you'll find a solution soon or adopt a different library or decide to contribute to the development/testing of the real multithreaded SNORT...
|
|
|
|
| Re: Frustrating combination of lack in performance and features [message #148446 is a reply to message #148390] |
Thu, 16 July 2020 20:08 |
ascdew
Messages: 7
Registered: July 2020
|
|
|
|
I will start by totally agreeing with the post by CristianoIera regarding the lack of performance improvements in Control by GFI development. It's really appalling that GFI development would be ignoring improving Control performance.
3 years ago we had a discussion with the Control dev group as we were configuring several new appliances for customers and we wanted to implement the new appliances with NVMe. At that time we were told that it wasn't possible because Control was still running on a fork of the 3.16 kernel.
So now we are at the same juncture with a number of client firewalls needing a tech refresh, so yesterday we placed a request to GFI Control as to whether NVMe support was now available with Control? Before placing the request we researched the NMVe linux driver and found that it has been back-ported all the way back thru linux kernel 2.6.
Sadly we just heard from GFI Level 2 support that the NVMe driver is not included in the latest Control kernel. How is this acceptable. Given the currently acknowledged performance constraints, making use of the NVMe driver would certainly help.
Another open issue since October 2019 is that the Control update back then broke the ability of a client to present a custom Control logo to users logging into/validating on the firewall. As of today - 8 months later this simple bug remains unresolved?
The UEFI boot issue is also unacceptable. How is it even possible that this is not already in place with Control?
Like CristianoIera, we are long-time Kerio/GFI partners and Control is our FW/UTM solution 100% of the time. But we are definitely taking major hits from clients due to the competition. Now with the virus and "WFH" being the solution, performance is ever more critical.
We fail to understand how GFI can allow Control to whither on the vine like an unwanted step-child. Is the GFI plan to deprecate Control as a product?
Please enlighten use on what the plan is for Control and why there appears to be nothing done to improve performance and implement new tech hardware features?
We are about to place several new hardware appliance orders and if these basic features are not available, we fear the clients will request that Control be replaced by a solution that takes advantage of modern hardware technology. Please do not allow this to happen!
|
|
|
|
|
|
| Re: Frustrating combination of lack in performance and features [message #148451 is a reply to message #148447] |
Fri, 17 July 2020 22:54 |
ascdew
Messages: 7
Registered: July 2020
|
|
|
|
Hey Ian:
Appreciate you responding to my post/request. As a follow up:
1 - installed V9.3.5 Beta 3 build 4224
Custom logo still does not work. Removed custom logo, installed beta 3. Re-applied custom logo - no joy! Tested with edge, firefox, vivaldi, chrome and safari.
2 - Very glad to hear that kernel 4.19 is in the works. I will press my luck and ask if it is possible to get a bit more defined on a release date for this and if it will include the latest kernel features/drivers like NVMe?
I realize that release dates are a moving target, but since it is already July, if we could get a more specific commitment it would be helpful. As I explained previously we have several customer firewall appliances that need a hdw refresh.
We are going to lose those sales because Kerio Control is no longer competitive in terms of the hdw performance curve. However we have solid if not current Hdw that we can temporarily put in place until this 4.19 kernel release is available - if it will be available this year? But we do need to manage customer expectations regarding what GFI will be doing.
|
|
|
|
|
|
| Re: Frustrating combination of lack in performance and features [message #148474 is a reply to message #148453] |
Thu, 23 July 2020 00:32 |
ascdew
Messages: 7
Registered: July 2020
|
|
|
|
There's not much to do to test:
1 - installed Control V9.3.5 beta 3 Build 4224 - see image 1 KerioControl-V9.3.5beta3-1.jpg
2 - on the custom logo config page - tried removing, add back, etc. to trigger change/update - see image 2 KerioControl-V9.3.5beta3-2.jpg
3 - tested login screen - custom logo is not displayed - see image 3 KerioControl-V9.3.5beta3-3.jpg
4 - Here is a snippet of xml from the winroute.cfg file - which appears to have the correct settings?
<table name="Misc">
<variable name="BrandLogoEnabled">1</variable>
<variable name="BrandPageTitle">ASC Kerio Firewall</variable>
</table>
5 - in the export of the cfg.tar.gz - it contains the brand_logo.png file - which when looked at is the correct custom logo file
So I am not quite sure what we are missing to get the custom log to work?
If there is something else we need to do to get this working, please advise.
|
|
|
|
|
|
|
|
| Restarting thread - Frustrating combination of lack in performance and features [message #149436 is a reply to message #148451] |
Fri, 26 February 2021 17:04 |
ascdew
Messages: 7
Registered: July 2020
|
|
|
|
Hello Ian:
So it's been almost 7 months and sadly I have seen nothing on the Kerio Control front regarding when the Linux kernel might be upgraded to a more modern and current version.
Certainly the ability to take advantage of NVME alone would help with performance, and at this point there are numerous improvements in the linux kernel, so it's becoming increasingly disconcerting to see the lack of development by GFI on the Control product. Most of our clients have figured out that the chinky-pox pandemic is overblown nonsense and economics/revenue growth requirements are now becoming the priority.
We are starting to see project upgrade requests escalating and timeframes becoming "immediate" need. Sadly as far as upgrading client firewalls, we are stuck with proposing older technology hardware solutions to accommodate the limitations of Kerio Control due to the old kernel in use.
Is kerio control simply the unwanted step-child of the GFI product line? Please tell me someone over there recognizes the need to move the product forward, or please sell it off to someone who wants to actively promote & upgrade the product.
Has anyone on the forum found a competitive solution to Kerio Control?
|
|
|
|
| Re: Restarting thread - Frustrating combination of lack in performance and features [message #149482 is a reply to message #149436] |
Thu, 11 March 2021 17:58 |
ascdew
Messages: 7
Registered: July 2020
|
|
|
|
Just an update on this thread to any user that shares our concerns about the delay and inability of the Kerio Control Dev group at GFI to get the obsolete Linux Kernel upgraded at least to V4.19.
Sadly this forum thread originates back in 2014, with more postings from 2017 - 2020 regarding the obsolete Control Linux kernel and all the related problems and deficiencies it has caused! We have personally lost over 30% of our Kerio Control customer base as clients simply can't afford to wait any longer for a more modern solution, especially on the hardware side as Linux has enabled so many new features in the more modern kernels that help dramatically with performance.
We have complained frequently about this issue and last night we finally received a much more coherent and sympathetic response from the GFI-Kerio Control Support Team. His response to us was as follows:
\\ ------------------------------------------------------------
Dear David,
Thank you so much for understanding the cause of our delay in kernel upgrade; it is well-appreciated. Although I'm sorry to hear that this has caused quite a deal of inconvenience for you and your customers.
To be honest with you, the new ETA for upgrade to kernel Debian Buster v4.19 is not yet provided (as mentioned by my colleague Guido) to the internal teams. A little earlier, I reached out to our Knowledge team and discussed this to hopefully (force) obtain an answer as they have immediate, direct contact with our Engineering team. They responded that they don't have an ETA yet, nor do we have an internal thread where we can obtain the new ETA.
As much as I would like to help you, for now I believe the best direction we can take is either (or both) of the following:
1. Consider posting a topic about this in our GFI Forum. More pressure there will help speed up the process.
2. I suggest that you subscribe using your email address on our GFI Upgrade Center (if you haven't yet). You will be notified via email as soon as the Kerio Control 9.4.0 (which has the v.4.19 kernel) is released.
\\ ------------------------------------------------
As you can see by his reply - he unfortunately appears to be as frustrated as we "Control" users are. So my immediate ask to any users on this Control forum is that you please post a request that GFI dev immediately move the Control dev project for migrating to the Linux 4.19 Kernel to the top of the priority list!
Perhaps if we can flood the forum with users that want the Control product to be the great tool it can be, we can get this done?
I remain absolutely stunned that GFI does not realize the sales opportunity that they have with the Control product! We believe with a newer kernel that can take advantage of the improvements in hardware - a number of serious performance limitations could be solved. Control itself is feature rich with numerous options, so the performance gains would make this a serious competitor in this market. As someone who has dealt with competitive products I can tell you that the Control graphic UI combined with the SSH backend admin, provides a very robust product that can be easily explained/demonstrated to an end-user, but also provides a variety of complex solutions on the technical side.
What is critical and killing Control is a serious performance deficit caused primarily by the obsolete Linux kernel. What is ironic is I remember talking directly to the Kerio Dev team - way back when they moved from the windows platform to the Linux platform. They told me it was great because it would enable them to easily and rapidly provide more features and better performance. Sadly this appears to have been a very unrealistic dream.
But I digress - if you love/use/want Control and you want it to be a great solution - please post that GFI dev get the kernel upgrade done now!
[Updated on: Tue, 14 June 2022 12:24] by Moderator Report message to a moderator |
|
|
|
Members
Search
Help
Register
Login
Home
