[tjoff]

Why would you need any vpns?

Especially if the vpns are setup from the controller you create a delicate chicken-and-egg problem. How are you to provision it the first time?

You also open up yourself to the problem of accidentally locking sites out and having to reconfigure each site from within.

[teilo]

You are overthinking this. If you have a VM running the controller, or a cloud key, on your internal network, you would need to VPN in to manage them remotely.

[tjoff]

No? If you have any remote sites you need it to be directly accessable from the internet anyway. Or am I missing something?

Now you might not like that, but realize that this service is exactly that.

You might be comforted by the fact that a breach of the controller doesn't affect your internal networks.

...until you realize that having control over the controller means root access on all of your sites. So it shouldn't be that comforting.

[teilo]

I'm not advocating that any enterprise use this service. I run a WAN with 4 local sites (on a MetroE MPLS network) and a remote office via a VPN tunnel. So this is not my first rodeo.

I would never use a cloud-based WiFi controller for the very reasons you specify, and that means that if I need to remotely manage Wifi while I'm out of the office, I'm using a VPN.

A lot of companies don't have the same security concerns. That's all I'm saying. And some for those who, say, manage wifi access intended for the public at multiple sites, like a Hotel or coffeeshop chain for example, this might be just the ticket. They don't have to setup and maintain a bunch of individual controllers, and can centralize everything in one console, and let someone else maintain the server it runs on.

[tjoff]

I agree, but the more or less equivalent alternative isn't setting up a bunch of controllers.

It's buying one cloud key, opening one port in the firewall and ensuring you have a dyndns or something to the site with the cloud key.