Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Twingate – A modern solution for remote access (twingate.com)
156 points by alexmensch 36 days ago | hide | past | web | favorite | 48 comments

A few issues I have with these NoVPN products:

* They are entirely proprietary or are proprietary extensions on top of open source software

* The clients are mostly proprietary and the distribution channels are limited. I'm guessing no .DMG is offered for macOS due to Apple's insane restrictions on OS-integrated VPN clients.

* There is usually a hard dependency on the provider for the connection, negotiation, or key exchange with no uptime guarantees.

* Pricing is not competitive with the alternatives including proprietary offerings from the big clouds.

* They all cite "Google BeyondCorp" without an understanding of what it is. Hardly do any of these products offer anything to do with inventory, device health checks, or MDM.

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.

The modern solution for remote access is to move all of your business systems to the web, employ TLS1.2+ with strong cipher suites, and enable MFA as appropriate.

We already have 100% of our business systems for 1 project using web-based access. This makes ramping new employees and doling out restricted access so much easier. If you give someone VPN access, you need to hire a full time guy to manage that bucket of pain if you want granular per-user permissions at the network-level. Web has no such problems. Everything is typically a completely independent security context in terms of network for any layer below HTTP. VPN means you have ~layer 3+ access by default to everything on that network.

There is an argument to be made for "XYZ doesn't have a web interface/API". But, I pose that this is a weak argument in 2020. Every cloud provider can be automated 100% via API calls. Every single thing you can do on the GitHub[Lab] web UI can be automated. Even if there isn't an explicit API, you can automate literally any legacy application with some mild scripting and duct tape. I've seen automation that samples a 3d application output in real-time and checks pixel colors for eventing, so I know this can be done. Bonus points here because these are typically legacy static and never-changing systems so you can code for it 1 time. There aren't really any excuses in my shop for manual labor. Setting up a new public webapp that can 2FA your employees and provision cloud resources via the AWS JSON API is not hard. You can make it hard, but you can also make it very very easy if you just focus on the value angle. Once you build one of these things, the next one takes 1/10th time time because you know how to do it. Maybe you just add a 2nd navigation option to your 1st one to manage that additional system...

We currently use a mildly exotic "temporary bastion" approach, where upon request / approval a dev can get a container launched. The container is launched on ECS running an ssh server, pinned to the dev's individual public key, and that container has the appropriate security groups / IAM roles to access various production resources.

Right now, a dev will 1) VPN to get shallow network access and 2) SSH over VPN to get deeper network access through the bastion container. Something like a database is security group'd off so that you need to be on the bastion container to access.

My question - would Twingate be able to support an ephemeral use case like this? I'm thinking ideally it can be launched as a sidecar container, and a dev could SSH through the twingate container. A lot of solutions I see don't seem to handle ephemeral situations super well, so I was curious.

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.

Can you explain how this is more secure than SSH to a bastion host via an out of band network?

Could you clarify a bit on "out of band" in this use case? In principle, if you have a way to access your bastion on a completely private--maybe physically separate / leased line--network, then that's going to be extremely secure, but maybe you had a different use case in mind?

Out of band could be as simple as ngrok, or cloudflare Argo - or as you suggest by a separate connection.

SSH is two factor - key + password and Argo,ngrok,wireguard to a VPS provide DDoS mitigation and attack surface concealment and reduction.

I think I’m missing what your product adds.

Gotcha. In your example: nothing. We're okay with that. The level of security that results from the setup you described is what we are hoping Twingate will bring to people with convenience and ease of management built-in. I'm always amazed at the very wide range of sophistication that different teams and companies approach security with, and very, very few companies are at the level of your example. That's what we're excited to help change with this new product.

So does anyone else notice the number of pro-twingate comments on this submission with accounts that have under 5 karma?

Like I want to try new things, but this entire comment thread seems to be full of astroturf and spam. And if that was something that was done as part of this launch and post then I have ethical questions about the product.

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

Yeah, seems like they are going away- that's pretty funky. Wonder if they posters removed them or they were flagged?

Nice to see that things cleaned up pretty quick, so thanks to whomever did that.

Hi everyone, I’m one of the cofounders of Twingate. Excited to share with the HN community what we’ve been working on over the last 18 months.

Twingate is a modern solution for remote access that replaces your VPN. It’s designed to address the underlying security issues with a traditional VPN + network perimeter, but it’s super simple to deploy, manage, and use. It introduces “zero trust” concepts like least-privileged access controls at the application level, hiding public attack surfaces, and continuous network authorization, but without the complicated change management typically required to get there.

We’ve particularly focused on making it work seamlessly for developer workflows & tools, so excited to hear what you all think. You can try it out for free today.

You can read more about how the underlying technology for Twingate works here: https://docs.twingate.com/docs/how-twingate-works

Very cool! How does this compare with Tailscale which utilizes Wireguard under the hood?

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

> ...with all transport encryption done via TLS...

Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?

The client (the Twingate app on the user’s device) actually runs a transparent TCP proxy, so we’re just forwarding TCP payloads to the connector at the other end of the tunnel. This avoids the “TCP meltdown” problem of a TCP-in-TCP connection and also why we support any higher level protocol without any special configuration. (By the way, the client also runs a transparent UDP proxy.)

Love this mission statement. I hope to never wrestle with VPN ever again. Good luck!

Is it correct that the Twingate systems have all the necessary credentials to grant arbitrary access to your resources?

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?

I've found that it's a good way to restrict access to testing/staging/dev environments. way easier to set up and manage than a vpn imo.

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

Is it just me, or do the installation instructions for the client really say you just enter a company name..... No other user/pass/key


To me that reads that I could just pick a known company using your service and get right in. What's going on here folks?

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

How does it compare to Gravitational Teleport?

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.

In general it seems convenient to configure; but in terms of operation how does it really differ from connecting your services as clients to a VPN LAN? With WireGuard for the tunnels themselves, you can even have as many routers/"relays" as you want, with virtually no overhead.

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.

Sounds super cool. How many concurrent connections can each connector support?

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

Does this in practice restrict to connect workstations/humans with services - or is there support for allowing services to talk to services too?

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 looks very interesting. Very similar to Cloudflare Access. How does it handle auditing? Is there an ability to log SSH or HTTP traffic?

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.

VPN is not Windows 95 and it has been evolving. Also it is not so difficult to manage a secure vpn setup.

Congrats to Alex and the team. Been super hard work for them and really pleased to see how this is working out!

This looks very interesting might give it a try instead of our current vpn

The logo seems very similar to Hashicorp’s Packer.

Why there is no option to sign up with email?

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.

Seems like an alternative to Pritunl Zero

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.

read the whole page, still don't understand how it works or what it does.

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.

Note that only "white-listed" [1] traffic is going through Twingate network. Regular user traffic (public resources) is proxied to the respective data sources directly from client devices.

[1] "white-listed" resources are basically protected (restricted) resources that are accessible to a specific Twingate user. Different resources may require different authentication methods (e.g. basic SSO vs. MFA).

no linux version? good bye!

The Linux version will be available soon.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact