When users are connected to Twingate, how private traffic is routed is determined based on the destination host connection request. This decision is made before DNS resolution, which allows routing of traffic to different destinations based entirely on the FQDN in the user's request.
When administering Twingate, -and-access-nodes#resourceResources are coupled to Remote networks, which correspond to the target private network. Therefore, it is the address that determines what target network the user's request will be routed to, and subsequently where DNS resolution of the destination host will happen. This allows the complexity of configuring separate environments to be hidden from the end user with the FQDN serving as sufficient abstraction.
For example, consider a simple scheme to separate development and staging web environments:
# Staging environment # AWS VPC, subnet 10.0.1.0/24, private DNS # staging.beamreachinc.com 10.0.1.22 # Staging web server connector-1.staging.beamreachinc.com 10.0.1.10 # Local Twingate Connector # Development environment # AWS VPC, subnet 10.0.2.0/24, private DNS # dev.beamreachinc.com 10.0.2.77 # Development web server connector-1.dev.beamreachinc.com 10.0.2.10 # Local Twingate Connector # Production # Public DNS, delivered via AWS CloudFront (CDN) # www.beamreachinc.com
With Twingate deployed on each local subnet, Twingate users that have been given access to
dev.beamreachinc.com will be transparently routed to the development subnet and their request will resolve to the
10.0.2.77 development server. This routing is invisible to the user and requires no configuration changes on their part.
Compared to the traditional approach of asking users to connect to the necessary environment—for example, by disconnecting and reconnecting a VPN client to a new environment—Twingate offers significant advantages.
- Naming is sufficient for the correct routing and authorization. This greatly simplifies the user experience without introducing the additional complexity of needing special user authentication or updating access whitelist rules when using public DNS names. Note: if one of your environments is hosted publicly, but managing an access whitelist is your primary concern, see Whitelisting Traffic to Public Services for how Twingate can help.
- Access can be given to internal and external users without providing access to the entire environment. It's often beneficial to provide access to individuals or groups that do not need access to the entire staging or development environment. Externally, this could include contractors and vendors that your business works with. Internally, this might include product management, marketing, or the executive team. These groups would be able to review changes in staging, say, by providing narrow access to the
staging.beamreachinc.comstaging server and nothing else.
- Staging and development environments are invisible to the public internet. Because private DNS is used, your environments are completely hidden from the public internet and only exposed to the users you authorize in Twingate. This eliminates the risk of any resources being exposed unintentionally.
- Users no longer need to know what backend network they are connecting to. A common pattern with legacy VPN solutions is the need for the user to decide which network or environment they are connecting to. Because Twingate handles this routing transparently based on the destination FQDN, users no longer need to consciously switch environments.
Updated about 1 month ago