Ubiquiti setup / apartments

HCHTech

Well-Known Member
Reaction score
4,050
Location
Pittsburgh, PA - USA
So...one of my residential clients bought a small apartment building this year (3 units). He is having FIOS installed so that each apartment has their own service (=3 ONTs I suspect), and wants to run only wireless internet to the apartments.

There will be three FIOS modems in the locked wiring closet, with a single ethernet jack in each apartment, high on the wall in the corner of the main living space.

I figure I can use POE injectors and AC-Lite WAPs for this purpose, along with 3 cloud keys to give him his own management console for changing wifi passwords & such. The cloud keys would use external power and connect to one of the unused LAN ports on each FIOS modem.

Does this make sense?
 
No reason for 3 cloud keys. Just need one. Put each apartment in their own site.

Why is he not providing a wired connection to each apartment?

Is he really getting 3 separate fios connections?

If this was my complex I would do either:
A) Use 1 FIOS, provide a VLAN wired connection in apartment, let tenant be responsible for their own router/wifi.
B) Use 1 FIOS, Install 1 cloud key, 8 port Unifi POE switch,provide a VLAN wired conenction in apartment, install Unifi AP in each apartment, run all in same controller each apartment in own site.
C) Let tenant get their own internet.
 
This would be a situation I'd put the APs on our cloud Unifi server....instead of dealing with a cloud key for each AP in this strangely separated situation.

Also recommend at least UAP-AC-Pro models instead of the Lites, or if the units are small enough, maybe even the In Wall Pros in case the client needs an ethernet jack for something.

Land Lord could get more profit sharing a single large
fiber pipe instead of 1x per unit.
 
No reason for 3 cloud keys. Just need one. Put each apartment in their own site.

Why is he not providing a wired connection to each apartment?

Is he really getting 3 separate fios connections?

Well, according to him, he wants 3 separate connections so he can get three separate bills. He wants the modems in a common place so "the tenants can't f&*k with them". This is already done, so it's the setup we will be working with. The units were gutted and remodeled already - I'm going onsite later today to see what I have to work with. According to him he said he instructed the electrician to make 3 home runs to the wiring closet (a walled off section of a garage) where the ONTs are. I'm sure he has probably had some bad experience in his past with comingling services so the current setup may just be a knee-jerk reaction to that bad past experience.

So...I don't think I can use a single cloud key because there are 3 physically separate networks. In our initial phone call, I told him about using a single WAN connection and separating the networks with vlans, but he has already made up his mind and the wiring is already done and the ONTs are already installed. As usual, we get called in at the end of the process so we have to work with the variables we are given.

I'm pretty sure I've seen multiple-tenant setups from Verizon before and there weren't actually 3 different ONTs, but instead multiple outputs from a single ONT. I'll know what's there is after I go onsite to survey the havoc.
 
You only need 1 Unifi controller. Either a cloud key, hosted by Ubnt, or running on a VPS somewhere. Just do a Layer 3 adoption if they are not on the same network. Unifi controller does not need to be on the same network as the devices. I have one running on a DigitalOcean droplet with multiple sites.
 
I feel sorry for the tenants. You get fiber Internet but can only access it via wireless. Ugh.
 
What stops them from just unplugging the AP and putting a cable into a switch?

If they are each getting a seperate connection why not give them hard wired as well if you are already running cabling?
 
You only need 1 Unifi controller. Either a cloud key, hosted by Ubnt, or running on a VPS somewhere. Just do a Layer 3 adoption if they are not on the same network.

Ahh. I didn't know you could do that! Since I've only done simple setups, I haven't run into this before.

I thought that in order for a device to show up as "pending adoption" on the unifi controller, it had to be able to talk to the cloud key (i.e. be on the same network) which in turn is configured to talk to my account on unifi.ubnt.com (I'm not running my own cloud controller elsewhere). So to do L3 adoption, I would have a laptop onsite connected to the same network as the device I want to adopt and run the Chrome plugin discovery utility, right? This is what would make the unit see the controller?
 
Several ways to provision Unifi equipment to report to a non-local controller....
The Chrome Plugin....it'll at least let you detect and see the Unifi equip on your network and find their IP. The "manage/set" doesn't always work well so I fire up Putty and log into each Unifi equip and provision to our cloud controller. You run it twice...first time sets the Inform URL...and within a few seconds it shows up in the controller...and you adopt it...and then you run the set-inform command again to sink it home and you'll see it start provisioning in the controller.
 
Hmm - that sounds simple enough. It also sounds like the cloud key isn't really necessary, it just makes things idiot-proof (or at least idiot-resistant).
 
Cloud key is just a computer that runs the controller. Its mainly for convience. Pretty much all my unifi installs (which are only a few) are running the controller on the clients server.

Sent from my Samsung Galaxy Note 9 while driv ik gndjfhd
 
You could also provision everything in your lab and then just deploy on site.

I find it easiest to SSH into the AP apply any updates then do a set-inform to my controller URL in the cloud.

You could even setup limited accounts for the customers on the controller.

Sent from my SM-G870W using Tapatalk
 
We have our Unifi controller running in the cloud.
On our server here in the office I have set a DNS record of 'unifi' that points to the IP address of that cloud controller.
So just plug in a new Unifi device, wait a couple of minutes, and it shows up in the controller ready to be adopted.
 
Well, the onsite went about as I expected. The Verizon folks were only about half done, and 2 of the 3 ethernet runs wouldn't tone out so the wiring guy was contacted. I've ordered the bits and we'll reconvene after the holiday.

@cyabro I've only got 5 or 6 sites now, but I think I'll look into the costs of hosting a cloud controller. I'm not sure where the break-even point is - those handful are running perfectly fine using cloud keys and the unifi site to manage.

Side note - I heard at the ITO Compass that the $79 cloud key will be going away at some point soon to be replaced by the new "v2" cloud key, which will be $179. That might change the equation.
 
I do "both" a cloud controller, and on-prem Unifi controllers.

I actually prefer on-prem controllers when I can. Be it a Cloud Key, or an install on a workstation or server, or for larger places, a virtual instance of Ubuntu on one of their hypervisor servers. All of these can be tied to the FREE portal at unifi.ubnt.com so you can view and manage all of your clients Unifi networks from that centralized web portal. We have around 140 sites on there now. If a single Unifi controller blows up..it only affects that one client, so it's not some big emergency like when a cloud controller with a ton of sites blows up.

In the old days, before UBNT came out with their free cloud portal and cloud keys, we had to do the cloud controller. Many many years ago when UBNT released the first multi-tenant version of Unifi, I wrote up a guide here on building a cloud controller. Back then I ran it at RackSpace, have since moved it to Linode...and I have our UNMS controller there also. At one point our cloud controller had almost 100 sites on it...I've been busy moving them to on-prem controllers (good portion of them cloud keys) ...we're down to around 45-50 now.

All new UBNT clients usually go on a local controller or cloud key. Only the sporadic odds 'n ends ones, stand alone APS, etc...are newly added to our cloud controller. I want to keep as few as possible here. I don't want to have to maintain this server anymore, or deal with the occasional blowups from upgrades of the controller, or having to spend time maintaining and securing the underlying OS. When this server does down...you lose contact with all client sites..becomes a good 911 for you. Non-billable work restoring it. (even though most people spin up linux for this..it's still hanging on a public IP, and accessible from the public....and it holds important client info on it. Most people just tend to set 'n forget these cloud servers). As for cost, they're cheap, depends on how much horsepower you give them but generally around 25-40 bucks a month.

Cloud Keys are senstive to rude shutdowns, can corrupt the mongo database. Lots of people forget that they're PCs...so they just "pull the power". And then wonder why it seems to have broken when it cannot launch the Unifi controller. You need to gracefully shut them down. So plan your staging around that as you prep the equipment in your office or change things around at a client .Always have 'em on a battery backup (which switches and other network equip should be anyways, right?).

The V2 Plus (+) is a combo Unifi controller for network and video. There will be a revised gen2 regular sized cloud key with a more robust storage system to survive rude shutdowns better.

Repairing a tanked cloud key is pretty easy. Two ways you can do it. When the Unifi controller itself tanks (mongo db is corrupt)...just log into the local cloud key web management (which is not the unifi controller app)...and restore from last backup. Backups are stored on that micro sd card. Reboot..BAM, back in action. OR...you can SSH into the cloud key and run a --repair command against the mongo database...give it a few minutes, once done, reboot the CK....usually comes back up fine.
 
Last edited:
I thought I'd do an update since reading about other folks' dumpster fires is always entertaining.

When the electrician who did the wiring was brought in to fix his mistakes, he basically had a tantrum because he "DID EXACTLY WHAT I WAS TOLD" and if they wanted it redone now, "THEY WERE GOING TO F-ING PAY FOR IT AGAIN". Wow. I'm pretty sure whoever did the original job spec didn't say to run wires to nowhere - haha. So he stomped off, never to be heard from again. This was in September.

In October, they brought in another electrician, who took one look and recommended the right answer, which was to run new wires, including all that entails - breaking into now-finished walls wherever necessary to make the runs. This place is a 100-yr-old rowhouse of brick construction, so no-doubt one of the 15 or so contractors that have worked on the project accidentally cut the wires for the 2 units where nothing tones out. Also just for fun, only 4 wires in the ethernet cable to the first floor had any connection now, so it's gotten worse since August. Continuing the disaster, one of the 3 FIOS modems now installed in the garage no longer works - it's spontaneously rebooting about once every 10 minutes, even after a factory reset. Lastly, just to put icing on the cake, I dropped my field laptop onto the cement in the 27° garage (that's -3°C for you non-Americans) after freezing there for an hour screwing around with the wiring and modems. The fall destroyed the screen and both halves of the case (it landed on a corner). A nice 2-yr-old XPS13 a customer recycled last spring - Crap.

I told the owner they should consider ditching the original plan entirely and ask Verizon to just install service in each apartment. I'm sure since they already did the install once, that this won't be free, but it has got to be cheaper than redoing the ethernet runs.

Lastly, they already have a tenant in the first floor, so wanted to know if there was anything I could do to get internet working while they decided on a final solution. So, I took the 4 wires that had connection on that cable, put the same ones on 1,2,3 & 6 on each end of the run, and that got them a wired 10/100 connection. Then I ran a 10 foot cable down from the box near the ceiling and connected it to a wireless router on the desk, made a double-NAT connection and got the hell out of there. I told them not to expect that this ghetto solution would last very long. What. a. mess.

They already bought all of the Ubiquiti gear, so I'm hoping never to hear from them again. It will be a long, long time until I consider saying yes to any job remotely resembling one like this in the future. Yikes.
 
Property developments are often like this. Poor project management and several independent trades each with no idea or concern what the others are doing.

I bet whoever cut through those cables knew damn well they done it. But reporting the issue could result in additional work or worse they have to pay for the damage. Easier to just ignore it... finish the job, get paid and get out of there. "not my problem"


This being said, if you get in with a good property developer it can be a great source of work. We do a lot of WiFi, CCTV, patch panel installs etc for a local developer. The difference is they have a good project manager and tradesmen are on staff. So if the joiner cuts through the electricians cabling he actually cares about it because they work for the same company. He can't just disappear into the night and pretend it never happened.
 
Well, this project is slowly grinding forward, at last. I was onsite yesterday, and I had some trouble, it turns out one of the brand new FIOS modems installed last fall is horked or someting. It won't do DHCP and spontaneously reboots about every 10 minutes, despite a couple of factory resets. If you give yourself a manual IP on their scheme, you can have internet between the reboots. I'm going back onsite today with the owner since Verizon won't roll a tech to replace the thing until you do troubleshooting with them over the phone. Awesome.

I ran into a problem while I was there, though. I put the cloud key on one of the networks and started through the configuration & firmware updates, etc. The site now exists on my controller at unifi.ubnt.com, but I couldn't adopt the AP that was on the other working network. I'm sure this is because the AP couldn't find the cloud key. I tried connecting the AP to the same network as the cloud key temporarily and I could adopt it fine then, but when I moved it back to the other network, it just shows up as disconnected in the controller.

I've read the technote about layer 3 adoption, but I'm confused about what to enter as the new inform URL.

So, my setup is I have 3 separate internet services. All use the 192.168.1.0 subnets. The cloud key has a static IP on one of them, 192.168.1.250. I want to install single APs on each network and have them adopted by the same site in my unifi.ubnt.com controller.

If I connect the AP to a network without the cloud key and use the discovery tool from a computer on that network, I can find the AP, but when going to the unifi.ubnt.com site, I can't adopt it. It doesn't show up under devices as I expected.

When I (apparently incorrectly) temporarily put it on the same network as the cloud key so I could us the normal L2 adoption, that worked fine, but the cloud controller now only shows it as disconnected when moved back to it's own network.

So when I go back today, I'll do a factory reset on the AP and have the controller forget it, but what is the correct method to adopt it without the onsite cloud key on its network? What should I set as the inform URL? Is it the external IP of the network that contains the cloud key or the IP of the unifi.ubnt.com site? Something else? I'm probably missing something obvious. Little help?
 
Back
Top