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.
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.
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
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.
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.
I think they are right on the money. OLL has impressed me every time I’ve learned of a principal of yours. I know of no other project in any realm that does as well in addressing all their users wishes or being as transparent about it.
Checking off some important things I feel I have been missing
My 0.2, I think it’s great to have features built-in as long as it doesn’t cause other compromises. I don’t personally think a smart hub geared towards local control is really the right place for a VPN server, or even a dyn dns, I would prefer all of that to be a part of the router. I do have a WG setup on my Unraid server and the setup is quite easy and has worked great for over a year now though.
I tend to agree, you’re not going to need a VPN without the Internet, at least in most day-to-day uses I would expect. I guess the reason it may be useful to some is if they have a perfectly functional router that does not already have a VPN option built-in. Having this feature on Core can ensure that all customers have the opportunity to enjoy the benefits from secure remote control, whether they choose to use the feature on Core or some existing VPN setup of their choosing.
Same here. I don’t see a good reason to have anything on CORE that isn’t part of rapid automation processing. I’ve had OpenVPN setup on my firewall (Linux box) for as long as I’ve been doing home automation and in my testing it’s faster than WG anyway. I have a beefy server dedicated to HA tasks. It’s been running Mosquitto, Node-red, InfluxDB, and Grafana for over a year and lately I added both Z2MQTT packages so I could gain experience with them. Since rapid processing is high on my list of HA characteristics I’ll move my Mosquitto, NR, and both Z2MQTT functions to CORE when I kick HE out of my environment. I have no intention of moving my InfluxDB nor Grafana to CORE. And I don’t see the rationale for running WG on CORE when I have access to my entire internal network via OpenVPN on my firewall.
That said, I can see where somebody without the resources or experience I have with these components would be thrilled to have everything installed in a cohesive manner on CORE. To each their own. 
And I think that’s the point, and has often been the point with people wanting chart options on HE, people want either some basic functionality in a certain area and/or a more complete offering of features. Not that everyone will have a need to use them or choose to use them on the platform, others will branch out and have those features handled elsewhere, but having them available is a bonus as I see it. It provides an entry point and potentially a solution for many people who don’t have more complex needs or wants.
Especially if one of those resources is ‘time’.
I’m looking forward to CORE getting all those things to play nicely without me having to do much “manual labor”
Even though I will probably not going to use WG on COREs since I have WG and Tailscale for various access but I think it’s a great addon to have for new users.
Unless you are building COREs for DIYers. You will definitely need an easy way for remote access and WG is the way to go.
I do agree WG is easy, but I also have to side with @LosinIt on this one. I run OpenVPN at several sites, across several platforms, and I cannot tell you how nice it is to have a “standard VPN” built in to just about every OS (Synology, QNAP, nix, mac, win, etc.)
If you don’t want to use it, then don’t enable it. It won’t take up any resources. BUT it is something pre-configured for the new user. Otherwise we have those that will do the unsafe port forwarding thing. Keeping the new user in mind and catering to the advanced user. You get to make that choice in CORE.
I use WG on a rpi and I found very simple to set it up and run. Despite my personal experience, having a vpn on CORE is extremely useful and time saving.
May I suggest to include also a performance monitor able to automatically warn when the system Is stressed, profile ancillary subsystems (as Vpn) and suggest to deploy the most impacting onesoutside CORE?