Hacker News Reader

Comment by rdl | Hacker News Reader

Hey. We've finally launched this, which is part of what we've been working on as a YC company for about 18 months.

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.

View on HN

Very cool, congrats on the launch!

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.

Sure! Getcloak is one of my favorite single-user VPN options, and looks like it's perfect for winning the "whack a mole vs. Great Firewall" game when traveling.

We're focused on groups of users and networks.

Thanks! Drop me a line at dave[at]getcloak[dot]com and let's sync up. I'll tell you about our work in and thoughts on the small teams and SMB space, too.

How do you compare to Hamachi, which is the original zero-conf, one-click-install managed VPN service?

https://secure.logmein.com/products/hamachi

I've never actually used Hamachi (although from what I've heard, it's good); I'll check it out more.

It's really good.

Though I wrote the damn thing, so I'm probably biased.

Really happy with Hamachi. Started out marketed as a gaming tool, but LogMeIn remarketed it correctly as a real virtual network solution.

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.

Yeah, from looking at it (I haven't installed it yet), the Logmein purchase and adaptation seems to make it a lot more interesting (I think I do vaguely remember it as a gaming thing back in the day when IPX was a thing)

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 wasn't a "gaming thing".

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.

The idea with protocol was always to keep the handshake/authentication part open, but don't commit to the details of the application client-server messaging. To that end the protocol spec for the original version was available from the moment the system went live and it was detailed enough so that some people made a sniffer and started reversing the application layer (which was fine with me). After the LogMeIn acquisition we revised the handshake protocol a bit to allow for security parameter negotiation and re-negotiation, and the spec again was published. It should still be there on the website, but I don't have a URL at hand.

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.

Honestly hamachi has got nothing on evolve [0]

[0] https://www.evolvehq.com/welcome#welcome-features

I really like the diversification of focus for VPN services. I haven't seen Evolve nor Cloak before, but both are great ideas. My friends used to like Hamachi, but recently have been crazy about Tunngle -- based more around gaming with random internet strangers, it uses the 7.x.x.x block.

---

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.

Hamachi hands out IPs to clients that don't belong to them. Notably they tried to hijack all of 5.0.0.0/8 and 25.0.0.0/8

But aren't those addresses only routed within Hamachi itself?

Its the same as if I worked for Verizon and routed all the phone numbers for San Francisco to my desk instead. Sure it works fine for everyone using AT&T, Sprint, etc. but it breaks the spirit of how the phone network should work (a central registry hands out blocks of phone numbers just like the Internet) and is in general a douchebag thing to do.

No, that's not the same.

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.

At no point did I make that claim. Please re-read with a critical eye.

Hamachi is effectively null routing legitimate users of the space within their network.

They switch to IPv6 a while ago. That's one.

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.

Here is a forum thread from last month where an employee confirms the switch to 25.0.0.0/8 (which is not IPv6, FYI). http://community.logmein.com/t5/Hamachi/New-25-0-0-0-8-Netwo...

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.

I'm not involved with Hamachi anymore, so I took what they told me privately about IPv6 at face value. I know the work on it started back in '09 and there were some v6-related bugfixes referenced in the release notes.

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.

It sounds like the IPv6 support is there, but the client defaults to IPv4 addressing. This has probably to do with user-facing issues of using IPv6 (like customizing passthru rules in firewalling software and such) rather than with an inherent inability of Hamachi to run outside of v4 space. It is capable of pure tap tunneling after all.

> 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.

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.

rdl is saying that they don't want to solve that use case at all. It's a bit hard to parse but if you just pay attention the "aimed at business/group use" phrase and ignore the rest of it, it's clear. It's a single sentence that would be better as two sentences.

Yes. There are better privacy options out there for individuals -- on price point alone. We're also a US company with all US citizens working here, so if someone came to us with a US-legal order, we'd have to comply. Have been considering something like the rsync.net NSL canary, though, and would push for user rights as hard as we could.

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.

But what about us truly paranoid? You should look into getting together with some sort of independent offshore hosting facility and running some remix overlay network services. I could totally put you in touch with this guy...

Seriously though, congrats on the launch.

We're actually looking at hardware tamper-resistance (HSMs, Intel TXT, etc.)

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.)

I could not find your iOS client on the App Store. Does it use one of the standard VPN types supported by iOS?

Unfortunately, no (we've had endless pain with ipsec vpns on client devices which move between networks, and the other protocols supported suck).

We're currently using the Juniper SSL-VPN hardware/software to support iOS users.

Congrats on the launch Ryan! This looks awesome.

Reply on news.ycombinator.com