Frequently Asked Questions
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.
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.
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.
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.
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.
“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.
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.
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.
- 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.
The Twingate client includes native Apple M1 support and can be installed through the Mac App Store in OS X.
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.
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.
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.
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.
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.
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.
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.
Twingate uses a standards-based transport protocol (TLS v1.2) to efficiently handle data transportation and routing. All encryption is done using standard ciphers.
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.
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.
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.
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).
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.
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.
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.
Please see our Twingate Security article, which describes how Twingate keeps you and your data, resources, and users secure.
Last updated 3 months ago