Twingate review

Do you have large teams working remotely right now? If that’s the case, there’s a good chance you or your teams are using a corporate VPN to connect to the company’s IT resources.
If your teams are working remotely, all of their personal traffic is also flowing through the company network. VPNs tend to be configured to route all of the traffic coming from the device running the VPN client through the VPN gateway. VPN traffic is then decrypted at the endpoint before being sent off to the internet, so personal traffic is not private on a corporate VPN. That creates a privacy issue for remote staff and a bandwidth hog for network admins.

VPNs are quite useful, but that doesn’t mean that VPNs are the perfect solution in every use case.

What if your teams could use a VPN that provided direct access to the network resources you need instead of going through a centralized gateway? How about a VPN that could automatically segregate personal and professional traffic and only route the professional traffic through the company servers? And what if the client software was easier to understand and to use for your users, cutting down the amount of time IT support has to spend on end-user issues?

Well, it exists. And it’s called Twingate. There’s just one catch: it’s not actually a VPN…

Twingate Summary

Twingate was founded in 2019, when Tony Huie, Alex Marshall, and Lior Rozner, formerly at Dropbox and Microsoft, came together to build a product that would procure the access typically provided by VPNs while fixing many of the shortcomings typically associated with VPNs. Twingate does this while enhancing your organization’s network security and reducing bandwidth. And with the new normal of working from home, we suspect more than one organization could benefit from it.

What is Twingate?

Twingate is a cloud-based service that provides secured remote access to an organization’s networks. So its function is very similar to a business VPN. But Twingate achieves this more flexibly and securely than a traditional corporate VPN, thanks to its granular access control policies and the fact that Twingate does not use internet-facing gateways.

Pros & Cons

Devices

Twingate provides native client applications for the following platforms:

• Windows
• macOS
• ChromeOS
• Linux
• iOS
• Android

The Twingate client app is extremely easy to use. And once connected, there is no reason to interact with the client app. It simply runs in the background. More on that below.

Twingate Pricing

Twingate offers four subscription plans, including a free tier.

• Starter – Free
• Teams – $5.00 / user / month
• Business – $10.00 / user / month
• Enterprise – Custom pricing

All of the paid plans can be purchased on a monthly or yearly basis. On a monthly basis, the Teams and the Business plans are $6.00 and $12.00 a month per user, respectively.

There is no pricing information for the Enterprise (custom) plan. For that, your organization needs to get in touch with Twingate.

All subscriptions come with a 14-day money-back guarantee.

How Twingate works

Let’s look at Twingate’s main components to gain a better understanding of how the service works.

Twingate consists of four main components: the Controller, Clients, Connectors, and Relays.

To understand the way it works, we’ll provide two examples.

So, in our first example, an end-user running Twingate on their laptop from home makes a request for company resources.

So the Twingate client detects that the request is for a company resource and sends that request to the Controller. The Controller checks the user’s permissions and the Connector’s access policy. If everything checks out, the Controller grants the request and forwards it to the Connector. The Connector then validates the client connection, resolves the DNS request and grants access to the requested resource via the Relay, over a TLS tunnel.

For our second example, an end-user running Twingate loads up a Youtube video in their browser.

In this case, the Twingate client detects that the request is not for a defined company resource and simply sends the traffic out the default route – over the regular internet. And that’s all there is to it.

So that’s how Twingate works. But what exactly did I just describe? Twingate is meant to replace a corporate VPN, without being a VPN. But what’s a VPN? A VPN is essentially a system-wide proxy with encryption. Whereas Twingate can be understood as being a set of sophisticated and centrally-managed proxy servers that provide encryption (TLS) and work together to achieve the remote access provided by VPNs but with more granularity, control, usability, and security.

Granularity & control

One of Twingate’s benefits is the ease with which IT departments can set up user permissions.

While it is possible to achieve granular control over permissions at the IP address-level with a traditional VPN (IKEv2 or OpenVPN, for example), it is rather complex and fairly cumbersome. And one would most likely need to add a proxy server to the mix as well as make custom modifications to the VPN configuration. It’s more work and multiplies the potential points of failure.

With Twingate, your IT department doesn’t need to change its infrastructure and can, from one central point (the Admin console), create granular access policies by enrolling users into groups that have fixed access permissions. This approach scales up or down much more easily than a VPN.

Ease-of-use

The above paragraph could tie into usability as well. But in this case, we’re talking about end-users. Commercial VPN software is easier than ever to use, but corporate VPN solutions tend to be less user friendly than their commercial counterparts. Part of the reason is that corporate VPNs need to cater to complex and distributed networks, which can make their implementation more complicated. And users, especially those that are less tech-savvy, can run into issues when using a corporate VPN client and they may not have a clue how to troubleshoot it – so they call support.

The Twingate client, on the other hand, runs transparently in the background and, once logged in, requires no user interaction whatsoever. And there’s no need for end-users to remember alternate hostnames or specific IP addresses to access remote resources with Twingate. That’s because when accessing company resources, the DNS requests are proxied and resolved locally on the remote network. So you can use the regular hostnames you’re used to and Twingate will route your request to the appropriate resource, regardless of which network you’re on.

On top of that, Twingate integrates with your SSO and identity providers. There is no need to create VPN credentials or any supplementary authentication. The supported SSO providers are:

• Azure AD
• G Suite
• Okta

Security

Twingate also provides some security benefits. First off, there’s no internet facing gateway to exploit, in contrast to VPNs. Twingate Connectors are deployed behind your organization’s firewall and only require internet egress permissions (outgoing connections).

Then there’s the fact that company traffic and personal traffic are always segregated over Twingate. It is configured for split tunneling by default, at the resource level. So Twingate will only route legitimate company traffic (as defined by your access permissions) through the company network. That means that if a user is ever compromised, the rest of the network, which that user did not have access to, remains secure.

This also has the benefit of reducing the load on the corporate network and keeping the experience snappy for end-users, as their personal traffic goes out to the internet directly.

And if we look at the other benefits we’ve listed above: ease-of-use, granularity, and control, we can see that they all indirectly enhance security. Complexity is harder to manage and more error-prone.

The experience

The folks at Twingate were nice enough to set me up with a demo account with access to both the end-user side and the admin side. Let’s look at both experiences.

End-user

When you launch the Twingate client for the first time, whether on macOS, Windows, Linux, ChromeOS, iOS or Android, you’re first greeted with a privacy notice (the screenshot is of the macOS version):

I find this thoughtful on Twingate’s part and I appreciate the transparency of its privacy statement. But remember, Twingate’s mission is to provide secure access to company resources. So of course there’s going to be some data collection going on. The nature of the service requires it to have visibility into what’s happening over the networks it operates on. And your company (Twingate’s client) may task Twingate with collecting various information on its behalf. It’s your company’s network, after all.

The point I’m trying to make here is that Twingate and commercial VPNs don’t share the same goals. So we won’t be rummaging through Twingate’s privacy policy. While privacy is important to Twingate (as its privacy statement makes clear), it is not a personal privacy product and the nature of Twingate’s mission requires more data collection than a commercial VPN.

Once you click Continue, you’re prompted to enter the name of the network associated with your Twingate account. This would be configured by your IT department when initially setting up Twingate. And as an end-user, this would be emailed to you. The network name is in the form <network name>.twingate.com. There is no hard limit on the number of networks you can access via Twingate.

Once you’ve entered the network name, you’re prompted to sign-in using one of the following authentication services:

• Google
• Microsoft
• GitHub
• LinkedIn

Once that’s done, you’re connected to the network you entered into the client app, and the client app disappears. From now on, it’s tucked away in a menu bar applet. And there’s really no reason to interact with it unless you want to disconnect from the network or quit the app.

So what happens now?

Now, as an end-user, I can just go about my business. If I need access to a company resource, I can just go ahead and access it, from a web app, via ftp, SSH, whatever. It’s as if I was sitting in the office, on the company network. Again, no alternate hostnames or IP addresses required. Just access your assets in the way you’re used to.

The requests that go through the Twingate tunnel are defined by Access Control Lists on the admin side. These will typically be to company resources, but it can be anything. So on my demo account, the website https://www.whatismyip.com/ has been defined as a destination that should be routed through the company gateway, which has been defined as one of the resources on the network to which Twingate grants me access. A resource, within Twingate, can be anything: a gateway, a server, a folder, a file.

Now while I’m connected to Twingate, if I enter that URL into my browser, I’ll see the IP address of the company gateway.

If I go to Comparitech’s IP address check tool, I can see my ISP-provided IP address. That connection was direct because it was not defined as a Twingate destination.

When Twingate routes traffic through a company gateway, it acts a lot like a commercial VPN, where your outgoing gateway to the internet and hence your IP address is changed to that of the server. But whereas a VPN would typically send all of your traffic over the gateway, Twingate enables you to define what goes through and what doesn’t very granularly. And this also has the benefit of enabling IP address whitelisting. If every client request for a resource has to go through the company gateway, then every client request will appear to be coming from the same IP address. And so, on the admin side, you can whitelist that IP and only allow connections from that IP address.

If I run a speed test while connected to Twingate, I should get my full ISP bandwidth as that traffic is direct. The speed test servers aren’t defined as a Twingate resource and hence aren’t routed through the Twingate tunnel, so my direct internet connection remains fast. From an end-user perspective, this makes the Twingate experience snappier than a typical corporate VPN.

Over Twingate, anything that isn’t accessing internal company resources stays direct. So a VOIP call with a third-party doesn’t need to be routed through the company gateway and hence can be made direct, fast and lag-free.

This has the double benefit of keeping your connecting snappy and fast while preserving bandwidth on the company network.

Another cool thing that Twingate allows is for custom domains, as defined by your organization, to remain resolvable. Because the DNS requests to company resources are proxied so that they’re resolved locally on the company network, any internal domains that are only resolvable using the company’s local DNS server will still resolve over Twingate – just as if you were sitting in the office.

So in my demo account, the local DNS server on the remote network I’m connecting to via Twingate can resolve the “.int” extension. So if I have a presentation sitting on my organization’s servers at http://business.prod.beamreachinc.int/, (and my demo account just happens to) I can simply type that link in my browser and access the presentation, regardless of my local DNS server setting.

Admin

Let’s look at the admin experience, now.

In order to access the Admin console, you, of course, need an admin account. Then, you can sign-in by accessing the URL of your Twingate network (the same one we used to configure our client) in a browser and signing-in, just like an end-user.

Once signed in, you’ll see the main dashboard.

At the top, we have four tabs: Network, Users, Groups, and Settings.

• The Network tab is where you define your remote networks and resources and where you deploy your connectors.
• The Users tab is where you define your users.
• The Groups tab is where you define your groups and their associated access permissions.
• And the Settings tab essentially gives you high-level information on your account and its configuration.

Under that, we can see our team name – demotech, in my case, and the address of our network underneath.

Below that, on the left, all of our defined resources are listed. And to the right, all of our defined remote networks are listed.

Clicking a remote network displays the connectors deployed on that remote network as well as its associated resources. So for the AWS-IP Gateway remote network, we have two connectors and one resource. Twingate recommends that two connectors be set up for each remote network, for failover and/or load balancing.

Twingate containers are deployed on your remote network as linux/amd64 Docker containers, behind your network’s firewall.

Access to remote networks and resources is managed through users and groups. Users are divided into groups. And groups have defined access permissions. By enrolling a user into a group, you’re also defining the access permissions of that user.

So if we look at my user here, we can see that I’m part of three groups: Engineering, Everyone, and Finance.

If we look at the Engineering Group details, we see that it grants access to one resource: the Source Code Repository.

Any user you enroll in the Engineering group will be given access to the Source Code Repository resource through Twingate.

We also see an Access Policy field. The access policy relates to the way you authenticate yourself using your login credentials (Single-Sign-On, multi-factor authentication, for example).

This setting is dependent on your organization’s identity provider and is configured by your IT department. Social is the default.

So the Admin console provides IT admins with a clean, clear interface that enables  granular control over access to resources with a simple, easy to use GUI.

Do I recommend Twingate?

Absolutely. It really does remove quite a few pain points from setting up secure remote access for businesses and their workforces. It enhances organizations’ network security and reduces bandwidth usage while simplifying deployment and end-user support.

And in my tests, everything just worked. No lag, no disconnects. And it segregated my traffic flawlessly.

The only downside I can see is the following:

By using Twingate, you’re entrusting potentially critical infrastructure to a third-party. This is common practice today. But so are breaches. By granting third-party access to your network, you put yourself in a situation in which if the third-party gets hacked, you get hacked. This is in no way exclusive to Twingate. It’s simply something to think about.

Tied to the above (third-party access) is the fact that if your company has stringent security requirements, it may prefer to build its own remote access solution from scratch to keep visibility into the network “in the family”. I doubt this would be the case for a very large number of businesses. But I could see this potentially affecting companies fulfilling government contracts, for example.

Other than that, Twingate takes the headache out of working from home, for businesses and users (and it really is simpler to deploy than a traditional VPN server). Highly recommended.

See also:

• Best corporate VPN solutions in 2024
• 6 Best remote access VPNs
• Using cloud VPNs for business
• How to set up a secure remote access VPN