Testing Zyxel vs Ubiquiti Access Points
When you choose something for yourself - you try to choose the best (preferably not very expensive, of course, but something good). And you try to choose it yourself. No one can take his word for it - only personal experience, testing and testing. And, truly, you can sometimes get amazing results, it would seem, from quite ordinary things. Amazing both in a bad and in a good way.
This article describes a part of the comparative testing of two access points, which were selected for specific cases. Anyone who is interested - Wellcome under the cat.
Point models: Zyxel NWA1123-AC PRO and Ubiquiti UniFi AP AC PRO
Both points are from the same price range and are designed to solve the same tasks.
For auxiliary equipment used in the tests:
The iperf server is a regular desktop computer with a gigabit network card. Nothing special.
The wi-fi client is the second hp probook 430 g4 laptop. With wi-fi module able in 5GHz.
Router - c9 arcer.
The test bench topology is as simple as possible:
Everything that comes into our hands, we run through the standard protocol. We have certain developments on which we rely. Some items vary from one TK to another, but the main functionality remains practically unchanged regardless of the task. There are critical points, the lack of which immediately puts an end to the use of such devices on the network (for example, if there is no ssh or snmp), but there are optional items, the presence of which will be in the plus of the device when summing up the results of testing. For example, the presence of the console port. There is - well, no - well, I didn’t really want to.
Some items will be commonplace, but, unfortunately, they really have to check. Not once or twice there were devices for which the specification claims to support this or that functionality and these checkboxes of settings are even present in the webcam, but do not work.
For example, traffic prioritization. You turn on the necessary tick in the settings, you start to collect packets with a traffic analyzer, but in fact, nothing has changed in the headers. Sadly
In this case, both points did a great job. There are no complaints, and the whole basis of the functionality that was required was implemented. Even somehow boring. This is not a low-pick segment, where you can see the “segmentation fault” from nslookup (yes, there are some places like this).
After checking the main functionality, it would not be bad to find something interesting. It is necessary to check not only the presence of a specific functionality, but also the absence of "superfluous"
Run by nmap at both points:
At both points, ssh is open, which is good. On Ubiquiti, only ssh is nothing superfluous. Only hardcore. On Zyxel - ftp, ssh, http (standard set) and something unknown on 40713 / tcp.
As it turned out later, this is a centralized service for managing access points (not only them, but also other available equipment) through the Nebula cloud. In general, I liked even more than the web of the point itself. A few screenshots to understand approximately (the scale on the first one was specially greatly reduced so that everything would fit): The
login and password for Zyxel by default was not specified anywhere on the point itself, so they simply used the jellyfish (standard utility for Kali linux brutus). We received a login / password pair - 'admin / 1234', and from Ubiquiti we already know the standard log-logs in the form of 'ubnt / ubnt'.
It turned out that at this point Ubiquiti no web server. Totally. Management only through the controller and a special utility. The folder / www is just empty and nothing is spinning on port 80/8080. But here at least the standard busybox (and quite free on commands), unlike Zyxel. There is a step to the left, a step to the right - execution.
On both points, walked the vulnerability scanner (Nessus). He did not show anything supercritical. Below are the results and a detailed description of what is found.
192.168.0.196 - Zyxel
192.168.0.126 - Ubiquiti
Ubiquiti:
One and not critical. Consider nothing found.
Zyxel:
Here it is more interesting, if briefly: the use of the old unsafe versions of SSL and the standard public snmp community, which in the settings you are invited to immediately change, at startup.
First, let's look at the network around. Watch only on 5 GHz band. For scanning, I used Acrylic, The points themselves were included one by one, so as not to interfere with each other. Plus, for the purity of the experiment, turned off another router adapter.
As a result, later, I had to carry out more tests, but in a different, more peaceful place, because In the first case, around someone's corporate network was deployed from just a huge number of points on a very wide range of channels (it can be seen on the screens below, many did not fit).
Traffic was driving iperf'om, in 5 streams. At first I tested for 60 minutes, but then I realized that it was not entirely informative and left the load for 4 hours.
What came out of it below in the spoilers:
Maximum value: 300 Mbit / s (rests against this ceiling and no longer issues)
Minimum value: 228 Mbit / s
Average value: 296.5 Mbit / s
C - stability. Good smooth connection at all times. There are short-term drawdowns, but they are minor.
Statistics during the work:
(CPU yellow, blue - memory + traffic)
Maximum value: 584 Mbit / s
Minimum value: 324 Mbit / s
Average value: 426 Mbit / s
But the CPU load was a little surprised:
At the moment of the test start, the load jumped up to 91%. I didn’t notice any special problems when using the point: the point didn’t heat up, the webcam didn’t lag, there were no packet losses.
The test was for the maximum possible performance and, despite the fact that this is not quite a standard situation, when a huge amount of traffic is driven through for a long period of time, we have such a case. (Access to servers with a large amount of data for "mobile" clients) I believe that the test was successfully passed. In any case, the question was asked to support Zyxel and are currently negotiating on this situation.
CPU / Memory statistics:
Having summed up the interim result, I can say that the Zyxel point looks more attractive in terms of use for the tasks we needed. With a relatively identical function, the choice will always be for stability over a long period of time and, of course, performance.
Unfortunately, it is impossible to completely cover everything with laboratory tests, to emulate all possible situations that can occur in production and to foresee everything. Therefore, further, both points, necessarily, are waiting for field testing in networks as close as possible to the combat conditions.
This article describes a part of the comparative testing of two access points, which were selected for specific cases. Anyone who is interested - Wellcome under the cat.
Point models: Zyxel NWA1123-AC PRO and Ubiquiti UniFi AP AC PRO
Both points are from the same price range and are designed to solve the same tasks.
For auxiliary equipment used in the tests:
The iperf server is a regular desktop computer with a gigabit network card. Nothing special.
The wi-fi client is the second hp probook 430 g4 laptop. With wi-fi module able in 5GHz.
Router - c9 arcer.
The test bench topology is as simple as possible:
Functional testing
Everything that comes into our hands, we run through the standard protocol. We have certain developments on which we rely. Some items vary from one TK to another, but the main functionality remains practically unchanged regardless of the task. There are critical points, the lack of which immediately puts an end to the use of such devices on the network (for example, if there is no ssh or snmp), but there are optional items, the presence of which will be in the plus of the device when summing up the results of testing. For example, the presence of the console port. There is - well, no - well, I didn’t really want to.
By the way about the console
At the Zyxel point, access to the console port is on the case.
This is undoubtedly a plus. On Ubiquiti, the console port is in the same place as the majority of manufacturers (which is absolutely not surprising - many people do this, but they don’t even have any legs):
You can separately arrange a holivar on the topic that: “on a normal device, access to the console port should not be needed in principle, ”but, I tend to believe that it will be better and not needed, than, suddenly, it will be needed and it is not there (just like with contraceptive means).
This is undoubtedly a plus. On Ubiquiti, the console port is in the same place as the majority of manufacturers (which is absolutely not surprising - many people do this, but they don’t even have any legs):
You can separately arrange a holivar on the topic that: “on a normal device, access to the console port should not be needed in principle, ”but, I tend to believe that it will be better and not needed, than, suddenly, it will be needed and it is not there (just like with contraceptive means).
Some items will be commonplace, but, unfortunately, they really have to check. Not once or twice there were devices for which the specification claims to support this or that functionality and these checkboxes of settings are even present in the webcam, but do not work.
For example, traffic prioritization. You turn on the necessary tick in the settings, you start to collect packets with a traffic analyzer, but in fact, nothing has changed in the headers. Sadly
In this case, both points did a great job. There are no complaints, and the whole basis of the functionality that was required was implemented. Even somehow boring. This is not a low-pick segment, where you can see the “segmentation fault” from nslookup (yes, there are some places like this).
Functional list
1. Поддержка multi-SSID. Возможность поднимать минимум две сети с разными SSID + возможность поднять скрытую сеть.
2. Поддержка 802.11i (безопасность, поддержка AES шифрования).
3. Поддержка 802.11q (возможность передачи тегированного трафика).
3. Поддержка влана управления.
4. Возможность изменять мощности сигнала радиопередатчика.
5. Поддержка QOS и 802.1p (возможность приоритезации трафика).
6. Возможность ограничить максимальное число клиентов, подключаемых к точке доступа.
7. Управление точкой посредством telnet/ssh/webGUI.
8.Поддержка мониторинга и управления точкой доступа по snmp.
9.Возможность работы точки в централизованном/автономном режиме.
10. Поддержка LLDP-discovery.
11. Наличие у точки внутреннего лога системных событий и возможность отправки логов на удаленный сервер.
12. Наличие на точке внутреннего анализатора трафика (опционально и не обязательно, но у обеих точках присутствует).
13.Наличие анализатора спектра и возможность обнаружения точкой доступа работающих рядом с ней иных точек.
2. Поддержка 802.11i (безопасность, поддержка AES шифрования).
3. Поддержка 802.11q (возможность передачи тегированного трафика).
3. Поддержка влана управления.
4. Возможность изменять мощности сигнала радиопередатчика.
5. Поддержка QOS и 802.1p (возможность приоритезации трафика).
6. Возможность ограничить максимальное число клиентов, подключаемых к точке доступа.
7. Управление точкой посредством telnet/ssh/webGUI.
8.Поддержка мониторинга и управления точкой доступа по snmp.
9.Возможность работы точки в централизованном/автономном режиме.
10. Поддержка LLDP-discovery.
11. Наличие у точки внутреннего лога системных событий и возможность отправки логов на удаленный сервер.
12. Наличие на точке внутреннего анализатора трафика (опционально и не обязательно, но у обеих точках присутствует).
13.Наличие анализатора спектра и возможность обнаружения точкой доступа работающих рядом с ней иных точек.
After checking the main functionality, it would not be bad to find something interesting. It is necessary to check not only the presence of a specific functionality, but also the absence of "superfluous"
Run by nmap at both points:
Ubiquiti
Zyxel
Тут на скрин не попал еще 21-й открытый порт для ftp.
Тут на скрин не попал еще 21-й открытый порт для ftp.
At both points, ssh is open, which is good. On Ubiquiti, only ssh is nothing superfluous. Only hardcore. On Zyxel - ftp, ssh, http (standard set) and something unknown on 40713 / tcp.
As it turned out later, this is a centralized service for managing access points (not only them, but also other available equipment) through the Nebula cloud. In general, I liked even more than the web of the point itself. A few screenshots to understand approximately (the scale on the first one was specially greatly reduced so that everything would fit): The
login and password for Zyxel by default was not specified anywhere on the point itself, so they simply used the jellyfish (standard utility for Kali linux brutus). We received a login / password pair - 'admin / 1234', and from Ubiquiti we already know the standard log-logs in the form of 'ubnt / ubnt'.
It turned out that at this point Ubiquiti no web server. Totally. Management only through the controller and a special utility. The folder / www is just empty and nothing is spinning on port 80/8080. But here at least the standard busybox (and quite free on commands), unlike Zyxel. There is a step to the left, a step to the right - execution.
On both points, walked the vulnerability scanner (Nessus). He did not show anything supercritical. Below are the results and a detailed description of what is found.
192.168.0.196 - Zyxel
192.168.0.126 - Ubiquiti
Ubiquiti:
One and not critical. Consider nothing found.
Zyxel:
Here it is more interesting, if briefly: the use of the old unsafe versions of SSL and the standard public snmp community, which in the settings you are invited to immediately change, at startup.
tyk
- Удаленная служба принимает соединения, зашифрованные с использованием SSL 2.0 и / или SSL 3.0. На эти версии SSL влияют несколько криптографических ошибок
- Сертификату сервера X.509 нельзя доверять. Цепочка сертификатов X.509 для этой службы не подписывается признанным центром сертификации. Если удаленный хост является общедоступным хостом, это сводит на нет использование SSL, поскольку любой может установить атаку «человек в середине» против удаленного хоста.
- У удаленного хоста включена переадресация IP. Злоумышленник может использовать это для маршрутизации пакетов через хост и потенциально обходить некоторые брандмауэры / маршрутизаторы / NAC-фильтрацию.
- Дефолтное snmp community (public).
- Демон SNMP отвечает большим количеством данных на запрос «GETBULK» с более чем нормальным значением для «max-repetitions». Удаленный злоумышленник может использовать этот SNMP-сервер для проведения развернутой распределенной атаки отказа в обслуживании на произвольном удаленном хосте.
Stress Testing
First, let's look at the network around. Watch only on 5 GHz band. For scanning, I used Acrylic, The points themselves were included one by one, so as not to interfere with each other. Plus, for the purity of the experiment, turned off another router adapter.
As a result, later, I had to carry out more tests, but in a different, more peaceful place, because In the first case, around someone's corporate network was deployed from just a huge number of points on a very wide range of channels (it can be seen on the screens below, many did not fit).
Traffic was driving iperf'om, in 5 streams. At first I tested for 60 minutes, but then I realized that it was not entirely informative and left the load for 4 hours.
What came out of it below in the spoilers:
Ubiquiti
Maximum value: 300 Mbit / s (rests against this ceiling and no longer issues)
Minimum value: 228 Mbit / s
Average value: 296.5 Mbit / s
C - stability. Good smooth connection at all times. There are short-term drawdowns, but they are minor.
Statistics during the work:
(CPU yellow, blue - memory + traffic)
Zyxel
Maximum value: 584 Mbit / s
Minimum value: 324 Mbit / s
Average value: 426 Mbit / s
But the CPU load was a little surprised:
At the moment of the test start, the load jumped up to 91%. I didn’t notice any special problems when using the point: the point didn’t heat up, the webcam didn’t lag, there were no packet losses.
The test was for the maximum possible performance and, despite the fact that this is not quite a standard situation, when a huge amount of traffic is driven through for a long period of time, we have such a case. (Access to servers with a large amount of data for "mobile" clients) I believe that the test was successfully passed. In any case, the question was asked to support Zyxel and are currently negotiating on this situation.
CPU / Memory statistics:
Results
Having summed up the interim result, I can say that the Zyxel point looks more attractive in terms of use for the tasks we needed. With a relatively identical function, the choice will always be for stability over a long period of time and, of course, performance.
Unfortunately, it is impossible to completely cover everything with laboratory tests, to emulate all possible situations that can occur in production and to foresee everything. Therefore, further, both points, necessarily, are waiting for field testing in networks as close as possible to the combat conditions.