How I built a building-wide wireless network for a hundred people
About two years ago, I set up a pretty complex Ubiquiti Unifi network for our medium-sized apartment building in Helsinki and have been managing it on behalf of all the residents since. Here are my notes. We have 39 apartments and several common spaces, with a building-wide network we purchased together to have quality network not only in the homes, but across the rest of our spaces. Because at-home network needs to be private, this makes this a complicated setup compared to most commercial networks of this size. While I’ve come across descriptions of networks many times larger in number of devices and area covered, I haven’t seen anyone describe one with this many parameters. This post dives pretty deep into network management.
TL;DR; key stats: 45 access points, 40 Wifi networks, 40 separated VLANs, 100-ish users, 100Mbps-ish bandwidth, works well after the learning curve (for me — for the users it’s like any other Wifi). Read on for details and lessons learned.
Our fiber uplink is from SuomiCom, a gigabit fiber link throttled to 100/100Mbps sustained (burstable to 200Mbps) shared between all users. This speed has been entirely sufficient, with capacity to spare even during an evening Netflix rush — acid tested over the COVID-19 lockdowns with everyone staying indoors, working, playing and streaming over the same network. A typical day sees an average of 110–120 clients connected to the network — split roughly even between laptops and phones/handhelds. If need be, one phone call to our network provider will lift our link to 1Gbps.
The building is covered by Ubiquiti Unifi UAC access points. There’s a Security Gateway 4 Pro and a 48-port PoE switch in the basement, and AC-Lite APs for most apartments, AC-LR’s in the half dozen larger apartments, all connected and drawing their operating power from that switch. Apartments themselves only have one device each, the unassuming (especially with its blue status LED turned off) wireless access point. Given the heavily reinforced concrete construction, this was how we could have good coverage throughout the building — the amount of steel is visible from the fact that neighbor APs are very weak, even in the stairwells (where wooden doors pass some signal through).
Every AP provides two Wifi SSID’s: one private to that apartment, and another common network to give whole-building coverage for visitors and our own people. We have quite a lot of common space, including a small gym in the basement where there’s practically no cellular coverage, so the latter is pretty important. Each common space of course also has its own AP, which only serves the common network.
The private Wifi networks are obviously the more important part, though. Each of these SSID’s works only with that local AP. That traffic is all routed to the basement equipment and on its way to the Internet on their own VLAN ids, so every apartment has its own completely isolated network. Majority of the use is obviously on these private networks. Configuring all these to be private was a bit of trial-and-error, and I ended up doing it three times over.
The first attempt was to create each apartment their own IP subnet and associated VLAN, and assign each of the Wifi SSID’s to use that VLAN. This worked fine for the majority of cases, but had a couple of drawbacks, which required more research. However already at this point we had both IPv4 and IPv6, private networks in every home, and a common building-wide network to use when in some other space like our gym or club room. We moved to the building a day after its construction completed, and by day three, I had the network working. Pretty good job, even if I say so myself.
The first issue I noticed was that, with the Unifi Controller at the time, I had to also make 40 copies of the common SSID to assign to each of the APs, each with the same configuration. Users and their devices didn’t notice anything, but there was a lot of duplication in the config, so changing anything, including the Wifi password, was a big hassle. A later Unifi revision (version 6.x) introduced AP Groups, which facilitated assigning the same common network config to all APs, and each of the apartment-specific SSIDs (and the respective access points) to their own AP Groups with one access point in each. As many config items, less duplication between them. The AP Groups setup itself was pretty straightforward, but even today I need to hunt around in the Unifi Controller UI if I need to change an AP Group, because those are only accessible via the Wifi network list, and I always forget. Perhaps I won’t, now that I’ve written this down.
The second issue came up when a couple of residents, myself included, wanted to have both wired and wireless devices in the same network, able to communicate with each other. With the Wifi networks in their own VLANs, Ethernet ports couldn’t see the same traffic. So, I needed to figure out how to introduce the same VLAN to both Eihernet and Wifi traffic. My first thought was to simply assign the same VLAN id the apartment’s Wifi networks use to also the uplink port of the backbone switch. Confusingly, while this did move the Ethernet traffic to the apartment’s own VLAN, the Wifi traffic from the AP seemed to disappear! Turned out I would have to not tag the private Wifi’s traffic in the AP, and then both Wifi and Ethernet would be tagged for the correct VLAN by the backbone switch based on the port where it came from. But what of the building-wide common Wifi network? Well, that was always tagged with its own VLAN id, and apparently the switched network had no problem seeing and forwarding it correctly because it was a different VLAN tag. It was only when packets had the same tag on both the AP and the Ethernet port, they’d vanish. Shrug. I’ve never actually studied VLAN configuration, perhaps this is how it’s supposed to work.
Powering a PoE access point while having a wired switch in between on the uplink port obviously required its own tricks: either a PoE injector, despite power already being available, or a switch which could pass PoE power through to the AP. I used Ubiquiti Nanoswitch because of its sufficient capacity, small size and affordability, but I suppose any passthrough PoE switch would do. If there were multiple devices behind one uplink that needed PoE power, perhaps a Unifi USW-Flex would be a good option. Anyway, a complicated explanation for the desired simple outcome: wireless devices like phones in the home Wifi network can control wired devices like TVs in the same apartment, but no one outside that apartment can access that traffic or devices.
As for the Unifi tools, my experience is mostly positive. On the plus side, the network is extremely reliable and I have to do very little maintenance or resolving problems for people. It’s also incomparably convenient that I can access the network management anywhere, on my computer, on my phone, irrespective of being at home or not. On the minus side, when I do have to do something, it’s very confusing, because Unifi keeps not only updating the software, but changing the Controller UI and moving features around. Every time I learn something, next time I need it, it’s likely moved or changed name. Sometimes these changes are good: like the AP Groups that replaced WLAN Groups. Other times, they’re infuriating, like when they change the online documentation, break all links to old docs, and neglect to provide a search engine.
The documentation did also leave a few other things to be desired. When I provisioned this two years ago, nothing in Uniquiti’s documentation suggested the Unifi Cloud Key device would not be able to deal with a network like ours, but sadly that’s the case. It runs and is able to configure the network, but collecting any metrics beyond the last couple of hours overflows its little database. A 41-subnet system is clearly too much of its little CPU, but it’ll manage until it’s time to upgrade to UDM Pro for higher bandwidth, anyway.
Another small issue was that not knowing how much power draw to expect, I over-provisioned the PoE switch way too much. The access points are drawing between 2.5 to 4 watts of power each, and having 45 of them, a 250W PoE switch would have been enough. We now have 750W.
One gotcha that was really tricky to solve, but few people hopefully have to deal with, was how to connect a device like a printer which only supported the WPS “press the button on your router” configuration mode for setting the Wifi SSID and password. Unifi devices don’t support WPS, so connecting these to the network is extremely difficult. There is a hack, if you really must: create a identically configured (same SSID+password) hotspot network on a WPS enabled device like a spare home router, connect the printer/other device, and then turn off the spare router and let the device connect to the actual network. Overall though, don’t buy WPS only devices! Again, this is mostly so I’d remember how to do it myself if the need ever arises again, which I hope it won’t. WPS is such crap.
Devices used, many of which Ubiquiti has replaced with newer models since:
UC-CK: Unifi Cloud Key running the Unifi Controller. As noted above, this barely works, but today you wouldn’t buy one separately anyway: the UDM devices support Controller built-in.
USG-PRO-4: router and firewall. This was the highest performance device available at the time, but today’s UDM Pro is much better and we’ll need to upgrade if we lift our bandwidth to 1Gbps.
US-48–750W: the overpowered backbone switch to uplink each apartment. 250 watts would have been enough, now we have over 3x power margin.
UAP-AC-LITE, 35 devices: most apartments and the common spaces are served by these.
UAP-AC-LR, 10 devices: for the larger apartments which benefit from the more powerful radios on these access points.
N-SW, as-needed: the Nanoswitches to provide fixed-Ethernet ports when residents need those in addition to their Wifi.
Plus the fiber switch and equipment brough in by the ISP, all colocated in the basement telecom space along with everything else but the APs..
