I still use their access points because it's hard to get anything else as good for the same kind of price, but they burned me killing the development on EdgeRouter.
So I've gone elsewhere for cameras, switching and routing.
This release is a nice point in their favour though but I can't see myself going back all in on Ubiquiti.
Their security issues in the past. Their failure to make the EdgeRouter handle DHCP and DNS properly. Etc...
I've since moved to cheap switches that support all port vlan trunks and LACP bonding, then just plug Proxmox into them and run OpenWRT in a VM for routing all the vlans. The Proxmox+OpenWRT combo even supports hot-plug virtual interfaces as more VLANs are lit up, they just pop up nicely in the web UI.
For the APs, TP-Link is less expensive and better performance. WiFi 7 and 10gbit for less money. No need to run a management OS in a VM either.
Their software updates are also very flakey. The past few releases for the Console and occasionally the Network were pulled right after being published for having blocking bugs. Again and again they publish the update and then do QA on their users. If you have an IT department you probably have some sort of process in place to deal with this and deploy when you're satisfied. A home user will probably have auto-updates enabled and bite the bullet again and again.
A while ago one update automatically enabled PMF (set to required, I believe) on all Wi-Fi networks. That didn't go great for me when half of my IoT devices stopped connecting and I wasn't available to fix.
Talking about flaky updates, Network update just published, already a flood of complaints [0]. And the constant changes in the GUI, with buttons and features constantly shuffled around and moved from one place to another for no apparent reason, are tiring.
Not sure, how active development is right now, but EdgeOS got forked from an open source devian based distro after that went commercial.
But EdgeOS was not the only fork, another one was VyOS (vyos.io). Pretty sure, that EdgeOS has done larger steps forward, especially, since it was bound to the hardware's developer.
The distribution was called Vyatta. VyOS is now very actively used and developed, it's way ahead of EdgeOS since that's been basically dead for years. EdgeOS was basically just a nice web UI over Vyatta but the one key point was that the EdgeRouters had hardware acceleration (Cavium CPU with offload, but Cavium got acquired by Marvell since) and only EdgeOS has the proprietary binary blob and integration that you need to use that on the EdgeRouter hardware.
So even though VyOS exists as the modern day Vyatta fork that is active and fully-featured, you can't really run it on the EdgeRouter hardware and since Ubiquiti stopped development, they're basically e-waste.
I still run one in a network but really shouldn't, since Ubiquiti are very rarely shipping security updates...
Funnily enough, they've just released an update! Yes, I was taken by surprise a bit.
EdgeRouter 3.0.0 [1] adds official wireguard support (I've been using the "wireguard-vyatta-ubnt" package from Github [2]), UI changes and some other improvements/fixes. I haven't tried it yet but will. I have an Edgerouter3-lite and an ER-X.
I'm shocked! Literally two years of basically zero activity since the last hotfix release...
The new GUI looks nice and Wireguard is great! Not all good news sadly though, users in the comments there are pointing out that the kernel has hardly been patched from the versions two years ago... At least some packages like OpenSSH, dnsmasq etc. have had updates.
the one key point was that the EdgeRouters had hardware acceleration
The EdgeRouter Lite used a Cavium SoC, the EdgeRouter X family used a 32-bit MediaTek SoC. Hardware acceleration was buggy on both and is/was known to cause packet corruption.
The main problem with the EdgeRouters was that Ubiquiti was basically just assembling off the shelf stuff. They didn't have the ability to fix SoC issues (or motivate the manufacturers to fix them). For years they didn't have the ability to do much Linux dev work either so the ER families languished on an end-of-lifed'd version of Debian. That experience and realization only motivated me to avoid future Ubiquiti products.
The thread you reference ends with the post saying "it is fixed in the 7.4.140 controller release", so im not sure how you can say it wasnt acknowledged or fixed.
Are you a ubiquiti employee who can see internal posts perhaps? There’s no such post on the public discussion. The only two instances of “fixed” on the page are people expressing hope it will someday be fixed.
As the other poster said, you actually need to read the thread and then a Ubiquiti employee links to a post where it says it was fixed. Considering you were so affected and frustrated by this issue, Im surprised you didnt actually read the thread you posted to realise this issue was fixed 2 years ago.
I’m curious to know more about your setup! Which switches do you prefer? What hardware are you using for proxmox? And what does your network look like?
For the switches I'm considering replacing them all with 2.5gbit but don't see the need to yet. Currently I have a TL-SG1016DE as the core switch. The main proxmox servers are 3 used Dell 1U servers I bought from Ebay. Each has 256GB ECC ram, 2x 8 core CPUs, 4x Gbit intel nics. I flashed the PERC card to be a plain SCSI controller so ZFS in Proxmox has direct access to the disks. If I were to buy them today I'd look for R720's or newer. I got mine for about $800 USD each. They're overkill, but provide a lot of capacity. They're also unnecessary, you can ignore them and only consider the rest of this comment. They're the most expensive, hottest, and loudest devices on the network.
I have a separate tower that's a old 9th gen intel that provides the large ~50TB ZFS NFS server. It used to be an intel Atom, but that finally died after 10 years so I moved the drives to a gaming PC I had lying around. Over the years, nicest thing about ZFS and Proxmox is the drives are fully independent of the hardware and the software OS they're attached to. Now, I just pass the devices through Proxmox to a Debian VM and they come up just like they did before.
Regarding the rest of the network, let's move from the edge in toward the 3x 1U servers and NFS storage box. I have 1gig symmetric fiber from Ziply. The ONT has cat5 running to 1 of the 4 gig ports in an Intel Atom C2758. The other 3 ports are bridged together in Proxmox to act as a switch. It kind of looks like an EdgeRouter-4 if you squint at the ports. This C2758 only runs a single VM, OpenWRT. The nice thing is I can take snapshots before upgrades, and upgrade or replace the hardware easily.
The OpenWRT VM is the most critical thing in the whole network. I try to manage it simply, I have some shell scripts that copy the /etc/config files into place and restart services for a simple IaC setup.
The main services OpenWRT provides are:
1. WAN DHCP client, my ISP doesn't offer static IPs.
2. One minute cron job that makes sure the A record for home.example.com is correct. *.home.example.com is a CNAME to home.example.com, this simplifies configuration and TLS cert management.
3. HAProxy runs on OpenWRT listening on 0.0.0.0:80 and 0.0.0.0:443 Extremely valuable for SNI routing of TLS connections. I moved the LuCI web UI to alternate ports, which is simple to do via config.
4. dnsmasq provides dhcp and dns for the main and guest VLANs.
5. OpenWRT is configured as a WireGuard server. Each wireguard client device is allocated an dedicated IP in a separate 192.168.x/24 subnet. This has been great for source based IP access control which I'll cover below. Wireguard clients connect to home.example.com.
That's it for OpenWRT. The key lesson I learned is it's been incredibly valuable to run haproxy on OpenWRT. All L4 connections terminate to it, but crucially it does not handle TLS certificates. It only forwards TCP connections based on the SNI in the client hello. HAProxy is also configured to use the PROXY protocol to preserve source IP addresses, which has been great for access control.
Most TLS connections are forwarded to a single node Talos VM running on another Proxmox host. This VM runs Cilium, Istio, and the Gateway API. The istio envoy gateway is configured to accepts PROXY protocol connections, which means AuthorizationPolicy resources work as expected. By default, only connections coming from the local subnets, or the wireguard subnet are allowed. OpenWRT does hairpin NAT, so this works just fine, all sources connect to the WAN IP regardless if they're internal or external.
I don't do much with Kube yet, most of the traffic is forwarded on to another VM running Portainer. Most of my backend services are in Portainer. The Kube VM does handle Certificate and AuthorizationPolicy resources though, using cert-manager and Istio. This has been nice, I don't need to configure each service for TLS or access control in bespoke way, it's all in one place.
The only other thing to note is the Dell 1U servers have 3 of their 4 gig nics aggregated into LACP bonds. Similar to the Atom router, they're configured as a bridge in Proxmox and I use them for the Ceph data plane. 9 of the 16 ports in that TL-SG1016DE are just for Ceph and I'm able to get close to 600 MiB/sec reads (yes megabytes) which is pretty neat given 1gbit interfaces.
That's about it. Overall I'm trying to eliminate VLAN's, but it still makes sense to have them for Ceph and for a Guest wifi network.
Edit: Lastly I've maintained a home lab for 25 years and this is the best iteration yet. All of the trade-offs feel "right" to me.
This. We used to do a lot of Ubiquiti, then the software quality went way down, their own security officer 'hacked' them and lots of other weird stuff. We were already using debian vm's instead of their horrible cloudkey devices (so slow..). We switched to Aruba Instant-On.
We still use some Ubiquiti. Sometimes i use this script on a Debian VM:
The new generation Ubiquiti hardware with built-in management is really good, inexpensive, and interface is responsive. It's also just good looking. They've really gotten better across the board. I'm using the Cloud Gateway Max.
This looks cool but it's not on any camera brand I have ever heard of before. I have a bunch of hikvision stuff that is on its own vlan with no internet access because it's concerningly chatty with Chinese IPs. I would love to put openipc on them.
I moved the firmware if my EdgeRouter X SFP to OpenWRT, since it has been years from their last security update and recently the WebUI tripped and broke.
The router works still amazingly fine, only their software has some bugs.
Personally, I've had good luck with Reolink cameras. I block them from the Internet at the router, just in case, but they do seem to respect your choice if you disable the cloud/mobile app feature.
The cameras will upload jpegs and mpegs to a local FTP server based on configurable triggers, which include 'AI' detection of animal/vehicle/human, all running on-camera.
I wrote a simple script to put all the daily uploaded jpegs on a HTML webpage (each linked to the video) for review. Home Assistant also has an integration that can do streaming and grabs the detection triggers as well.
RouterOS does feel a little clunky for sure, but you can configure _everything_. And once it's set up, it works beautifully and consistently.
Ubiquiti's routers to me just seem to be prosumer routers with an "enterprise" UI on top. Whereas Mikrotik genuinely offer an enterprise experience (also still great for home) with the boring, drab, absurdly functional UI to back it up.
Ubiquiti looks beautiful; but you can't do anything with it.
The GL.iNet Flint 2 came highly recommended (near cult following) from my own pretty extensive research for offboarding ubiquity. It comes with a OpenWRT fork pre-installed, but flashing mainline OpenWRT is officially supported. I've been happy so far.
The Flint 3 just launched, and the headline feature is WiFi 7: that should be less of an issue if you're going with separate APs.
I have a bit of a soft spot for Mikrotik, but I can't help feel like their hardware only exists to sell training.
For our house I tried a Mikrotik, a TP Link and a Ubiquiti AP. The only one that really works in our case is the Ubiquiti. Also for a home that's mostly Apple hardware, you kinda need a manage wifi solution, because Apples WIFI stack have issues switching between APs and needs a controller to kick you off (I don't know if that's still the case). Ubiquiti have one of the only routers that will force Apple hardware to switch APs. Mikrotiks CAPsMAN isn't even really a WIFI/AP controller, it's just provisioning.
For all it's flaws, I still really want to just run 100% Mikrotik gear.
RouterOS 7 with the wifiwave2 package supposedly improves on this by (finally) supporting 802.11r/k/v for roaming between APs.
I don't have any mikrotik hardware new enough to support it so I haven't tried it myself yet and documentation is (as usual) pretty lacking, but like you I want to believe.
I work for a small ISP servicing both fiber customers and a diminishing (Thanks, starlink) number of fixed wireless customers.
We use all Mikrotik hardware for routing. RouterOS is so flexible and capable. But it is absolutely not user friendly.
For large scale commercial deployments we use Ubiquiti equipment. There is always a Mikrotik router but the APs are all Ubiquiti. It’s just easier and cleaner for us to manage deployments that way.
I see no reason why someone just casually playing with their home network would use Mikrotik though.
We use Cambium for Point-to-Multipoint mostly because the price and selection is better than Ubiquiti but we use the wireless backhaul gear from Ubiquiti in a few spots.
To be perfectly honest if Ubiquiti had the right kind of hardware and management capabilities for us to serve as the root of any deployment I would probably use it everywhere.
So I've gone elsewhere for cameras, switching and routing.
This release is a nice point in their favour though but I can't see myself going back all in on Ubiquiti.