https://docs.twingate.com/docs/architecture-overview Jump to Content TwingateHomeDocumentation HomeDocumentation --------------------------------------------------------------------- HomeDocumentationLog InTwingate Log In Search Twingate Overview * How Twingate Works + Architecture Overview + Connector & Client Registration + Client Connection Flow + Understanding Relays * How DNS Works with Twingate * Twingate vs. VPNs * Twingate vs. Mesh VPNs * Term Definition * FAQ Use Cases & Guides * Protect Legacy Technologies with Multi-Factor Authentication * Access Control For Non-Production Environments * Active Directory with Twingate * Azure: Accessing Private Resources + Deploying the Connector + Creating Resources + Accessing Resources * Bastion Server Cloaking + Cloak your bastion server * Kubernetes: Best Practices + Routing Traffic From Kubernetes Cluster Using the Twingate Client * Manage Access for Vendors and Contractors * Private DNS: Best Practices * Remotely Access a NAS Device + How to Set Up Twingate on a Synology NAS * Remotely Access a Coworker's Development Server * SaaS App Gating + Best Practices + Azure Active Directory SaaS App Gating + Okta SaaS App Gating + OneLogin SaaS App Gating * strongDM Cloaking * Whitelisting Traffic to Public Resources + AWS Exit Nodes + AWS CloudFront * Windows Start Before Logon * Ephemeral Access to Resources * Getting Started with the APIs & Command Line Interface + Exploring the APIs + Introduction to the Python CLI + Introduction to tg CLI (JavaScript) * Working With AWS Workspaces * Maintenance Events, Service Status & Outages * Introduction to DNS & How DNS Works with Twingate * Peer to Peer Communication in Twingate * Deploy Connector on Windows with Chocolatey Twingate Administration * Twingate Product Tiers * First-time Configuration + Define a new Remote network + Create a new Connector + Deploy the new Connector + Create a new Group + Create a new Resource + Connect to Twingate * Remote Networks + Best Practices * Connectors * Resources * Users + Admins * Groups * Services + CI/CD Configurations + Linux Headless Mode + Windows Headless Mode * Security Policies + Authentication + Two-Factor Authentication + Device-only Resource Policies * Devices + Device Security Guide + Device Security Posture Checks + CrowdStrike Configuration * Two-Factor Authentication + Using Two-Factor Authentication * Analyzing Network Traffic + Detailed Network Event Schema * Admin Console Security * Admin Actions Report * DNS Security * Administration Troubleshooting * Subscription management Connector Management * Understanding Connectors * Deploying Connectors + AWS + Azure + GCP + Linux + Managed Connectors * Updating Connectors + Containers: Docker/ECS/Azure + K8s Helm Chart + Systemd Service * Connector Health Checks * Connector Metadata * Deployment Automation * Real-time Connection Logs * Supporting Unqualified Domain Names * Troubleshooting Identity Provider Configuration * Supported Identity Providers * Azure AD Configuration + Azure Tenant ID Configuration + Azure AD Twingate Gallery application * Google Workspace Configuration * JumpCloud Configuration * Okta Configuration + Configure SCIM User & Group Sync * OneLogin Configuration + Configure SCIM User & Group Sync Client Applications * Endpoint Requirements * Managed Devices + Windows + macOS and iOS * Download & Installation + macOS + Windows + Linux + iOS + Android + ChromeOS * Using Twingate * Troubleshooting + Disabling Browser DoH Admin API * Admin API Overview Release Notes * Admin Console Release Notes * Client Release Notes + Windows Release Notes + macOS/iOS Release Notes + Linux Release Notes * Connector Release Notes Trust Center * Twingate Trust Center + SOC 2 Report + GDPR Compliance + HIPAA Compliance * Twingate Security * Service Reliability * Responsible Disclosure Policy + Vulnerability Reporting Acknowledgements Powered by Architecture Overview Suggest Edits 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. 14001400 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. 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. 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. Next, we'll dig into how Connectors and Clients register with your Twingate network. Updated over 1 year ago --------------------------------------------------------------------- What's Next * Connector & Client Registration Did this page help you? Yes No