Oh no it’s not! I’m right there myself.
Me neither since I have a VPN for my entire network I won’t use a second, more specific one. However, I can see where some who don’t already have a VPN may want to use a dedicated one to CC.
I would say this more than anything for me.
This additional feature has to be configured by the user. It’s not active out of the box.
6 Likes
You’ve got my vote for making VPN available with off as the default setting.
I would not want to see traffic to 3rd parties going through your servers though. I want my hub to continue working even if your company ceases to exist and the servers are turned off (something we’re hoping won’t happen of course).
1 Like
For security, allow users to use self-signed certificates at a minimum, plus the ability to generate and install full SSL certificates. What would be even better would be to include the certbot daemon to support LetsEncrypt in the base OS and having a UI to configure it. This will allow users the option to use real SS certs without the technical expertise, hassle, or expense of doing it on their own.
3 Likes
Uhm … maybe I should have been more specific in my original post. When I mentioned SSL certificates and https, I assumed you would know that I considered all of that a part of SSL certificates.
3 Likes
I thought so, but in my line of work, omitting details leaves things dangerously open to interpretation. 
4 Likes
Another Mars VS Venus issue my house runs into all the time 
4 Likes
I know enough about certs to be dangerous. That said.
-
It seems that SSL certs are rough to use when you’re not using a dedicated “domain name” that you own. You can generate self-signed ones with some work–but they can also trip up some checks (e.g., browsers that aren’t trusting of them). While you can add trusted certs to WIndows, that can be rough to do for some devices. So, one supposes your system would allow us to control the trusted cert/CA lists?
-
As for VPN stuff. That can be a royal PITA if you have to manage things (It took me a while to figure out how to generate certs for OpenVPN that didn’t expire every 30 days!). Esp for novices–so tools, good documentation, etc. are important.
-
If you could allow use of some “Dynamic DNS” service thru the hub to accommodate normal ISP use of dynamic IPs–then have remote apps able to point to a Dynamic DNS provider to get the current IP address, that would be great.
-
Allow using an SSL protected VPN tunnel to connect to the hub remotely (from mobile apps, etc.), incorporating the necessary dynamic DNS lookup (with provisions for NOT using the VPN when on the same, local network–but, allowing optional VPN use if desired).
-
Ideally, your remote/mobile apps would have the OpenVPN client built-in, so they could automatically connect to the hub securely, remotely.
-
BUT ALSO: it would be great if your hub’s OpenVPN server allowed pretty much ANY authenticated device to connect. That way, I could (for example) create an OpenVPN profile on my laptop and just browse right to it–so I could manage the device remotely in by browser.
-
Your OpenVPN server on the hub will need to support the use of client certificates and passwords (i.e., super tight security) so that simple hacking of passwords doesn’t let you in from outside.
Much of the above should allow direct control without you having to “cloud serve” anything. You could offer the Dynamic DNS lookup–but, it would be great if you also could use OTHER providers (e.g, DynDNS).
And, if your device surfaces an OpenVPN tunnel, you could remotely access the full capabilities of the device.
The trick is doing things to make the OpenVPN stuff less than obtuse (it took a fair amount of wrangling and stumbling across some great posts/documentation/etc. on generating certficates, configuring OpenVPN, etc. to get my Asus one working properly).
And. The. Key. Issue. Support/updates. If this sucker is going to have an “ear to the WWW/wild wooly world”, the OpenVPN software and anything else needs to be super secure, patched RAPIDLY for all the vulnerabilities the come along. And, it needs to “keep up” with compatibility for newer OpenVPN clients, etc.
2 Likes
I had the same struggles with ovpn that you did and I fully agree with your concerns. However, I don’t recall the OLL folk saying anything about ovpn. Wireguard is the only VPN that will come with CC AFAIK.
1 Like
I guess, mainly, I was only familiar with OpenVPN–but, it sounds like WireGuard isn’t bad. It’s just much newer and less proven. However, also smaller and faster in general.
Most of my comments would apply in some manner with it (although, it does handle keys/certs differently).
I’d like to see the ability to proactively control what clients get VPN access from the hub side, with secure certficates.
1 Like
Got it. We’ll have to wait and see to be sure but I think we’ll be able to add packages to the Linux OS and OpenVPN could be one of them. 
Since I have both ovpn and wireguard running on my f/w (wg is new addition and I’m evaluating it) I won’t use whatever CC provides so I really don’t have any skin in this game.
1 Like
But, the bonus of using something the build in (assuming it works well and is secure) is that their app should be able to leverage it to allow secure connectivity remotely (e.g., from your phone). And, it should be transparent.
I already have access to my ENTIRE network with either ovpn or wgvpn. Why would I want a more restricted connection? Granted, some will prefer it that way.
You might have an exposed port (port forwarding) JUST for your hub. Then, the app could connect without you needing to manually establish the OVPN/WG connection first.
Example: Using Android Auto. That uses WiFi and doesn’t work if you have OVPN fired up and connected. However, you can still access the Internet via your 5G connection.
If you had the hub’s port exposed and used their VPN, you could still connect securely. And, not interfere with AndroidAuto (assuming their mobile client handled the VPN connection internally).
For those who want it that way it’s a great option.
You’ve lost me here. I have a client app for ovpn on my phone and I have a peer app for wgvpn on my phone. With either one I open the app and tap the slider to start the connection, nothing more. ALL traffic from my phone is then routed over whatever network is available to the VPN (server/peer) on my firewall which is then routed to the destination, be it my internal networks or the Internet, with DNS blocking from my Pi-hole, and all apps on my phone use this singular network connection. Except for speed it’s exactly like being connected to my home Wi-Fi. And since my HA stuff is on one of my internal nets it is accessed the same from any phone location.
I cannot comment about this because I drive Toyotas and they only play with Apple products. 
So, when I’m driving only cell data is available.
What I do with my phone is turn off Wi-Fi when leaving home and fire up a VPN connection for the duration of my time away. Again, other than speed, I can’t tell that I’m not sitting in my favorite chair.
NOTE: I can turn the Wi-Fi on and have the VPN just as happy but there are only a handful of APs away from my own that I trust connecting to so I just leave the Wi-Fi off unless I’ll be in one of those locations more than a few minutes.
On a related note…
Today I ran speed tests from my phone with Magic-Iperf installed using both ovpn and wgvpn. The results are a mixed bag but shoot a giant hole in the consensus (AFAIC) that wgvpn is faster. I conducted the test twice in each of 3 locations and ovpn was faster in 4 of the 6. YMMV
1 Like
My thought was that, if the WG client is “bulit into” the hub’s app, then it would be easy for ANYbody to have an “instant” VPN to their hub, even if they didn’t have anything else going.
They would simply need to forward a port from the firewall to the hub–and all the traffic from the app to their hub would be secure & encrypted via the automatic VPN. No other VPN would be needed.
And, if you were already on the network with a separate VPN connection on your phone, it could detect that and connect without the VPN just like if you were at home.
I’m just throwing out some ways they could make it MUCH more secure than other options and even avoid the need to pop through the cloud (aside from, possibly, using a DynDNS provider to look up the home IP address).
As for Android Auto, it will NOT connect when I’ve got my VPN going. Perhaps, with a lot of work, I could figure out how to let the phone’s WiFi connect to the radio head without the VPN while letting the phone data use it–but it’s not worth it.
Plus, bypassing VPN on WiFi would ONLY be desirable when it was talking to one of my 2 AndroidAuto heads. All other WiFi connections should go through the OVPN if I had it up.
1 Like
I’m dropping it because we’re talking different use cases and to each their own.
I do want to clarify one thing for those unfamiliar with VPNs…
It’s not quite that simple. The user still has to generate key-pairs on each system they want to participate in the VPN and copy the public key to each other system they wish to connect with. There’s no getting around that. While it is an easy thing to do there are a great many who get hung up on this…just like I did the first time. 
I want to add some things regarding Wireguard to begin with. The minimal system overhead is the first thing I want to point out. If it is not in use system resource use is negligible since it’s part of the kernel anyway. On a device inside a LAN, such as a CC, there are multiple ways to connect between peers, one is direct with a port forwarded to the device. This is not something all users can be expected to know how to do. When that is not possible there’s still ways, such as UDP port hole-punching. This technique doesn’t always work, it depends on the router/FW used on the network. It also requires a 3rd peer on the outside to initiate the connection before it can be made direct. There are things like UPnP, but let us not go there. We may use such things, but personally I would recommend it to be turned off in most cases.
As for configuration of Wireguard peers, that can be done with QR codes. Dynamic DNS is a feature we will have built-in, but it is as everything else, optional.
OpenVPN speed is mentioned above, yes, for throughput I also see better results with OpenVPN. There are types of tech which can give even greater speeds, but the complexity of getting them to work is way outside of what even most power users would want to bother with. For low traffic applications such as a Dashboard or admin pages, it doesn’t matter much however. There latency is an important factor. In that regard both types of protocols usually come out on equal grounds. When it comes to how easy setting up a client/peer is, WG is the winner, every time.
With that said, for those that want to use any built-in functionality they can do so by adding a peer. Those that don’t see a need just don’t use it and can use their own solution.
Flexibility and choice is a key guiding principle for our system design. Two other important development goals for us is secure-by-default and ease-of-use. These are two goals which often contradict each other, so it is a matter of balancing and careful selection of solutions to get us to a good product. Since we won’t force anyone to use any cloud services or to keep a CC connectable from the Internet, if they don’t want to it is all a matter of choice. For ease-of-use, certain things will be on by default, but configurable.
With this said, what do you think about these types of design goals? They’re not the only ones, mind you, but they are important to us.
9 Likes