Multiple Network Segments

In general, you should configure one Twingate Remote network per network segment that you are providing remote access to. Because a Remote network logically groups Resources that are all routable and accessible from Connectors deployed in the same Remote network, “network segment” here refers to any address space that is accessible from deployed Connectors, regardless of physical network configuration.

For example, you may want to configure two peered AWS VPCs as a single Remote network in Twingate, even if these VPCs are in different physical locations. As long as the combined address space for both VPCs is accessible from the deployed Twingate Connectors, end user traffic will be correctly routed to the destination Resource.

From a performance standpoint, there is no penalty to having multiple Remote networks configured if this suits your particular network topology. Continuing with the example above, if there is no reason to peer two VPCs other than for remote access, performance is likely to be improved by treating each VPC as a separate Remote network and deploying separate sets of Connectors in each VPC. User traffic will then be routed directly to the destination Resource without any network traversal.

Private DNS

Because Twingate both does not require any public DNS entries and will resolve addresses local to your remote networks via deployed Connector(s), your internal network can remain completely hidden from the Internet.

Although not required, we recommend setting up private DNS to resolve internal IP addresses. This provides a better user experience and also avoids address space collision as you expand your deployment.

Users can use private DNS names when connecting to Resources (eg. resource.company.int) from their local device while running Twingate. If Twingate is disconnected, or access for the user is revoked, the private DNS names will be unresolvable.

Learn more about how DNS works with Twingate.

Routing

It’s not necessary to change network routing rules to accommodate the needs of remote access when deploying Twingate.

If traffic previously needed to flow between a set of subnets to accommodate a single remote access entry point, this is no longer the case. Instead, network routing can be entirely set based on security and infrastructure management best practices.

For example, consider two subnets, 10.1.0.0/16 and 10.2.0.0/16, where network traffic cannot flow from one subnet to another. To provide remote access to both subnets, you would deploy two Connectors—on say, the hosts 10.1.0.35 and 10.2.0.35—with one on each subnet. Because each Connector resolves the local addresses on its own subnet, you can provide remote access to hosts on both subnets without requiring traffic to flow between them.

Firewall rules

No inbound traffic from the Internet or any other source is required for Connectors or Resources.

Connectors only ever initiate an outbound connection to Twingate in order to authenticate themselves and receive a list of Resources that they are authorized to forward traffic to. Any traffic flowing from users to Resources travels along this established connection.

Learn more about Connector network requirements in Deploying Connectors.