Twingate was designed from the beginning with a thoughtful approach to security in mind. A key feature of Twingate’s design is that no single component can independently make a decision to allow traffic to flow to another component or Resource in your Remote networks. Authorization for user access or data flow is always confirmed with a second—or even with a third—component depending on the sensitivity of the decision being authorized. By adding in delegation of user authentication to a third party Identity Provider (IdP), that separation of concerns extends even further, providing an additional layer of security to your Twingate network.

The following guide starts by covering Twingate’s architecture and then dives into how Twingate encrypts traffic and guarantees that users can only securely access Resources they have been authorized to access.

Twingate relies on four components—the Controller, Clients, Connectors and Relays—that together ensure that only authenticated users are able to access the Resources that they have been authorized to access.

With Twingate fully configured, the end result is that authorized users can connect to any Resource using its FQDN or IP address—with addressing local to the Resource on the Remote network—without needing to know anything about the underlying network configuration or even what Remote network the Resource resides on.

Let’s dive into each of Twingate’s components in turn before moving on to how Clients and Connectors securely register with your Twingate network and then the the full connection flow.

Controller

The Controller is the central coordination component for Twingate. It’s a multi-tenant component that stores configuration changes via the Admin console, registers Connectors, and issues signed authorizations to Clients making connection requests amongst other responsibilities. The Controller is the only component that does not interact with any data flow.

The Controller’s responsibilities include:

• Storing access management and configuration changes from the Admin console. This includes all admin-definable configuration and settings in the Twingate Admin console.
• Delegating user authentication to social identities or configured Identity Providers. The Controller always delegates user authentication to a third party identity authority. When Twingate is configured to synchronize with an Identity Provider, users are also synchronized from the IdP to the Controller.
• Generating ACLs for Clients. Client ACLs represent the discrete set of Resources that a given user is allowed to access and as such are the “least privileged access” representation of what the user is entitled to.
• Generating ACLs for Connectors. Connector ACLs represent what network destinations—Resources—the Connector is authorized to forward network traffic to. The set of Resources in a Connector ACL also serves as a second check on a given Client ACL: traffic can only be forwarded to a Resource if it falls in the intersection set between the two ACLs.
• Registering and authenticating deployed Connectors. Connectors cannot be deployed without one-time authorization from the Controller. Once deployed, a Connector authenticates itself with the Controller and registers itself with an anonymized hash-generated unique ID. This Connector ID is the only identifying information that is ever shared with Twingate Clients.

The Controller, with full redundancy and clustering, runs as a Twingate-hosted, multi-tenant service.

Client

The Twingate Client application (or simply, Client) is a software component that is installed on users’ devices. The Client’s role is to act as a combined authentication and authorization proxy for user requests for private Resources. The Client is where most of the decision-making takes place in a Twingate network deployment. Network routing and authorization decisions all take place at the edge within the Client.

The Client serves multiple roles, including:

• Handling user authentication. Users cannot access any Twingate-protected Resources without first authenticating themselves. This is enabled by the Controller, which redirects the user to an identity authority on their local device for authentication.
• Obtaining a signed ACL for the authenticated user. This user-specific ACL is signed by the Controller and used to determine which network connections should be forwarded to protected Resources and which should be ignored. The signature on this ACL is verified by the appropriate Connector during a connection request to prevent tampering.
• Detecting network connection requests to protected Resources. When a network connection is detected, the Client inspects the destination address, whether it is an IP address or FQDN. If the destination address matches a Resource in the ACL, a connection will be initiated via Twingate to the Remote network.
• Proxying DNS requests for protected Resources. For network requests to protected Resources, DNS requests are forwarded for resolution to the Remote network Connector. This means that DNS lookups for protected Resources are always resolved locally even though the Client is on a different network.
• Proxying TCP and UDP traffic for protected Resources. The Client uses a transparent proxy to forward traffic for any TCP or UDP port/protocol to protected Resources. This means that no application configuration is required on the user’s device. Applications on users’ devices will appear to be connecting directly to remote Resources, even though they are not routable from the device without Twingate.
• Establishing a certificate-pinned TLS tunnel with the appropriate Connector. The Client is responsible for establishing an encrypted tunnel with the appropriate Connector to access a protected Resource. This TLS tunnel is established based on the anonymous, unique Connector ID and is pinned to the specific Connector based on a signed connection token received from the Controller. This flow will be explained more detail later in this guide.

→ Learn more

Connector

The Connector is the mirror component to the Client but has a simpler set of responsibilities. The Connector is intended to be deployed behind the firewall of a private Remote network.

The Connectors responsibilities are primarily:

• Authenticating and maintaining connectivity with the Controller. Once a Connector is successfully deployed, the Controller responds with a Connector ACL. This ACL is kept up to date with any changes triggered by configuration updates in the Controller.
• Maintaining connectivity with one or more Relays. Because a Connector is intended to be deployed behind the firewall of a private Remote network, it maintains active outbound connection(s) with at least one Relay.
• Verifying the integrity of any inbound Client connections. The integrity of the established TLS tunnel, the signature of the Client, and the validity of the Client’s ACL claim are all confirmed for every inbound connection request to the Connector. This process is described in detail in the next article in this guide.
• Performing local DNS resolution of proxied requests. For inbound connections for FQDN Resources, local DNS resolution is performed by the Connector before forwarding traffic to the resolved IP address.

→ Learn more

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.

The Relay’s basic responsibilities are:

• Serve as a registration point for Connectors. When Connectors are initialized, they establish a connection to one or more Relays and register a unique, hash-based Connector ID with the Relay. This Connector ID is also stored at the Controller, which allows Clients to connect to the appropriate Connector with any private network or other specific information being shared. No other information is stored at the Relay.
• Serve as a connection point for Clients looking to establish connections to Connectors. After verifying that the Client request is legitimate, inbound connections contain a request for a specific Connector ID. This allows the Relay to connect a Client directly to the requested Connector for the establishment of a single, certificate-pinned TLS tunnel. This is done without any special knowledge of the source and destination networks, Client or Connector involved in the connection.

→ Learn more