VPN's are all the rage out there at the moment for either security your connection out on public internet or getting access to different Netflix titles in other countries the big players like NordVPN and ExpressVPN are spending a lot to advertise their services.

Historically however a VPN is a business enterprise tool providing employees a method while off site to get access to the corporate network. Its a single point of access which can provide access to services within a network which are not wanted to be public facing.

Disclaimer

I know I can't spell, read the text, get the flow.. 
Correct me if i'm factually incorrect, 
giggle at my spelling. 
Its the content which is important not the words.. 
If i had a copy editor this wouldn't be a problem 
but i'm not making money off this blog, its a personal outlet.

With that please note: 
Twingate have not offered any money for this post, 
They have not paid me or ask for the post, 
I have not taken any free upgrade for the service 
I've used the Starter Pack. 
Both Tony and Alex have reached out, 
and both been very helpful.

Recently I tweeted about Pritunl an Enterprise VPN which is easy to setup and gives a nice WebGUI for OpenVPN server and Wireguard. I was impressed by the ease of setup, reporting and it was genuinely simple to use.

I was tweeted back by the guys at Twingate and they suggested looking at their service.

The product has impressed me enough to ditch the Pritunl Blog post and focus on this.

Secure remote access for distributed workforces
Replace corporate VPNs with a more secure, usable and performant zero trust access solution

What is Twingate?

The website of Twingate states the service as..

Secure access to private data for your distributed workforce

Replace corporate VPNs with a more secure, usable and performant zero trust access solution

Which is a big statement, Zero Trust model was created in 2010 by John Kindervag and is explained as.

Zero Trust is a security concept centred on the belief that organisations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.
“The strategy around Zero Trust boils down to don’t trust anyone. We’re talking about, ‘Let’s cut off all access until the network knows who you are. Don’t allow access to IP addresses, machines, etc. until you know who that user is and whether they’re authorized,’” says Charlie Gero, CTO of Enterprise and Advanced Projects Group at Akamai Technologies in Cambridge, Mass.

What Twingate see as the issue with the standard Enterprise VPN model is over 3 areas:

An Exposed public gateway - VPN's work on known ports, and even when not they are a public point of a network which a bad actor can sue to exploit into your enterprise.

Difficult to Maintain - If you're a large well manned organisation keeping your security up to date and your VPN in order is part of day to day life. However as companies tend to run on low manned IT teams, and the VPN can be a scary thing to maintain, and its easy to take the "if it ain't broke, don't fix it" approach when there are other things which need looking at.

Lateral Attack Vulnerabilities -  Most VPN's allow access to a whole network and do not protect at an app level. So a bad actor if able to compromise that exposed, un-patched public endpoint they get access to the whole network or network segment and all the services within it.

So with all that in mind Twingate has looked to take a different approach to remote connectivity.

How does it work?

So how does this difference look from a high level perspective?

If the traditional Enterprise VPN model is looked at the endpoint, your laptop, has a client which connects directly to a public facing VPN, which may use certificates, 2FA and credentials to provide you access. This VPN then provides you access to Network segments which have services on them.

Usually (admittedly not always if you split tunnel) all your traffic will be directed through the company VPN so accessing the company servers or the internet, all the traffic will route through the VPN so the traffic can be logged and provides a perceived security benefit as well.

The Twingate model takes the public VPN endpoint away from your network and puts it in the cloud. So the Twingate client connects to an endpoint which is not your network. Twingate supply a connector which you run on your infrastructure and only reaches out to the Twingate host (No ports are opened from the outside into your network). the connector provides access to resources (services or applications) on your network.

Authentication is provided by okta or other 2FA services.

The primary difference is the concept of not having that public endpoint which you connect to as far from the public side of your network as possible. To not have your local network exposed using open ports and use a connector which calls out from your network to the Twingate services to provide the communication.

So far so good.

What do you host?

So these connectors, they sound like we are just obstificating the VPN endpoint out to the cloud, but I've still get to get a connection from the public Twingate servers into the company network using the Twingate Connector.

Twingates Documentation describes it as follows

Understanding Connectors
Whether you are deploying Connectors in cloud infrastructure or on-prem, they serve as the backbone of your Twingate network, allowing you to provide access to Resources to users anywhere in the world. This guide covers general recommendations that apply to any environment, and you will also find en…

Although Connectors have superficial similarity to a VPN gateway, there are significant differences in behavior that benefit security and management:

  • Connectors should never be accessible from the public internet. Connectors should always reside behind a firewall, within the private network that protected Resources are connected to.
  • Users never choose to connect directly to a Connector. Twingate instead connects users to Resources by routing them through the appropriate Connector behind the scenes.
  • Connectors do not ever allow users to join the private network. Instead, Connectors should be seen as narrow keyholes that only allow individual network connections to proceed to the Resources that users are authorized to access.
  • There is no downside to deploying Connectors on multiple private networks. Because users are never aware of the Connector a given connection is routed through, the number of Connectors does not introduce any additional complexity to users. This allows Connectors to mirror your network infrastructure without making changes solely to support remote access.

A more accurate way to think about Connectors is as sophisticated, centrally-coordinated proxies that never allow more than the authorized traffic to pass through them. Some differences emerge in how to think about deploying and managing them:

  • Name and address resolution is local to Connectors. When a user is authorized to access a protected Resource, name and address resolution of that Resource does not take place on the user's device, but is instead forwarded to the Remote network the Connector resides in. This means that users can use private DNS names and IP addresses to connect to Resources without needing to connect directly to the destination network.
  • Separate Connectors allow users to connect to multiple networks without updating routing permissions. It's no longer necessary to make network routing or infrastructure changes to support remote access use cases. Networks can be defined and segmented as dictated by best practices, and Connectors can be deployed within network subnets as needed to support access. For an example use case of this, see our Access Control for Staging Environments.
  • Connectors are automatically clustered and can be deployed to meet your changing needs. Connectors are software-only and automatically clustered for redundancy within the same Twingate Remote network. This allows you to add more Connectors as needed to meet changes in demand or usage.
  • Twingate enables very precise "split tunneling". Only traffic destined to Resources that a user is authorized to access will be routed to the relevant Connector from their device. This means that the only traffic flowing through a Connector is that which is destined for a Resource on the same Remote network.

How do you set that up?

The connector i've tried was the Docker Container variant, and was pretty simple to get setup

Define a new Remote network
The first step is to define a new Remote network. We will then deploy a new Connector within this Remote network to start providing access to Resources. You may already have one or more Remote networks defined from your choices during the sign up process. If you already have a Remote network defined…

There is a wizard based website to run through and its fairly self explainitory

Start by adding a Remote Network, this is the Name of the subnet you would be connecting to which could be a local network, remote network, dev, integ pre prod or prod network..

Click on the Remote Network you just added (the one with the red indicator)

Add resources to the Network, these can either be server IP/URL's or CDIR Formatted network (0.0.0.0/0 format)

You can add multiple resources. If the service on the server runs on a non standard port, thats ok you don't need to do the n.n.n.n:nnn format just the IP of the server. Zero trust dictates you should be firewalling the server the service runs on appropriately

Click on add a Connector and a new connector will be added to the page.

Click on Deploy a connector.

There are multiple options for deployment, the one i've used is the Docker image, to move forward with this click on Generate Tokens.

A set of random keys will be created to secure this connectors communication between your network and the Twingate servers. (remember the connector only ever calls out, twingate never calls in)

I added  the Local DNS Server on the remote LAN and then its a case of copying the docker command and running it on your docker server. As long as it has access out to the internet and the Twingate servers (firewalls setup right) The connection status should turn green in a minute or so..

At this point you are done. The next step is to get a client to connect.

How do you connect?

There are clients for Windows, MacOS, Android, IOS and Linux of which i've tried the Android and the Linux clients.

The Android client is a simple affair, you'll have setup users within the Twingate interface and provided an address in the <company name>.twingate.com format as well.

The user connects using the login service you setup in the Twingate interface and its kind of done from there. There is nothing to it.

The linux (Ubuntu at least) is installing a Deb package and using the command line

sudo twingate start
sudo twingate stop
sudo twingate status

I did reach out to the team and Twingate and suggest that having this in Network Manager would work a lot better

My assumption is the Windows, Mac and IOS Gui interfaces are equally as simple to setup.

Whats the speed like?

I'm in a situation where i'm able to run a quite good comparison test for Twingate against Pritunl and Wireguard VPN's i've got setup at home.

VPN FAST.COM Network Battery
None 4.9Mps Three 4G 2 Days Battery life
Twingate 4.9Mps Three 4G Have run all day
Pritunl (OpenVPN)  2.2Mps  Three 4G Drains
Wireguard  3.9Mps  Three 4G Can run all day
ExpressVPN  1.1Mps Three 4G Drains

While not a scientific study as my 4G does occasionally fluctuate its interesting the speed differences which are an average of 10 tests over a 2hr period.

What did shock me was the battery drain the Pritunal/OpenVPN client and the ExpressVPN clients are two things i tend to use on my laptop more than my mobile however they kill the phones battery. (Huawei Mate 20 Pro with 1 Sept 2020 software update)

I'd expect no lack of speed with Twingate to the internet as it uses split tunneling, so only send the traffic it needs to the Twingate servers and directs other traffic directly to the internet not its own servers.

Who are they?

Twingate was founded by Tony Huie, Alex Marshall and Lior Rozner and its team built their new VPN alternative by focusing on security and ease of management in the same way they did while building products at Dropbox and Microsoft.

I've spoken to Alex and Tony on Twitter and they are great guys who really want to build a good product.

They have a good overview of their security and their Service Reliability on the following pages. Security seems to be at the center of the product.

Twingate Security
Introduction Twingate helps customers to improve information security in their organizations by providing a better, simpler approach to securing access to their private network resources. However, to deliver on that promise, we’re cognizant that we must first ensure that our own security practices a…
Service Reliability
How Reliable is Twingate’s Infrastructure and Service? Service reliability is a core aspect of information security. This document describes how Twingate ensures service reliability in relation to availability, performance, and scalability. Twingate provides superior reliability over traditional sol…

Thoughts?

Until Tony reached out, i'd not heard of this software so was interested to try it out. When trying things I'm also looking for a couple of initial things

1) Does the person who reached out seem helpful and respond to follow up questions? In this case yes very much so both Tony and Alex were there to point me in the right direction.

2) Can i get from 0 to working basic setup with minimal reading? This is 100% the case here. I was able to get setup and running in about 10 minutes on my phone and laptop.

3) Would i ditch my existing product for the new one? I'm a bit on the fence with this. I have pritunal working for family who are abroad to connect in and watch UK TV, and Wireguard for personal use (the Windows Wireguard client at time of writing sucks). I would ditch both if the free tier was 5 users, 2 Devices not 2 users 2 devices. currently the self hosted option gives me that wider scope.

I love the concept of the service and will keep using it on the Starter Tier, If there was a $20 a year 5 users, 2 Devices tier I think the Self hosted market would possibly jump all over this. $60 a year per user probably not so much.

Adding access to the API is also something i've be very interested in, automating the company, user, connector, resource sign on with code has huge appeal to me.

I however am not the target audience for Twingate, companies are and knowing the licencing costs of traditional Cisco Anyconnect and other Enterprise VPN's the costs here are pretty reasonable for most companies.

If you're in the situation of revisiting your VPN, this is a very VERY solid option, its user friendly and will provide you much more security out of the box than most of the traditional offerings, it will quickly reduce your cost of ownership and give your workforce a far far nicer experience while allowing you to stay secure.

Thanks for reaching out guys.

Follow up reads

Pango Case Study: Why we left our corporate VPN for Twingate | Pango
How Pango moved to Twingate’s modern remote access model in less than 24 hours during Covid-19. Twingate is a modern alternative to business VPN, designed to be more secure, reliable, and made to deploy within minutes.

https://www.g2.com/products/twingate/reviews

TechCrunch is now a part of Verizon Media
About
Meet the people behind Twingate.
Former Dropbox and Microsoft employees launch new VPN alternative
Is Twingate the answer to securing remote workers?