Introduction
Twingate is a cloud-based service that provides secured remote access to an organization’s networks. It’s function is very similar to a business VPN. Twingate makes Zero Trust Network Access (Yes, Buzzword. I know) easy to deploy, even easier to use, and always secure. It establishes direct peer-to-peer connections to protected resources, with each request verified before it ever leaves the device.
How Twingate is Revolutionizing Remote Access
Resources Based Access
Most commercial VPNs allow you to access internal networks whereas Twingate allows the declaration of individual resources as shown below:
A resource on your network can be any of the following:
A Fully Qualified Domain Name (FQDN), eg. host.autoco.internal
An FQDN using one or more wildcards, eg. *.host-0?.autoco.internal, where * represents 0 or more characters and ? represents exactly 1 character.
- Wildcards like
*.autoco.internal match anything to the left of .autoco.internal
An IP address, eg. 10.1.0.35
A valid IP CIDR range, eg. 10.1.0.0/16
The underlying reason for declaring network resources in such a manner will become apparent in the next few sections.
Native Access Control Lists
Twingate uses Access Control Lists (ACLs) to secure resources both internally and externally. ACLs consist of tables that define access permissions for network resources. They are built into network interfaces, operating systems as well as enabled through Windows Active Directory.
When onboarding a new resource, the admin is able to entirely control Port restrictions and Internal Domain names as shown above. Most traditional VPNs do allow subnet routing. However, resource-specific rules and restrictions have to be configured on your internal firewall. That changes with Twingate.
Twingate also offers granular permissions which allow you to define access to individual resources with custom policies and groups, enabling narrow access permissions. This kind of implementation has become a basic necessity in a world where people work from anywhere.
Users & Groups (AAA-like)
Now that we've declared our network resources and setup restrictions, let's take a look at what makes Twingate so special.
Traditional VPNs require the remote user to establish a connection to the VPN server and, once they prove they are an authorized user, they are granted access to the network behind the server, as if they were sitting at a computer in the office and on the network.
Larger companies may also have multiple networks which need to communicate with each other. This requires building a complicated network of VPN connections between them and letting users connect to multiple VPN servers.
This is where Twingate's Zero Trust Networking comes into play. ZTN, a network access framework, operates on the fundamental concept that both the network itself and the users seeking to link with corporate assets are regarded as untrusted, thus the term "zero trust." Given this premise, maintaining security mandates a thorough examination and validation of every endeavor to reach a confidential resource. This validation includes confirming the user's identity as they assert (authentication), and ascertaining their entitlement to reach the specific resource in question (authorization).
How it works:
We have 2 active users declared in our network.
We also have 3 operational groups.
We're able to assign active users to operation groups as shown above.
We are able to assign groups to resources which determines their access to the resource.
The configuration is pretty modular as shown above and we are also able to assign multiple groups to a particular resource.
Architecture
Twingate relies on four main components
Controller
Clients
Connectors
Relays
Together, they ensure that only authenticated users are able to access the Resources that they have been authorized to access. Here's how they all work in conjunction.
Controller
The Controller's responsibilities encompass various tasks such as storing configuration changes from the Admin console, delegating user authentication to third-party identity providers, and generating access control lists (ACLs) for both clients and connectors. These ACLs define authorized resource access for users and network destinations for connectors. The Controller also plays a role in registering and authenticating deployed connectors, requiring one-time authorization and establishing anonymized unique IDs for identification, ensuring secure communication with Twingate Clients.
Client
The Twingate Client application (Pretty self-explanatory, like your Openvpn Connect), installed on users' devices, serves as a crucial authentication and authorization proxy for user requests to private Resources. It establishes TLS tunnels with designated Connectors which ensures secure and efficient access to protected Resources, all orchestrated at the Client's edge.
Connector
The Connector, serving as the counterpart to the Client, takes on a simpler yet significant role. Designed to be placed behind a private Remote network's firewall, the Connector's core responsibilities include establishing and upholding communication with the Controller. (Basically the node in your network, something like argo)
Relay
The Relay is the simplest component in the Twingate architecture. No data or network-identifiable information is stored in the Relay and no data-carrying connections are terminated at the Relay. The Relay can be considered to be the equivalent of a TURN server in WebRTC nomenclature.
Access
Desktop
Accessing your remote resource is as simple as downloading your corresponding agent from their website and blazing through the following steps.
Once authenticated successfully, you should only see resources that have been delegated to you or the group that you belong to. It's that simple. You can now access that resource without any issues.
ssh ubuntu@192.168.18.18
Mobile
And that's it! Additionally, if you were on a traditional VPN, your general network traffic (by default) would flow through the VPN server which exhausts the VPN Server's bandwidth unnecessarily forcing the server to be scaled. With Twingate, your general traffic goes out through your device's network card unless specified otherwise.
Logging
Recent Activity
Twingate allows the admins to track recent activities related to each resource.
Reports
Twingate also allows admins to generate reports in bulk and review them as shown:
Setup Process
The setup process is fairly straight forward.
Prerequisites
- An in-house node running 24/7
Installation
Remote Network
The first step is to add a remote network. Name is whatever and select the location accordingly.
Connector
The next step is to install the connector on our local node. There are a ton of deployment methods to choose from and I went with Docker as expected.
Configure the connector to your liking and paste the command into your node as shown below
![]()
.
Once we see that the connector is up, we are ready to go. However, Twingate does provides 2 connectors by default for redundancy.
Now we're ready to add resources, port restrictions, users & groups as discussed above! It's that simple.
Conclusion
Pros (+)
Extremely simple setup & management process for admins
Extensive ACL control over resources
Lessens company network load by directing non-business data straight to the internet
Handles DNS queries within the remote network, preserving typical hostnames and IP functionality.
Wide support for client operating system
Cons (-)
Remote access solutions are moving towards zero trust security. According to Forbes, implementing a zero trust access (ZTA) solution over traditional secure remote access solutions delivers one of the best frameworks needed in today’s digital era. It operates on the principle of “never trust, always verify,” ensuring that users and devices are continuously authenticated and authorized before accessing designated resources
ZTA can help protect against everything from simple malware to advanced persistent threats to insider threats. It can not only help prevent attacks outright, but also stop lateral movement, or otherwise mitigate, an attack in progress.
PSA: There are a few other tools that achieve the same goals as Twingate which doesn't depend on an external entity for your private system access. (E.g ZeroTier / Nebula)
Follow up (?)
I might discuss how tools like such can be used by attackers to run around in your network 🥲.
-Nee
