Show HN: Twingate – A modern solution for remote access

The real raison d'etre with these new wave of commercial NoVPN products like this one and Tailscale is to build a high margin SaaS business without really having the infrastructure liabilities of SaaS businesses. The problem with these kinds of products is that they are, from a security perspective, a disaster. Not only your entire network is compromised if they get hacked or if even they want to get into your network whenever they want which is an unlimited power I've never seen in any SaaS product, also your network becomes prisoner to their services, so if their services go down for any reason, you and everyone in your network will be unable to connect to your network even if it's perfectly working.

At least Twingate doesn't try to do sanke oil advertising like Tailscale and sells itself as an "open source" (go have a look at their Github open issues, it's a complete disaster) while it is not. Also the other thing is, if you have a relatively small company of 50 people you will end up actually paying MORE than those seemingly overpriced yet established products like Zscaler ZPA.

For me, the only serious alternative to expensive products like ZPA are Zerotier and Pritunl. They are as transparent as open source yet still viable as businesses without being greedy or captive to VC money to extract every single dollar out of you.

These are all valid points, and we’re keenly aware that trust is central to our offering. On the subject of trust, I’d love to get your take on my response to hlieberman’s comment as I agree that it’s very important.

On the pricing front, our goal is to make the service cost-competitive when you take into account the positive security externalities, but in particular the huge time sink that teams and companies put into deploying, distributing and managing a typical VPN solution. This is a big reason why we’re so focused on ease of use.

Re:BeyondCorp, I brought it up as a comparison point in my blog post, but I don’t want to appear to be making claims that our product is currently a 1:1 BeyondCorp replacement. One of the next things on our roadmap is to start exposing device inventory and posture checks as management options in the product to start getting closer to a full BeyondCorp-like offering.

However, a key insight we had in working with early beta customers is that there is significant pain to address even without getting all the way to a full zero trust / BeyondCorp state. That’s a big reason we decided to launch our product now, even before we’ve had the opportunity to add functionality we know will need to be added in the future.

Hey, great question, and your setup seems very secure, but I’m sure it would be nice to reduce some of the overhead. The right way to support your ephemeral bastion use case with Twingate will ultimately be to use a public API that we plan to launch later this year. That will allow you programmatically deploy connectors as needed.

However, I’d also question whether you even need your ephemeral bastions anymore with Twingate. A big part of the value is that you can do away with any public entry points (even if they are secured as well as you’ve described) and very tightly control who can access hosts on your deeper network. Do your bastions do more than provide access points? For example, session auditing is pretty common.

I saw one or two as well, but they seem to be disappearing even with "show dead" on?

Thanks! One of the things that we've really focused on is making Twingate super, super easy to deploy.

From all of our customers conversations we've found that despite acknowledging that a better approach to remote access is possible, most people are really turned off by how hard it seems to be to implement a "zero trust" type solution. Our product goal is a 15-minute deployment, and our initial customers have been really excited about how easy it is to start using Twingate. One of the biggest selling points is that users can keep using the same addresses (either DNS or IP) for their resources with zero application, network or device configuration changes. That's a huge difference compared to every other product that's out there.

As far as the underlying technology is concerned, we're entirely standards-based with all transport encryption done via TLS. In fact, the name "Twingate" comes from an architectural decision that we made to ensure that multiple authorization checks are performed for every single network connection request.

If you'd like to dig more into the details, I'd definitely encourage you to read our "how it works" documentation here: https://docs.twingate.com/docs/how-twingate-works

Our general approach is to rely on widely-used delegated trust mechanisms (eg. OAuth, SAML, CAs, etc.) and from our perspective the more of that we can do the better, as it helps decentralize control mechanisms and improve overall security. Ultimately, you’re absolutely right that it comes down to trust, and we’re very aware of that.

Like most aspects of security, it’s about assessing the tradeoffs involved. From our standpoint, our interests are completely aligned with our users—earning their trust by keeping them secure benefits us, too. When you compare that to the security risks inherent to VPN (implicit total trust of devices, granting access based on joining a network, etc.) for the complexity of remote access today, what we’re hearing from our initial customers is that it’s a no-brainer.

The best analogy I can think of is Okta. Theoretically, Okta could arbitrarily authorize access to any of your internal applications, but from their customers’ standpoint that potential risk is vastly outweighed by the additional security benefits afforded by SSO.

That said, we definitely want to keep doing everything we can to improve trust in our product. One idea we’ve discussed is allowing our customers to have complete signing authority (on hardware/service entirely under their control) over all tokens in our system. As an example, would that go further to address concerns around trust from your perspective?

Totally! We've seen some nightmare configurations around separating dev/staging/prod environments involving scripts to change /etc/hosts back and forth and some funky VPN configurations.

This is such a common use case that we wrote up a brief description of how to approach this: https://docs.twingate.com/docs/access-control-for-staging-en...

Twingate integrates with the existing Identity Provider used by that company to authenticate users. So you'll be redirected to that IdP upon your first start of the client.

[p.s. I'm one of the engineers working on Twingate.]

There are similarities in the general approach, but the two biggest differences between us and Teleport are:

1) We support native clients on every major platform (Mac, Windows, iOS, Android and Linux support just a few weeks away) which makes it super easy for anyone in a company or team to gain access without being limited to Linux.

2) Twingate natively proxies any TCP or UDP traffic and we don't care what the underlying protocol is. This is huge given that most teams are using a variety of client applications, protocols and destination servers.

Good question! At the absolute limit, connectors are CPU-bound, but it's unlikely that you would hit a CPU limit before you exhaust all available file descriptors or network bandwidth unless you're using a very under-powered host.

There's a couple other things that help, too:

1) We allow clustering as many connectors as you'd like to help you scale as usage patterns or application needs change. (This tends to be a big problem with VPN as deploying a new VPN gateway is a fairly heavy lift.)

2) Contrary to VPN deployments, which bottleneck all traffic through a single or small number of VPN gateways, our best practice recommendation is that you deploy as many connectors as you have network segments, which also helps spread out network load across multiple connectors.

Because connectors are quite different to VPN gateways, we wrote up this comparison article, too: https://docs.twingate.com/docs/understanding-access-nodes

Currently, yes, we’re focused on connecting users with services, but there’s nothing inherent to the underlying technology that prevents us handling service to service communication in the future. This is a common request, and along with a public API that we plan to release in the future, we think we’ll have a very flexible solution for your use case down the line.

This is our very first public launch, and auditing/analytics are next up on our roadmap! Just to be clear, we do not currently and do not plan to intercept any traffic—any client application connections remain encrypted inside of our TLS transport tunnel. What we will be providing is connection-level analytics for Twingate traffic flowing through connectors you deploy on your network. For example, connection start and end times, which authorized user accessed the destination resource and how much data was transferred. How would that fit with your needs?

By the way, this is similar to Cloudflare Access, but we’re protocol agnostic (any TCP or UDP traffic can be proxied) and we don’t require you to change or create any public DNS entries. In fact, our best practice recommendation is that you exclusively use private DNS to cloak your private network.

The most important factor in this decision is maintaining separation of concerns between user authentication (identity provider) and network authorization (Twingate). Since we rely on an identity authority for access, if the user--or an attacker--is unable to authenticate themselves, we can't allow a network connection to proceed, keeping the destination resources safe. This is even more important for customers using an identity provider like Okta, allowing them to continue managing all of their users centrally.

And tailscale and even original BeyoundCorp from Google (which they released several weeks ago). I believe the amount of solutions is reflecting the market need.

I don't work for twingate, but I know several guys who do. From the chat with them, I understood it installs transparent proxy to your client, and forwards all the traffic to specific destinations through access nodes over the TLS tunnel. In case specific route is not "white-listed" - it asks for authentication/authorization. Basically instead of having one point of authentication e.g. VPN gateway, you may have several specific for resource, you don't need to play with routes and have a good internet connection while connecting to the services you care through secure connection.

The Linux version will be available soon.

VPN has one important limitation - it either provides you with default gateway and all the traffic goes through your VPN node, or you need to maintain and play with routes in order to prevent this. Another limitation is - as soon as you passed the VPN GW - you are "at home", and can access anything you like. Twingate provides you with the possibility to avoid VPN gateway for everything except for specific "access points" which are close to the sites you would like to limit access to. They also check the endpoint client attempts to connect and if the client doesn't have permission - it got rejected. Even though it can access other available resources through the same access point. You can have many "access points". I believe they use some proprietary protocol (which is bad if you ask me), I could not find any security audit on their site about the protocol. From the other hand, according to the documentation they use TLS, which is good. I believe WireGuard could be a better use here because it is OpenSource and widely used by big players. On the other hand, TLS is used even more, but I would like to get some security audit results.