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.

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.

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.

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.

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

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.

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.

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

Oh yeah, I'm also a YC alum, which I guess I haven't admitted publicly yet (although I have seriously hinted), so if anyone in the future has questions about YC w.r.t. security or infrastructure companies, or wants to apply to YC after Iraq/Afghanistan, I'd be happy to answer any questions. [email protected].

Your page needs to scale correctly. I can't even sign up for the beta. I just tried signing up for it twice.

First time, http://cryptoseal.com/beta/ received a 400. Second time, http://connect.cryptoseal.com:8443/beta/thanks/ with a 400: http://cl.ly/image/0s1v1z3X0z3I

Why do you make us sign up for a beta/invite if we can't even use it right away and wait? I don't understand. What's the whole point of a launch if you're going to do that? First, you're having a bad registration flow because I'm already frustrated with your service. Two, I can't even use your product to test it and have to 'wait' for the invitation.

Once we fix all this and get the instant (or closer to it) activation, I'll have a hackernews code for some kind of extra service or discount.

Ugh. That was an intermittent problem which we thought we had fixed. Looking into it now.

Not sure how much you care, but it may be worth hiding your nginx version[1]. It's just as easy as adding

server_tokens off;

to your http section of your nginx.conf

[1] http://wiki.nginx.org/HttpCoreModule#server_tokens

Your subscription model doesn't make sense to me. For the cost of a year ($1188) you could pay someone to setup your own VPN using open source software and not be limited to 5 users. A simple user license scheme seems to be more applicable.

I also don't get the comparison to CloudFlare. CF is a proxy service that optimizes and protects your site from attacks. A VPN provides a secure connection between computers. The only thing that's the same is that they're both security related.

Edit: After re-reading the article, looking at the site, and comments I realized I've misunderstood the service. The TC article made it sound like you were just selling VPN software. Now I understand that you're acting as an intermediary server, allowing clients to connect without setting up their own. It's an interesting idea but my first question still stands. Why not pay someone to setup a server for you?

We are intentionally trying to avoid the $10-40/mo "privacy VPN" market. There is endless abuse and pain running it. I've run remailers, talked to FBI agents when they were potentially going to do bad things to me, etc., and am trying to avoid being in that position again. Setting a $100/mo floor pretty much puts us in the business/group range only, which has vastly less abuse.

Within that goal, we're looking at various pricing options, and additional bundled or a la carte services (DLP, logging, backup, etc.). $99/mo is just intended to communicate that if you want a single user VPN to use BitTorrent or IRC, you should look elsewhere. (I'll probably put up some Tor nodes again on separate networks to contribute to the "freedom of information" market)

The CloudFlare analogy is kind of a stretch, but the idea is that they do magic stuff to your front end customer traffic, and we do magic stuff to your back end internal user traffic. They're performance and security (mainly availability, some other security); we're manageability and security.

As for why you'd use a service vs. setting up a server and running it yourself, different users have different internal support costs for different things. I run my own services for some things. I use providers for others. Most businesses are generally happier buying a packaged service vs. paying someone to configure something custom and put it on a server and maintain it. It really depends on the environment.

The TechCrunch folks are very cozy with CloudFlare, so anything even remotely mentioning security also gets a CF plug.

I specifically mentioned CF when talking to the writer, though. (I love the CF product, and thought it would be a good way to explain network services overlaid on top of existing network links and traffic, just internal vs. external)

Congratulations.

What's the protocol here?

SSL VPN to clients, ipsec tunnels to Amazon AWS and other providers. This seemed to be the best overall performance/reliability on the networks we used.

Came across Ciphergraph (http://www.ciphergraph.com/) at Microsoft accelerator demo day on Jan 11th (http://www.microsoft.com/en-in/accelerator/Accelerator_compa...).They offer solutions in cloud security. Their VPN offering looks similar to CryptoSeal. Good that consumers have more choice in this space.

Looks great.

Curiosity has bit me, so a question:

Have you done any testing regarding the 'cryto/security' space and the dark color theming? I know that dark themes are all the rage but I've always noticed that many people think of 'cryto/security' stuff as a dark, evil topic used by hackers and the like. I'd be curious to know if a more upbeat, lighter theme would have an impact on conversion. "Bringing security into the light" or whatever.

Mostly it is that we suck at graphic design. If anyone wants to redesign the site, we would be totally open to it. (our three founders are me, bifrost, and cyber -- bifrost is a network and freebsd guy, and cyber is a c/network programming/netbsd guy).

I personally like the style of GitHub more than virtually any other site.

I'm developer who isn't great at design myself.

I'm looking at this from the perspective of someone who works at a startup with a fair number of people whom are non-technical (primary developer who gets stuck with IT stuff as a result type situation). I've pushed security best practices on them in various forms to various levels of push back. I'd love a simpler way to get them to use VPNs for various functions, something simpler than sending them single use download links of openVPN installs with their security certificate embedded. This seems like it would help with this, but I can see that would get pushback on the site theme. e.g. "Is this really what I need to sign up for?" e-mails with a screenshot attached.

I'm not trying to be too critical and I hope you don't take it that way. Just trying to provide some feedback based what issue I may have with implementing your service.

Yeah, that's a totally valid argument, and helpful. Probably will prioritize a better public-facing website (and a beta invite which doesn't for some reason fail non-deterministically, and gives no visual confirmation that it's accepted the submission...) Also doesn't work at all on iPhone or anything else that requires scaling.

Fantastic! Definitely useful for a lot of high-security use cases. We'll look at offering this to our customers as a guarantee for our highly confidential work.

Looks interesting... Am I correct in understanding that you guys would be the central party in the VPN?

For example if Alice and Bob are both using CryptoSeal Connect then network traffic flows like this?

[Alice] <==> CryptoSeal <==> [Bob]

Also, small typo "We deploy mobile cleint software ..." under "Many Clients Supported". Otherwise nice site (I especially like the "seal" :D).

Yeah. We're primarily positioning this for a group of developers or other users who want access to internal resources, like AWS servers or potentially any SaaS application we support (would love to set up tunnels to internal-use tools like Salesforce).

All of your traffic goes via us to your servers. This isn't ideal from a privacy perspective, but does allow IDS, DLP, etc. filtering. It's a tradeoff.

I wouldn't do it, personally, for individuals. For businesses, however, a contract with a service provider to do this kind of thing is totally reasonable. You still can use ssh/ssl/etc. on all of your traffic to your servers. This protects lower-value stuff and/or is belt-and-suspenders.

I've been looking for something like this for our product (SaaS database client, shameless plug: http://www.jackdb.com/) as security during network transit is obviously a big deal. At the moment there's is no explicit SSL/SSH tunnel so it relies on the underlying driver to handle.

Being able to plug into something like this would be useful if it can automate/offload the client side VPN setup and simplify things for a client adding a new connection.

> We deploy desktop client software which is fully supported on Windows and Mac OSX, and works on Linux, FreeBSD, and most operating systems which support Java.

You have a desktop VPN client in Java. But, but... why? I'm not trolling. This is such an unconventional choice of language for a VPN software, most of which is written in C or C++. Java is pretty much like going with Perl or Ada.

That will be fixed at some point in the future; it's java as a fallback after that. We have a way to do native OS on Android and iOS, and can potentially do the same thing on Mac/Windows.

Linux/FreeBSD/etc. are likely to remain java for a longer period.

I hate Java, myself.

Delighted to see this emerge.

Unsexy and brilliant. I wish I understood your market more, but my only contribution is to say that an old client called me just today asking about VPNs and I bumbled around trying to sound knowledgeable. One swallow does not a summer make, but I have a feeling this is going to do well. Good luck.

IMO VPNs are a lot like backups, source control, etc. -- essential, but a pain to deal with. Then a company like GitHub happens and turns what used to be hellish pain into one of the best experiences on the Internet.

Absolutely spot on. Although I'd say Github is fairly symbiotic with Git itself - a tech leveraged by a brilliant service which pulls in more adopters to the tech. I don't know if there's something similar with VPNs.

This is awesome and along with CloudFlare a good reason for something like YCombinator to exist. Institutions can protect people from a government that makes it hard to run services like this. It's still risky but beats going it alone.

beta signup fails - http://www.cryptoseal.com/beta/thanks

This webpage has a redirect loop The webpage at http://www.cryptoseal.com/beta/thanks has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Yeah, we fixed that, thanks. (it was many levels of redirects to support cloudflare SSL and to try to keep www totally static, despite using django to generate the templates. None of us are really web front-end people.)

Totally looking to grow the team -- will probably post HN job ads shortly. Essentially we need a good front-end person (not necessarily great at front-end, like would be needed for an end-user consumer product, more generalist preferred), ideally python, who is basically familiar with security and wants to learn more -- and more back end/networking/security developers always.

(We're in the SF Bay Area, but seriously looking at a non-bay-area secondary office -- WA/TX/NV or maybe BC, in a few months.)

We're pretty good for "hiring from our network" on back end people, but not as good for front end/web tech. Even if someone isn't a fit for us, I'd love to talk to people and could maybe think of other places which would be interesting. [email protected].

Congratulations on this.

I particularly like the clear straightforward wording on your website, which lets people know exactly what they can expect.

Congrats! My hat's off to you, I used to work on a managed VPN service and I know it's a lot of work.

It should be Garry Tan but that's par for the course for TechCrunch.

They typoed "CryptoSeal" in 4 different ways in the first draft online.

Sounds like this could be a sweet niche :) Congrats!