* 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.
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.
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.
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...
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.
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.
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.
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.
Nice to see that things cleaned up pretty quick, so thanks to whomever did that.
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
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
Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?
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?
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...
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?
[p.s. I'm one of the engineers working on Twingate.]
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.
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
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.
 "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).