Reply
New Member
Posts: 4
Registered: ‎12-05-2017

Cloud Key strategy for remote site

I have a Unifi network at home and I am planning to set up a simple Unifi network in a remote location (my parents). Aside from cost, what are the pros and cons of having a Cloud Key at the remote site as well as locally vs just having one Cloud Key manage both sites?

 

My primary objective is for any configuration/diagnosis I need to do remotely to be utterly reliable - "popping over" to do a bit of diagnosis/fixing isn't practical.

New Member
Posts: 16
Registered: ‎05-30-2017
Kudos: 3
Solutions: 1

Re: Cloud Key strategy for remote site

The controller is really a passive thing. For family and friends, I generally just run everything under my controller. 

Even in my situation where an upgrade caused me some cloud grief, the outage doesn't impact the remote sites. These sites (cottages or parents) don't really require changes in logic. Once imprinted they generally just run. 

Therefore I'm a proponent of just having them all report back to a centralized controller. Less "thingies" to worry about at the remote sites.  

Senior Member
Posts: 23,586
Registered: ‎08-04-2017
Kudos: 4470
Solutions: 1160

Re: Cloud Key strategy for remote site

Hello @rowatt,

 

You will open ports to the entire world if you want to adopt devices to your UCK.

 

 

Regards,

Glenn R.

Cloud Hosted Controllers | Glenn R. | UniFi Installation/Easy Update Scripts | UniFi-Video Installation Scripts | UniFi-VoIP Installation Scripts
USG-XG-8 • USG-4-PRO • USG
US-XG-16 • US-48-500W • US-24-POE-250W 2x • US-16-POE-150W 3x • US-24 • US-8-150W • US-8
UAP XG • UAP-SHD • UAP-HD • UAP-NanoHD 2x • UAP-AC-PRO 2x • UAP-AC-LITE • UAP-AC-IW • UAP-AC-M • UAP-AC-M-PRO 2x
UAS-XG • UCK-G2-PLUS • UCK-G2 • UCK
New Member
Posts: 4
Registered: ‎12-05-2017

Re: Cloud Key strategy for remote site

[ Edited ]

 @chuckpitre I agree that fewer "thingies" is generally a good idea, and point taken that even if something does go wrong with the connection to the Cloud Key, the kit should just keep running with its existing config. I guess my concern here is that if I did need to make a config change (say changing the guest wifi password), and something went wrong with the CloudKey connection, I'd be stuck. On the other hand, if something went wrong with a remote Cloud Key, I'd be equally stuck.

New Member
Posts: 4
Registered: ‎12-05-2017

Re: Cloud Key strategy for remote site


@AmazedMender16 wrote:

You will open ports to the entire world if you want to adopt devices to your UCK.


Thanks, but is that a big deal? If I understand correctly, all I would need to do is to open INFORM (8080) and STUN (3478) inbound on the site with the Cloud Key, and it doesn't seem that either of those ports represent a risk (unlike 8443 which, I believe is not required if I enable Cloud access?).

 

Am I misunderstanding which ports need opened or the assiated risks?

New Member
Posts: 16
Registered: ‎05-30-2017
Kudos: 3
Solutions: 1

Re: Cloud Key strategy for remote site

If opening ports was a problem then there would be no applications served over IP. 

There are security good-practices that you can do to minimize and mitigate risk. Things like isolating your publicly available applications from your home user network or other things like config backup strategies. STUN, very popular with SIP, is designed to get around NAT (a cumbersome thing from ipv4) and ensure end-to-end connectivity. Make sure your password isn't something like SailB0at123; get a password generator and make it lengthy (ex: lastpass), mfa etc etc etc

 

if you wanna be uber paranoid you can try putting up your own stun server and setup a back to back UA to Ubnt and be all uber complicated (see first post on too many "thingies")

 

Mitigate and minimize are my favorite strategies, the rest end up in the category of "arms race" IMHO. 

Senior Member
Posts: 23,586
Registered: ‎08-04-2017
Kudos: 4470
Solutions: 1160

Re: Cloud Key strategy for remote site

[ Edited ]

Hello @rowatt,

 

An open port is always a vulnerability.

The chances of being attacked are low, but I'm just letting you know.

 

 

 

 

Regards,

Glenn R.

Cloud Hosted Controllers | Glenn R. | UniFi Installation/Easy Update Scripts | UniFi-Video Installation Scripts | UniFi-VoIP Installation Scripts
USG-XG-8 • USG-4-PRO • USG
US-XG-16 • US-48-500W • US-24-POE-250W 2x • US-16-POE-150W 3x • US-24 • US-8-150W • US-8
UAP XG • UAP-SHD • UAP-HD • UAP-NanoHD 2x • UAP-AC-PRO 2x • UAP-AC-LITE • UAP-AC-IW • UAP-AC-M • UAP-AC-M-PRO 2x
UAS-XG • UCK-G2-PLUS • UCK-G2 • UCK
New Member
Posts: 16
Registered: ‎05-30-2017
Kudos: 3
Solutions: 1

Re: Cloud Key strategy for remote site

@AmazedMender16 I disagree with your premise that an open port is always a vulnerability. Somewhere in the world of things this became an accepted statement. This akin to noting that a doorway in a wall is a vulnerability. It is an entrance way where you control traffic.
Now how you control traffic will then dictate the degree of security. This is the same if you are running a road-block, managing masses of people coming in and out of a controlled entrance or running a cluster of web-servers that need layers of mitigation from reverse proxies to wafs. Having port 443 open isn't the risk, having port 443 open without anyone posted at the doorway watching the peeps come in and out is the vulnerability.
But i'm way off topic and into the philosophical & strategic narrative at this point Man Happy
New Member
Posts: 4
Registered: ‎12-05-2017

Re: Cloud Key strategy for remote site

@chuckpitre thanks. I'm with you ports & vulnerabilities in general - for applications/devices that are designed to be used in untrusted environments, opening specific ports to properly configured devices/apps ought to be fine. I do like to understand what I'm doing, though, before I open things up and I'm definitely still learning when it comes to Cloud Key.

 

Reply