
Show HN: Twingate – A modern solution for remote access - alexmensch
https://www.twingate.com/blog/introducing-twingate
======
schoolornot
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.

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

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

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

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

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

~~~
alexmensch
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?

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

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

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

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

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

------
alexmensch
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](https://docs.twingate.com/docs/how-twingate-works)

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

~~~
alexmensch
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](https://docs.twingate.com/docs/how-twingate-works)

~~~
microcolonel
> _...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?

~~~
alexmensch
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.)

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

~~~
alexmensch
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?

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

~~~
alexmensch
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...](https://docs.twingate.com/docs/access-control-for-staging-environments)

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

[https://docs.twingate.com/docs/download](https://docs.twingate.com/docs/download)

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?

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

------
sansnomme
How does it compare to Gravitational Teleport?

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

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

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

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

~~~
alexmensch
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](https://docs.twingate.com/docs/understanding-access-nodes)

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

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

------
lasdfas
This looks very interesting. Very similar to Cloudflare Access. How does it
handle auditing? Is there an ability to log SSH or HTTP traffic?

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

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

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

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

------
httgp
The logo seems very similar to Hashicorp’s Packer.

------
techload
Why there is no option to sign up with email?

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

------
miniman1337
Seems like an alternative to Pritunl Zero

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

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

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

~~~
iojin_z_bajin
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).

------
el3ctron
no linux version? good bye!

~~~
iojin_z_bajin
The Linux version will be available soon.

