Exit Networks let your end users route all traffic through Twingate. Exit Networks fully encrypt all traffic that leaves a user’s device, even if it’s not destined for a protected Resource. Exit Networks route traffic through Connectors that act as exit nodes.

Twingate typically uses split tunnel routing, meaning that only traffic destined for Resources goes through Twingate. Split tunnel routing is ideal most of the time as it routes Resource traffic directly through Twingate while offering the best performance and latency for all public internet traffic, such as video conferencing, general browsing, and streaming video.

Use cases

Routing all of your traffic through Twingate can be particularly useful in a few situations:

• When you don’t fully trust the local network, such as when connecting to the Wi-Fi network of a coffee shop or a hotel. Routing all traffic through Twingate fully encrypts all outgoing traffic, keeping it safe from prying eyes.
• When you’re traveling and want to access content that’s only available back home. Similarly, when you need to verify that content will be localized correctly in another country.

How Exit Networks work

Exit Networks are a collection of Connectors that act as exit nodes. When a user routes their traffic through Twingate, all non-Resource traffic will be routed through their selected Exit Network. Traffic destined for Resources will continue to be routed to those Resources.

Furthermore, when traffic is routed through an Exit Network, that traffic is sent through the geographically closest Connector, similar to how Connectors are selected when connecting to a Resource. Exit Networks are also able to gracefully pass traffic to another Connector if one goes down, just like Remote Networks. Twingate will consistently route traffic through the Exit Network even if some of the Connectors become unreachable.

Configuring Exit Networks

Navigate to Internet Security → Exit Networks

You manage Exit Networks in the “Internet Security” section of the Admin Console. Navigate to “Internet Security” and then the “Exit Networks” tab to get started.

Create a new Exit Network

Create a new Exit Network with a unique name, e.g. its region, like “United States”, or its function, like “Coffee Shop Mode”. Once you’ve created an Exit Network, you can move on to deploying Connectors inside of it.

Deploy Connectors within the new Exit Network

Deploy Connectors within the newly created Exit Network. To learn more about deploying Connectors, follow the Deploying Connectors guide. We recommend deploying at least two Connectors and making sure that Connectors are peer-to-peer friendly. Learn more in the tips section below.

Within the Client, you should now see the option to “Route All Traffic Through Twingate”

Hover over “Route All Traffic Through Twingate” and select your Exit Network to start routing all traffic through Twingate. You can also easily disable routing all traffic through Twingate at will.

Currently, users are limited to using Exit Networks for sessions of up to 12 hours.

(Optional) Select which Groups can use Exit Networks

You can optionally choose which Groups are allowed to use Exit Networks. To do so, click the “Enabled for Everyone” button (or, if you’ve set this up previously, it may show as “X Groups”). From there, you can select which Groups should have access to Exit Networks. Users in the selected Groups will be able to use all Exit Networks, while users not in those Groups will be restricted from accessing any of them.

Tips

Deploy Connectors in a peer-to-peer friendly way

Connectors in an Exit Network should be peer-to-peer friendly. When end users can connect to a Connector using peer-to-peer, their connections will be faster and have lower latency. To ensure that Connectors are peer-to-peer friendly, read our guide on troubleshooting peer-to-peer connections.

Deploy at least two Connectors in each Exit Networks

For better availability and redundancy, deploy at least two Connectors in each Exit Network. This helps balance traffic between two Connectors and ensures that if one Connector goes down, another is there to automatically take its place.

Deploy Connectors for Exit Networks separately from your existing infrastructure

An Exit Network will route all traffic through its Connectors. In turn, if Connectors in Exit Networks are able to reach your connected Resources, any user routing all of their traffic through Twingate would be able to access Resources without any authentication checks.

To prevent this, Connectors in Exit Networks should be deployed outside of your existing infrastructure. Putting them into a separate VPC or treating them like points of presence is strongly preferred compared to piggybacking on top of existing infrastructure.

Minimize egress costs by using cloud providers with lower bandwidth costs

Major cloud providers like GCP, AWS, and Azure charge high prices for egress bandwidth. Some cloud providers include bandwidth for each VPS you provision and have lower cost bandwidth overages. Since Exit Networks should be deployed outside of your existing infrastructure (whether in their own VPC or even further separated), these providers may offer a cost-effective solution to routing your traffic via Twingate. Consider providers like

• Digital Ocean includes 0.5 to 11 TB of bandwidth depending on the instance type.
• Vultr includes 0.5 to 12 TB of bandwidth depending on the instance type.
• Linode includes 1TB to 20TB of bandwidth depending on the instance type.
• Hetzner includes 1TB or 20TB of bandwidth depending on the region.

who all have bundled bandwidth and much lower bandwidth overage costs compared to the major providers.

Our testing indicates that these providers have peer-to-peer friendly NAT, but you should validate that your specific deployment is peer-to-peer compatible.

FAQ

How does routing all traffic through Twingate work with DNS filtering?

DNS filtering continues to be resolved by the Twingate Client while all of your traffic is routed through Twingate. DNS filtering will continue to work as normal.

Why isn’t IPv6 working?

The Twingate Client currently is not compatible with IPv6 addresses. When routing all traffic through Twingate, AAAA queries are blocked and you will not be able to connect to domains that require an IPv6 address.

Why can’t I reach a specific site when routing my traffic through Twingate?

This may be due to how your Connectors are deployed, or it may be due how Exit Networks currently work. Please reach out with any issues that you experience, especially while Exit Networks are in early access.