We've been running https://www.getcloak.com/ for about a year now. Let's swap "easy-to-set-up, easy-to-use" VPN war stories sometime if you're interested.
We're focused on groups of users and networks.
Though I wrote the damn thing, so I'm probably biased.
Saved my &*s on several occasions allowing me to connct to a 'non-Internet' facing server.
Does not really have an enterprise feel to it and wonder if it ever will. It also lacks an open protocol description and/or clients on iOS or Android. However, an older build for ARM/Maemo is available. The lack of this limits it currently to a Windows and Linux environment.
Also, I wasn't involved with Hamachi for few years now, but I think they had a plan to switch to TLS altogether, so that must've been done by now.
I wonder if Salesforce, Oracle, Microsoft Azure, etc. would be likely to do some kind of virtual/software defined network thing in the future. It's an obvious choice for an IaaS provider, but being able to put your SaaS or PaaS on a customer-defined network makes a lot of sense too. Would love to talk to those guys.
It was indeed widely used in gaming circles, but gamers weren't really the target market I designed it for. They just happened to come along in droves, because I added support for network broadcasts and that made LAN games playable over the internet.
---
These solutions are amazingly better than trying to host a VPN from DDWRT on a low-powered router -- when the game host isn't on the router's LAN, there's a massive bandwidth penalty. It's worst on RTS and MOBA games, especially Demigod, where clients synchronize gamestate not just with the server, but with all peers. This isn't immediately obvious when hosting games, but every 100ms, each of the 6 clients are sending the checksum of ~1.2gb to 6 other clients, through your router. Twice.
Two - the idea to use 5.x/8 came through me and it dates back to a dot-bubble era managed VPN company I worked for, called eTunnels. These addresses are used for routing inside of virtual networks, which is a separate routing domain, disconnected from the Internet. While this does create a routing ambiguity at the VPN client that wants to talk to the Internet address of 5.x.x.x, it doesn't mean these addresses "leak" to the Internet and somehow disrupt general network flow to/from 5.x.x.x.
You might want to have a look at 100.64.0.0/10, the IANA allocation for carrier NAT implementations. Explicitly allocated to be non-unique and used within networks of private networks.
WRT 100.64.x.x. - back in '07 we pitched IANA an idea to have a dedicated class A network for VPN service providers. This was based on the assumption that while many people might use VPN networking, very few would be on two VPNs at the same time (which is neither too practical nor advisable). So having this space would've meant not needing to compete and resolve conflicts with 1918 addressing and it would also provide single direct-routed space within a VPN that natively supported OS broadcast traffic. Latter is a very big deal in Windows world, because of how a large chunk of Windows Networking works, and it's generally a useful thing to have for proper LAN emulation. IANA just waved us off.
(edit) Followed a link at the post you linked to and there's an official news release that says -
We’ve added IPv6 support to Hamachi a while back, and you can
simply turn off the use of the 5/8 space, but we realize that
IPv4 is still very important to most of you.
Having a 5.x.x.x address assigned to your machine doesn't make all Internet traffic for that address go to your box. You either don't understand the concept of routing domains or you just feel like trashing Hamachi in general.
Hamachi is effectively null routing legitimate users of the space within their network.
You may want to make sure that those two types of VPNs use entirely separate infrastructure, to make sure that crazy jurisdictions trying to block the latter don't end up blocking the former as well. You'll probably still have problems with that.
We've been thinking about how to handle the "company has a bunch of users, a few of them go to China sometimes" problem. That we might actually try to solve (by letting you have a private IP and testing against the firewalls out there, which are getting pretty sophisticated). Probably a few months away.
Seriously though, congrats on the launch.
We got started looking at how to make "trusted clouds", using DRM/tamper-resistant tech. The problem is building that in a way that anyone could actually adopt is really hard, so we figured we'd work on some related, easier problems, where we could build some of that tech internally and use it where it makes sense, first (key management, etc.)
We're currently using the Juniper SSL-VPN hardware/software to support iOS users.
VPNs aren't anything new, but we're an easy to set up VPN service, and aimed at business/group use, vs. either the "privacy VPN" market or the "national firewall evasion" VPN market.
The idea is that we make it easier to use something like Amazon VPC to put your sensitive internal services behind a firewall, then only allow access to those services (or to admin features of your public-facing service) from a VPN.
We're adding other cool stuff to the VPN -- basically we want to be to your internal users and services what CloudFlare is to your public external users.