Understanding Connectors

Whether you are deploying Connectors in cloud infrastructure or on-prem, they serve as the backbone of your Twingate network, allowing you to provide access to Resources to users anywhere in the world.

This guide covers general recommendations that apply to any environment, and you will also find environment-specific guides in this section.

Connectors are not VPN gateways

Although Connectors have superficial similarity to a VPN gateway, there are significant differences in behavior that benefit security and management:

• Connectors should never be accessible from the public internet. Connectors should always reside behind a firewall, within the private network that protected Resources are connected to.
• Users never choose to connect directly to a Connector. Twingate instead connects users to Resources by routing them through the appropriate Connector behind the scenes.
• Connectors do not ever allow users to join the private network. Instead, Connectors should be seen as narrow keyholes that only allow individual network connections to proceed to the Resources that users are authorized to access.
• There is no downside to deploying Connectors on multiple private networks. Because users are never aware of the Connector a given connection is routed through, the number of Connectors does not introduce any additional complexity to users. This allows Connectors to mirror your network infrastructure without making changes solely to support remote access.
• Traffic can be routed to the geographically nearest Connector. In situations where services are replicated across multiple geographic regions, Connectors can be deployed in each region to ensure that users are always routed to the nearest Connector. See our Connectors Best Practices guide for more information.

Connectors are sophisticated, software-defined proxies

A more accurate way to think about Connectors is as sophisticated, centrally-coordinated proxies that never allow more than the authorized traffic to pass through them. Some differences emerge in how to think about deploying and managing them:

• Name and address resolution is local to Connectors. When a user is authorized to access a protected Resource, name and address resolution of that Resource does not take place on the user’s device, but is instead forwarded to the Remote network the Connector resides in. This means that users can use private DNS names and IP addresses to connect to Resources without needing to connect directly to the destination network.
• Separate Connectors allow users to connect to multiple networks without updating routing permissions. It’s no longer necessary to make network routing or infrastructure changes to support remote access use cases. Networks can be defined and segmented as dictated by best practices, and Connectors can be deployed within network subnets as needed to support access. For an example use case of this, see our Access Control for Staging Environments. Twingate will automatically route traffic for a user to the closest available Connector, reducing latency and seamlessly handling routing in the case of replicated Resources.
• Connectors are automatically clustered and can be deployed to meet your changing needs. Connectors are software-only and automatically clustered for redundancy within the same Twingate Remote network. This allows you to add more Connectors as needed to meet changes in demand or usage.
• Twingate enables very precise “split tunneling”. Only traffic destined to Resources that a user is authorized to access will be routed to the relevant Connector from their device. This means that the only traffic flowing through a Connector is that which is destined for a Resource on the same Remote network.

Last updated 5 months ago