Glossary

Resource

A Resource is any destination host, server or application. Twingate supports any TCP or UDP protocol, so it is not necessary to differentiate between different destination protocols. Whether SSH or HTTPS access is required, a Resource is simply defined by its destination address.

Connector

A Connector is a Twingate software component that runs on the destination Remote network. Any traffic destined for private Resources will go through the Connector, and all traffic will appear to originate from the Connector host.

We deliver this component as a Docker container that does not require any special host privileges. You can either run this directly on a Linux-based server or VM, or directly on AWS, Google Cloud or Azure using their native container services.

Security Policy

A Security Policy defines what security controls are applied to a user in order to access a Resource. This allows flexible policies to be applied to specific Resources, regardless of the protocol used. For example, an MFA Security Policy policy can be applied to SSH server access.

Group

A Group is a logical grouping of Users that are given permission to a set of Resources. All Users that are members of a Group can access all Resources that are associated with the same Group.

Groups are associated with a single Security Policy that is applied whenever a User in the Group accesses Resources in the Group.

General

What is Twingate?

Twingate provides secure access to private resources for distributed workforces under a zero trust networking model. Learn more about how Twingate works and the advantages of Twingate over VPNs in our documentation.

What is Zero Trust Networking?

“Zero trust” networking is a network access model that is based on the core principle that the network and the users that want to connect to private resources on it are assumed to be untrusted (hence “zero trust”). To ensure security, this dictates that every attempt to access a private resource must be checked and verified to ensure that the user is who they claim to be (authentication), and is authorized to access what they are trying to access (authorization). Hence a zero trust network does not distinguish, from a trust perspective, between a public network like the internet, and a private network like a company network, even if a user is directly connected to that network.

How does Twingate differ from a VPN?

Twingate provides access controls based on the modern “zero trust” model, under which every request to a network resource is checked and verified. This model is different to VPNs, which grant access to whole networks via centralized VPN gateways, and not to individual resources. Twingate also provides a host of security, usability, and maintenance benefits over VPNs for both end users and administrators. For more details, see our comparison of Twingate against VPNs.

How does Twingate work?

For a description of how Twingate works, and its architecture, and how it fits in with your infrastructure, see our documentation on How Twingate Works.

What platforms does Twingate run on?

• Twingate allows secure access controls to be applied to private resources on any network, whether they are on-premise or hosted. Our customers use Twingate to access resources in public cloud platforms (eg. AWS, Azure, Google Cloud Platform), virtual private server environments (eg. DigitalOcean), and on-premise networks.
• Twingate supports any application that communicates via TCP or UDP out of the box, without any application, device, or server configuration necessary.
• Twingate clients are available for macOS, Windows, Linux, ChromeOS, Android, iOS, and iPadOS. Clients can be downloaded at get.twingate.com. For more information see our client documentation.

Does the Twingate client work on Apple M1-based systems?

The Twingate client includes native Apple M1 support and can be installed through the Mac App Store in OS X.

Deploying Twingate

How much technical knowledge do I need to have to deploy Twingate?

Deploying Twingate does not require technical expertise in networking. If you know the internal IP addresses or internal domain names of the resources you want to allow to be remotely accessed, and how to run a Docker container on a device in your network, you will be able to deploy Twingate. See deploying connectors for step-by-step instructions and best practices.

What changes do I need to make to my infrastructure to deploy Twingate?

You do not need to make changes to your network infrastructure to deploy Twingate. Twingate overlays access controls over your existing network. In fact, the only thing you need to do to make a network accessible via Twingate is to install a connector (deployed as a Docker container or a native Linux system service) on a server on that network. We also provide a range of service-specific Connector deployment options to make it easy to deploy Connectors in your environment.

Twingate’s deployment model is software-only and intended to be . There is no to change any IP addresses, remap network names, worry about network segmentation, change firewall rules, or install a new hardware appliance.

Do I have to disable my VPN infrastructure before I can use Twingate?

No. Twingate can be used alongside any existing VPN infrastructure you have. This makes evaluating Twingate easy, since you don’t need to “rip and replace” your existing systems to try it out. It also makes migrating to Twingate easy, since you can phase a rollout. And if for whatever reason you need to roll back, your existing infrastructure will still be there so users aren’t disrupted.

How do I deploy Twingate on end user devices?

Because the Twingate Client doesn’t require any special configuration, users can download Clients themselves from the Twingate website or their mobile device’s app store. After installing the Client, users only need to sign in with their usual SSO credentials, all they’ll have access to all the Resources that you’ve given them permission to access via the Twingate Admin console.

Does Twingate integrate with identity providers?

Yes. Twingate integrates with major identity providers, including Okta, Entra ID (formerly Azure AD), Google Workspace, and OneLogin. Twingate delegates authentication activities to these identity providers, and therefore does not store or handle sensitive user credentials like passwords.

Where should I install my connectors?

Only one Connector needs to be deployed on each network that you want Twingate to control access to, but we recommend deploying Connectors in pairs for failover redundancy. In terms of best practices, please see our recommendations on Connector deployment.

Performance

Does all traffic need to be routed through my infrastructure?

No. Twingate is split tunnel by default, meaning that only access to resources that you’ve added to Twingate will result in traffic passing through your infrastructure. Zoom calls and access to public websites, for example, don’t get routed through your infrastructure, decreasing lag for users and reducing congestion on your network.

As my company and traffic scales, how can I be sure that Twingate is able to continue supporting it?

As a component of our customers’ network infrastructure, service reliability and availability is something that we take extremely seriously. See Service Reliability to read more about our approach.

What protocol does Twingate use for encrypted data transport?

Twingate uses a standards-based transport protocol (TLS v1.2) to efficiently handle data transportation and routing. All encryption is done using standard ciphers.

Does Twingate support WireGuard?

WireGuard is an open-source communication protocol that implements VPN techniques to create secure point-to-point connections. While Twingate may adopt WireGuard as a transport layer in the future, we are currently monitoring the progress and adoption of the WireGuard protocol.

End User Experience

How do end users get Twingate?

Users can download the client from https://get.twingate.com. Android, ChromeOS, macOS, iOS, and iPadOS users can also download the client from their device’s app store. Clients do not require any pre-configuration by organizations.

Do users have to interact with the Twingate client?

By design, user interaction is intended to be minimal. After installing the client, users just need to click “Connect” and authenticate using their company credentials via SSO. Once authenticated, Twingate will sit unobtrusively in the background and should not require further interaction. Twingate is always on, and doesn’t need to be toggled on or off. Split tunneling means that accessing public resources is not affected while using Twingate.

Unlike a VPN, even if you have multiple secure networks, Twingate handles routing to each of them transparently and users don’t have to select a specific gateway that would give them access to a specific network.

Administrative Experience

What control do I have over access levels and Resource authorization?

Twingate allows access controls to be set by combinations of Resources and user Group. This enables role based access controls at a granular Resource level.

Certain identity providers allow setting multiple Access policies. Access policies can be set up to determine what authentication mechanism should be enforced by your identity provider and in which contexts (e.g. device posture, time of day, and other factors).

Do you have an API? Can I programmatically deploy Twingate?

Yes, Twingate has an API that you can use to configure Twingate and deploy Connectors programmatically. For example, the API enables you to deploy a new server or other resource, automatically have it registered as a Resource that Twingate controls access to, and automatically assign certain user Groups permission to access it.

Billing

How do you charge for Twingate?

We charge on a per user basis, either annually or monthly. In this context, a user is a “seat” that you can allocate to a specific individual user. Once you have allocated all your seats to individuals, you will need to either purchase more seats, or reassign existing seats. See subscription management for more information.

Security

Do I have to publicly expose any servers to use Twingate?

No. Unlike traditional remote access technologies like VPNs, Twingate does not require you to set up gateways, concentrators, or servers that listen for inbound connections from the public internet. Instead, network subnets interface with Twingate via the use of connectors. Connectors are sophisticated software-defined proxies that are not accessible from the public internet, and are not directly accessed by users. This means that your networks can remain hidden from the public, with no visible, exposed entry points. Read more about how Twingate works.

How can I be confident that Twingate is secure?

Please see our Twingate Security article, which describes how Twingate keeps you and your data, resources, and users secure.