How do you compare to Hamachi, which is the original zero-conf, one-click-install managed VPN service?
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.