Unifi setup w/Gen2 Cloud Key

[HCHTech]

I recently did my first install with a Gen2 Cloud Key. I've got about a dozen or so installs out there with Gen1 Cloud Keys, so we have that procedure locked in and well-documented. Since we deal mostly with small businesses, our normal setup involves a small Unifi POE switch that we place on a separate LAN port on the firewall. That lets us put that traffic in a separate zone and we can control it there. We setup VLANs in the Unifi settings for Guest vs. Private.

This current setup is different, the client needed a new main network switch, so I went with the Unifi 48 POE-500. Maybe a little overkill, but I wanted the 10Gb port for the server. We have 5 APs. Because of this, we have only a single connection from the switch to the firewall, so configuration is a bit more complicated. Also, I wanted to use this setup to update our SOP.

I did the initial setup on my bench where I had more control. I setup a router to provide the same LAN configuration as the client's firewall, plugged in the switch, CK and all of the APs. During the setup where you configure the cloud key, I noticed there was a 'guided setup wizard' available if you chose the basic setup (as opposed to advanced). Because this was new, I decided to run through that to see what all it did, and didn't do. I specified the wifi setup I wanted and answered the various questions. To my surprise, this resulted in everything working as desired. We had:

1. Both WLANs present and secured
2. Clients on the Guest WLAN were isolated from clients on the LAN
3. Clients on the Guest WLAN were isolated from clients on the private WLAN
4. Clients on the Guest WLAN were isolated from each other
5. Clients on the Private WLAN could see and ping clients on the LAN, and vise versa

Next, I went looking for how this was accomplished. To my surprise, I found no VLANs created, just the two WLANs, and the Guest WLAN had the "Guest Policies" checkbox ticked. I went into the switch configuration so see if they had done VLANs there or port isolation or something - everything looked unmolested - no special configuration that I could find.

Well, being me, I didn't like not knowing how they did this. I reset everything to factory defaults and re-did the setup manually, using VLANs like normal. This also worked as expected, I got the configuration i wanted and I knew how it got there.

I decided to do a chat with Ubiquiti to see if I could ferret-out what the wizard did to accomplish that initial setup. No surprise, but they were not really interested in helping me understand. It's like they didn't even know about the wizard setup. "You didn't use VLANs?" "Does it work now"? After 30 minutes of back and forth like that I gave up. I love Ubiquiti, but it makes me crazy that their support consists almost entirely of pointing you to their tech notes. I even offered to do the wizard setup again and have them remote in to look at the screens I was seeing, but it was very clear that either they don't do this anymore, or at the very least, they save it for true emergencies. In any event, they declined.

So, I doubt I'll see a setup similar to this anytime soon. Can anyone more familiar with the Gen2 Cloud Keys offer an opinion on exactly how that guided setup accomplished the traffic isolation without creating VLANs?

 

[SAFCasper]

When you enable "Apply Guest Policies" for a SSID it doesn't make a VLAN. It still bridges to your main network unless you tell it otherwise. The difference is they use protocol blocking to prevent interaction.

So you could have device 192.168.1.10 on your main SSID and 192.168.1.11 on your guest SSID. Same network, same subnet, same vlan, same DHCP server and scope... they could even ping each other.
However, it will block any attempt of smb, ftp, ssh etc between the two devices. So they are essentially "isolated"

Creating a separate VLAN, subnet, DHCP scope etc for each network is much preferable, but it's a reasonable solution when the rest of your equipment isn't VLAN aware.

 

[HCHTech]

Thanks. Hmm. is this "protocol blocking" visible anywhere in the configuration, or is it all under the covers when you check to apply Guest Policies? During my initial setup, I tested with ping and explorer, so the protocol blocking was also blocking ping. Since there is no USG in place, whatever is happening has to be controlled by the APs themselves in that instance - I'd think, anyway. This is interesting.

Here is an on-point question from their forums that doesn't come to a conclusion, unfortunately.

I also found this quote on their forums in another thread - it's from a user, not from a Ubiquiti person, but seems on point:

"The guest policies add additional isolation by solely providing access to the internet and preventing the clients from communicating with each other on the same vlan (guest1 cannot communicate with guest 2)."

 

[YeOldeStonecat]

You can think of "Client Isolation" as a sort of...."almost VLAN"..but it isolates "each client" on that guest network from each other. The only thing they can access, by default, is DHCP, DNS, and the gateway. You can add additional things they can access, like the MAC address of networked printers. (I still add the DHCP source and the source of DNS...because in the past versions of Unifi..sometimes that didn't always flow through flawlessly).

If you create just a VLAN for the guest network....computers that latch onto that guest wifi can see each other. So...can infect each other, can mess with each other, etc. So the safest approach for a guest network, what I do is create a corporate VLAN, our standards are...VLAN 6 for guest networks. I then create the SSID for the guest network....and enable guest policies...and then in the advanced section, assign it to VLAN 6. You of course have to take care of DHCP and DNS for this VLAN. And then determine about your fine tuning policies...multi cast, etc etc.

As a "best practice" for Unifi, I also create a switch port profile for ports on the switch that will face APs...and I enable port isolation for those ports. This cuts way down on broadcast traffic from going across the APs. As, airtime is precious. Just note...if you have anything connected to the APs that need to be seen from the LAN, such as a wireless printer....you need to not have port isolation enabled on the AP that the wireless printer is connected to.

 

[HCHTech]

As a "best practice" for Unifi, I also create a switch port profile for ports on the switch that will face APs...and I enable port isolation for those ports. This cuts way down on broadcast traffic from going across the APs. As, airtime is precious. Just note...if you have anything connected to the APs that need to be seen from the LAN, such as a wireless printer....you need to not have port isolation enabled on the AP that the wireless printer is connected to.

This is gold - thanks!

 

[Sky-Knight]

The default guest access policies don't block protocols, they're IP level controls. They simply prevent the wireless clients from communicating with anything in the three RFC reserved private IP ranges. With exception of DNS and DHCP traffic from the appropriate sources.

You can add and remove IP addresses from those ranges too... it's all in the controller. Settings -> Guest Control.

 

[YeOldeStonecat]

If you're getting into using Unifi products more and more for your clients, look into getting a multi tenant Unifi controller for you hosted up at Hostifi. Ryans and his crew are great. Takes much of the maintenance off of you. He manages the Unifi controller upgrades, he backs up your sites, troubleshoots controller related issues. He stays back a bit for good steady/best Unifi controller versions...only upgrades after lots of research and sticks to the best versions.

I still have probably 60-ish clients on Cloud Keys....tied to our account at unifi.ui.com portal
But most of our clients are now over at Hostifi...think we have around 200 sites there. Well worth the money.

 

[HCHTech]

If you're getting into using Unifi products more and more for your clients, look into getting a multi tenant Unifi controller for you hosted up at Hostifi. Ryans and his crew are great. Takes much of the maintenance off of you. He manages the Unifi controller upgrades, he backs up your sites, troubleshoots controller related issues. He stays back a bit for good steady/best Unifi controller versions...only upgrades after lots of research and sticks to the best versions.

I still have probably 60-ish clients on Cloud Keys....tied to our account at unifi.ui.com portal
But most of our clients are now over at Hostifi...think we have around 200 sites there. Well worth the money.

After a particularly not-fun Ubiquiti week, I'm starting to look at a hosted controller more seriously. What is the "conversion" process like? Ideally, I could take a current backup of each of my sites, restore them all to the new cloud controller, then use the unifi.ui portal to access each AP & switch and change the inform address. I'd like not to require an onsite visit as part of the conversion. For some clients, I could certainly remote into a spare machine onsite, but for others, that doesn't exist, so it would be more cumbersome.

Also, Hostifi doesn't really have a plan targeted at a small fry like me with only 15 sites, I also found Controllific, which has a "500 device" (apparently this means count of total APs not number of sites) for about 40% of Hostifi's lowest plan, and also includes backups and updates. I have more research to do obviously, but I think this will be a 2021 project for us to convert.

 

[Sky-Knight]

@HCHTech, all of the above tells me you've already goofed...

Unifi inform URLs by default are unifi.whatever.com. The whatever.com bit is the DNS suffix spit out by the local DHCP service that configures all of the devices. What you do is use a router that can spit put a custom DNS response to that name for that network, that resolves to the appropriate IP address.

That way, when you want to move a controller for a given network, you pull a backup, restore it into a tenant on the cloud controller, and once you're sure everything is there and working you update the DNS record, then go into the onsite controller and tell all the devices to reboot. When the devices come back up they resolve the name to the new IP address and checkin with the new controller. You can even control that rollout by rebooting a test device first.

All of this is why I love having Untangle at the head of a Unifi network, it makes this DNS change trivial and works independently of the Unifi stack if something goes wrong.

Anyway, don't change the inform URI, use the default and control the default behavior. Save your hair!

 

[HCHTech]

Like most things Unifi, their tech notes only go so far when you want to research a "How do I do this thing" kind of question. Their support isn't that much better. They just assume you know the "right" answer, which obviously, I don't. So I'm glad for this forum's resources. I've never done anything special with DNS at a site when configuring a Unifi setup, so I think your solution will still work for commercial installs where we control the edge device (typically a Sonicwall). For the few residential installs with an ISP router, I think I'm better served changing the individual unit inform settings). Having not been down that path before (changing the controller location), I've never needed to change default behavior before.

 

[YeOldeStonecat]

After a particularly not-fun Ubiquiti week, I'm starting to look at a hosted controller more seriously. What is the "conversion" process like?

easy peasy...there's a "migrate" function which makes is wicked easy....you run the wizard...which has you enter the DNS of the "new" controller. This automatically sets the inform on the devices to look to the new site. It also creates an exported file. You then import that file on the new controller, which creates the site...and you see the devices lite up there. Complete the migration wizard and you're done. Throw away that cloud key.

As for migrating from hosted controllers, so...we always had our own controllers at unifi.<our shortened domain.net>. And later unifi2.<our shortened domain.net>.
When we decided to go to Hostifi (they're great)....they give you a static IP, and...you just repoint your hosted controllers there. So....I did a backup from our own controller...restored the backup at Hostifi...and then I adjusted our DNS a-record for "unifi2" at our domain.

 

[Sky-Knight]

Oooo... I missed that migrate button that's nice!

 

[VISA MC]

easy peasy...there's a "migrate" function which makes is wicked easy....you run the wizard...which has you enter the DNS of the "new" controller. This automatically sets the inform on the devices to look to the new site. It also creates an exported file. You then import that file on the new controller, which creates the site...and you see the devices lite up there. Complete the migration wizard and you're done. Throw away that cloud key.

As for migrating from hosted controllers, so...we always had our own controllers at unifi.<our shortened domain.net>. And later unifi2.<our shortened domain.net>.
When we decided to go to Hostifi (they're great)....they give you a static IP, and...you just repoint your hosted controllers there. So....I did a backup from our own controller...restored the backup at Hostifi...and then I adjusted our DNS a-record for "unifi2" at our domain.

What made you move to hostifi vs a traditional VPS? Did you run cloud VPS before or did UniFi and unifi2 point to physical servers in your office?
We are approaching 250 sites on ours and have yet to see any performance issues.

 

[YeOldeStonecat]

What made you move to hostifi vs a traditional VPS? Did you run cloud VPS before or did UniFi and unifi2 point to physical servers in your office?
We are approaching 250 sites on ours and have yet to see any performance issues.

Covered above in reply #7.
I'm close to exiting this profession, I'm older, I like to start closing my work day at 4pm and head home. Got tired of dealing with the host OS security, logs, firewalls, running Unifi upgrades (that occasionally blew up...right when you want to head home), dealing with backups, database maintenance, etc. To me that is "volunteer time". Usually done after hours..which dinner time and after is precious to me.

Not related to performance issues at all. In recent years just prefer to pay for services instead of supporting them myself. In my earlier years when I was young and full of piss and vinegar yeah I'd often eat dinner at the office and stay late late late working on stuff. I had spun up our UBNT servers at RackSpace, and later moved 'em to Linode.