Scheduled Firmware Update.
I'm sure I'm not the only person in the whole forum who experienced the following:
We left our Automatic Update on and once we updated our controllers, within seconds all the SSH connections with the server is disconnected because APs went into upgrading mode and Wi-Fi is down. A few minutes later, branches across the country or even the world call and complained that their Internet went down for a few mins.
To counter this problem, I'll suggest the following improvements:
1. Add an option to select the scheduled update time under the Automatically Update Firmware column.
2. The update time selected follows the time zone which was configured for the sites. This ease the job for IT if they have overseas sites to manage.
Non Destructive AP Update.
As we all know, if we leave the Automatically Update Firmware checked, all the APs will all go down at the same time and we will lose all Wi-Fi access for a few minutes before they came back up when a new firmware arrives. This is a large problem because someone might be doing something when the update is rolling.
My suggestion is:
1. Create a database so that the Controller knew which AP is nearby to which AP. Other than that, the controller needs to know which AP can takeover another AP's load if one went down (eg during Upgrading).
2. Update only selected APs at any one time so that this allows other APs to come in and take over their load while they are being upgraded. This reduces impact on the clients. They will simply roam onto another AP when the original AP is undergoing upgrades.
Support this idea by giving it a kudos if you think this is useful for you!
The Topology view is great and could be even better if it would also present the different configured networks with colors. Something like:
- one bold gray line if the link is carrying All networks
- one bold <network color line> for the main network and additional non-bold lines for tagged vlans
bonus point if clicking on 2 devices would should the route between the two of them.
extra super bonus points if clicking on 2 devices would show the route between the two of them and the firewall rules that might apply between them.
Would be helpfull to log clients attempts to connect to a Wi-Fi network using an incorrect WPA/WPA2 key.
High number of incorrect login attempts might indicate a vlunarability scan or a brute force attack.
This feature might increase security of WLAN´s because Admins will see message in case of penetration.
Thanks for considering
I love the DPI functionality, to have a quick overview of how my traffic.
However, I find it frustrating that I can only see currently acrtive devices for a traffic category.
E.g. in the main category "SECURITY UPDATE" I can see the following:
I know that none of the devices in my network has Avast installed - so I am curious to see which device communicated with Avast. However, since it happened in the past I cannot get that information - clicking on "Avast" will show:
It is impossible to for me to catch the application in the act - so I have to guess which devices might have initiated the traffic.
You obviously have the data, it is just a matter of preseving/presenting it..
Please add this functionality :-)
The firewall GUI needs to get cleaned up.
1. A single tab for firewall rules regarding traffic IN and OUT on the same interface, but with a direction arrow on the firewall rule.
2. Better sorting of firewall rules. Abillity to sort on direction, action, protocol, source, port, destination, enabled / disabled.
3. One separate tab for every interface / vlan.
It would be great if we could have multiple users in the Cloud Console, especially with the new Elite Console around the corner. Rather than utilizing a shared account we'd like to be able to give each of our techs an account to manage our clients through the cloud console. Also enabling and enforcing two-factor authentication would be an welcomed enhancement.
There has been a lot of trouble reported with Cloud Keys being corrupted when power is lost. Since the Cloud Key runs standard controller software, it seems likely that the controller is also vulnerable when running on other platforms. While ideally the software would be robust to power failures, there is doubt that this can be solved with software alone.
As a fallback, people can protect their controller with a UPS. But this, on its own, doesn't solve the problem - it simply delays it. If a power outage exceeds the capacity of the UPS the same problem exists. To avoid this, it is necessary for the controller to shut itself down *before* the UPS runs out of power. Common consumer UPSs provide for this by providing a USB interface that can deliver UPS status information.
It turns out that there is an open source project that already interfaces to a wide variety of UPS systems. Using this software it will be easy to extend the Controller to do the right thing when powered by a UPS. Please do this!
More information on this can be found in a post on the Switching and Routing forum: Feature Request: Shutdown Router/Switches with Battery Backup.
I want to suggest the option to choose a default VLAN for a wirless network if RADIUS assigned VLAN is activated.
This should move wifi clients to a default VLAN if no VLAN attribute "radiusTunnelPrivateGroupId" is received form the RADIUS server.
An additional suggestion already mentioned on the forums is the option to reject authentication if no VLAN is received from the RADIUS server.
One would think that simple function like this is already impelemted. But it's not.
Please warn us when there is new Unifi controller SW available
(like it works on other UBNT devices).
A popup message, an administrative e-mail.. anything
The UniFi Cloud Access Portal (https://unifi.ubnt.com) should have the option to send email notifications when UniFi controllers go offline/online.
It would be great if when mousing over the Upgrade button on the Devices page, the UI would tell us which version clicking it would upgrade to. I use a CloudKey and it is always behind on firmware updates. The last update kicked all my WiFi clients off after 15 minutes and I had to downgrade the version to get them back. I'd like to know when a fixed version will be available so I can upgrade without re-installing the version that gave me issues in the first place.
5.3.8 seems to have introduced a feature not present in 5.2.9, and not mentioned in the release notes where it generates an alert on detecting a rogue AP.
These notifications are not helpful in an environment where your buildings are surrounded by other buildings that broadcast the same SSID. In my case, part of a University where different departments have their own wifi system but we all broadcast the same University-wide networks in addition to our local ones.
Equally this could be an issue for small businesses in built up areas who use popular 3rd party providers for guest access (such as The Cloud)
Within a minute of upgrading to 5.3.8, I'd had 45 notification emails (before disabling email notifications - which now means I can't tell when an AP has crashed or been unplugged), and the notifications continue to roll in on the console every time it refreshes.
So a config option please to revert back to the earlier behaviour of not being notified of rogue APs (at least until the more complicated idea of being able to mark rogue APs as good) would be perfect.
Please add Whitelisting / Blacklisting to the controller (maybe via Guest Control?)
I need to block sites like Youtube, social media, porn,... on our guest network.
The only real solution I can find to do this is to create a VLAN but I only have the ISP router and it is not capable of creating VLAN.
I could also force OpenDNS (or similar) on the AP but then I will also restrict the normal network.
(And it actually does not seem to work either...)
After installing the Unifi Controller (5.2.9-8748) on a Debian Sid system from the Ubiquiti APT repository on a Debian Sid system, I was shocked to discover that the package automatically installed and started a full-blown network service as root, with no security hardening whatsoever.
This basically means that anyone who manages to breach into the Unifi Controller (say, by remotely exploiting a vulnerability in the built-in HTTP server) gets immediate unfettered root access to the entire machine, without even having to lift a finger. That's quite appalling, and it goes against the fundamental, well-known, decades-old Unix best practice of not running daemons as root.
There is no reason whatsoever for the controller to run as root, as it doesn't require any special privileges for normal operation. As a matter of fact, the following hardening procedure will downgrade the controller to much more restricted privileges, while still allowing for proper operation:
# systemctl stop unifi # groupadd unifi # useradd -g unifi -s /bin/false -d /dev/null unifi # chown -R unifi:unifi /var/log/unifi /var/lib/unifi # rm -rf /var/run/unifi # cat > /etc/systemd/system/unifi.service.d/security.conf <<EOF [Service] RuntimeDirectory=unifi User=unifi Group=unifi PrivateTmp=true PrivateDevices=true ProtectSystem=strict ProtectHome=true ProtectKernelTunables=true ProtectControlGroups=true NoNewPrivileges=true ReadWritePaths=/var/log/unifi ReadWritePaths=/var/lib/unifi ReadWritePaths=/var/run/unifi EOF # systemctl daemon-reload # systemctl start unifi
The above not only runs the Unifi Controller under its own dedicated user and group, it also uses advanced systemd features to completely lock down the daemon, including making almost everything read-only, hiding access to devices, and preventing anything running under the controller from running setuid binaries. This kind of setup makes it extremely difficult for an attacker to escalate their privileges upon a successful compromise of the Unifi daemon.
Can we please have this setup (or something similar) be the default for the Debian package, instead of running network-facing services as root by default? Please?
I believe here we have many IT Managers that are managing multiple sites across the country or even around the world. Most of the sites share the same settings but up till now, we have to make a new site and duplicate the settings for the new site MANUALLY. To circumvent this hassel, some IT Managers just dump all sites into one site (example here)which bring some problem as listed:
1. Hard to pin point the site when error occurs.
2. This method can't be used if USGs are deployed to more than 1 site. (UniFi Controller limits one site one USG)
3. Not best method to manage your sites and APs when you have hundreds of them
This is why today, I'm suggesting the implementation of Site Group into the controller where a site can be placed within a larger group. The benifits are as follow:
1. Settings are automatically duplicated from the Site Group's default settings to all newly created sites within the Site Group.
2. All the sites within a Site Group can share the same settings.
3. Special modifications can be made on a per site basis if needed.
4. Saves IT's time when deploying tens or thousands of sites.
5. Allows IT to arrange the Sites according to Site Group (Eg, different Geographical area).
6. Easier for IT to find a Site when the branch calls up and asks for network information. (Imagine if you have 1k sites in a controller)
7. Allows IT Service provider to serve customers with multiple sites by putting all of the customer's site under one Site Group.
Here is an example of what I imagined the Site Group feature should be implemented:
Under the Current Site tab. there should be an option to choose 'Overview' which allows us to see the Site Group's status as a whole. Settings made under the 'Overview' site will be the default settings for other site.
Give this Feature Request a kudos if you think this works for you and should be implemented into the Controller.
On the controller you can view the statistics for the following
Traffic (needs DPI)
We have two SSIDs. One for employees, and one for the public.
We would like to know when the public is using the public wireless. Right now, the public and employee is all meshed together in the overview.
I would like to request that an additional statistics page be added that breaks down each SSID
I beleive the controller already collects this information, it just needs to create the data display.
The Unifi switch should be accessible via IP address.
I understand that full config would only be available via the controller, but just to access and reboot would be VERY helpful.
The controller is on a CloudKey attached to the PoE switch. It because unresponsive; thus could not access any network devices without a manual (pull the power) reboot of the CK or switch itself.
- col10 on: Unifi Controller - Clients view ... display LAN statistics
- vwtonline on: Rogue access point
Request - aggregatio
n/storage of DPI data on a per client basis
Scheduled Firmware Upgrades and Non destructiv
e AP updates.
Firewall GUI enhancemen
- svenvg93 on: Wifi only version of the controller
- Dave-D on: Rogue Detection And Blockage
- rebelwireless on: RENAME NETWORK CATEGORY IN CONTROLLER
- F1NETWORX on: Custom DDNS Providers
- willba4 on: log incorrect password attempts on Wi-Fi networks
- Limited UAP EDU Broadcast User
- Reset a device config to factory (except name)
- Unifi Controller - Clients view ... display LAN statistics
- Rogue access point
- Sites Overview - Upgrade Available
- Rogue Access Point XXX was detected
- Add Walls (and wall material) into Unifi Mapping feature
Make Hotspot and Voucher-ba
sed access control accessible to multiple sites
- Scheduled Restart for AP's to clear state tables, memory, or when network changes occur
- Speed limits with RADIUS or directory service