Show HN: Twingate – A modern solution for remote access
1–10 of 52 posts
Re: Show HN: Twingate – A modern solution for remote access
#2Hi 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
Re: Show HN: Twingate – A modern solution for remote access
#3Very cool! How does this compare with Tailscale which utilizes Wireguard under the hood?
Re: Show HN: Twingate – A modern solution for remote access
#4This looks very interesting might give it a try instead of our current vpn
Re: Show HN: Twingate – A modern solution for remote access
#5Very 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
Re: Show HN: Twingate – A modern solution for remote access
#6How does it compare to Gravitational Teleport?
Re: Show HN: Twingate – A modern solution for remote access
#7Sounds super cool. How many concurrent connections can each connector support?
Re: Show HN: Twingate – A modern solution for remote access
#8How 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.
Re: Show HN: Twingate – A modern solution for remote access
#9I'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.
Re: Show HN: Twingate – A modern solution for remote access
#10Sounds 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