Split Tunnel Failures

By default, Twingate uses split tunneling: it only captures and routes traffic destined for the private Resources you have explicitly defined. All other traffic - such as to public websites like Google, or to local network devices like a printer - is ignored by Twingate and follows the device’s normal network path.

This split tunnel design means two categories of issues can occur: traffic that Twingate captures when it should not (local subnet collisions), and traffic that Twingate does not capture when it should (missing Resource definitions).

Local Subnet Collisions

Problems arise when a Twingate Resource definition accidentally overlaps with a user’s local network, causing Twingate to mistakenly capture local traffic.

Common Symptoms

• A user reports, “I can’t print to my home printer at 192.168.1.50 when Twingate is turned on.”
• A user cannot access a local file server or NAS on their home network.
• Another VPN client that the user needs for a different purpose will not function when Twingate is active.

How to Identify and Troubleshoot

• Identify the IP address overlap: This is the cause in nearly all cases of local network conflict.
  • Ask the user to find their local IP address and subnet. On Windows, they can run ipconfig; on macOS or Linux, ifconfig or ip addr. For example, their computer’s IP address might be 192.168.1.100 on a 255.255.255.0 subnet, meaning their local network is 192.168.1.0/24.
  • In the Twingate Admin Console, carefully review all your Resource definitions. If you have defined a corporate Resource with the address 192.168.1.0/24, you have created a collision. The Twingate Client on the user’s machine will see this rule and attempt to route all traffic for their local network - including their printer - to your corporate Connector, where it will fail. The same collision issue occurs if you have defined a Resource with a specific address within the 192.168.1.0/24 range and a device on the local network has the same IP address.
• Refine your Resource definitions: The best practice is to be as specific as possible when defining Resources to minimize the chance of collision.
  • Instead of defining a broad CIDR range like 10.0.0.0/16, define Resources using their specific IP addresses (e.g., 10.0.5.23) or smaller, more precise CIDR blocks (e.g., 10.0.5.0/24) whenever possible.
• Understand and use Exit Networks for full tunneling: If your goal is to prevent split tunneling and force all of a user’s traffic through a secure gateway (for example, when they are on an untrusted public Wi-Fi network), the correct feature to use is an Exit Network.
  • An Exit Network is a special type of Remote Network where you deploy Connectors to act as secure Internet exit points. When a user selects an Exit Network in their Client, all of their traffic is routed through that exit Connector. This is an intentional, user-selectable, full-tunnel mode, and is not the default behavior.
• Handle .local domains with care: If your internal network uses the .local top-level domain, be aware that this is also used by the mDNS (Bonjour) protocol for local device discovery. You must define your internal .local domain as a Resource in Twingate for it to be resolved correctly, but this can create conflicts with local device discovery. Refer to Twingate’s specific knowledge base article on this topic for best practices.

Missing Resource Definitions for Web Applications

When you use Twingate for application gating - routing SaaS or web application traffic through your network so it appears to originate from a known IP address - you need to define Resources for every domain that application depends on. A modern web application rarely operates on a single domain. A site at app.example.com may load scripts from cdn.example.com, authenticate through auth.example.com, or pull assets from a third-party domain entirely.

Because Twingate only tunnels traffic for defined Resources, requests to any domain you have not added will bypass the tunnel and go directly over the user’s internet connection. The destination service may then reject those requests because they arrive from an unrecognized IP address, resulting in failed page loads, broken functionality, or authentication errors.

Common Symptoms

• A SaaS application partially loads but key features are broken or unresponsive.
• A user sees authentication errors (HTTP 401 or 403) on a web application that works without Twingate.
• A web application loads its main page but fails to load styles, scripts, or embedded content.
• A user reports that a gated application “works sometimes” or “works on some pages but not others.”

Identify Missing Domains with Browser Developer Tools

The fastest way to find which domains are missing from your Resource definitions is to inspect the application’s network requests directly in a browser.

• Open the web application in Chrome, Edge, or Firefox while signed in to Twingate.
• Open the browser’s developer tools. In most browsers, press F12 or right-click anywhere on the page and select Inspect.
• Select the Network tab, then reload the page.
• Look for failed requests. Filter or sort by status code and look for HTTP errors such as 401 (Unauthorized), 403 (Forbidden), or blocked/cancelled requests. Pay attention to the domain in each failed request.
• For each failed domain, add a wildcard DNS Resource in the Admin Console. For example, if you see a failed request to cdn.partnersite.com, add *.partnersite.com as a Resource. Assign the same Groups and Security Policies as the primary application Resource.
• Wait for the new Resources to appear in the user’s Client, then reload the application and repeat the test.

Identify Missing Domains with Test Resources

If the browser developer tools approach does not fully resolve the issue - for example, if some requests fail outside the browser or the application’s traffic patterns are difficult to trace - you can use temporary test Resources to capture all network traffic and identify what is missing.

This procedure temporarily routes all of a user’s traffic through Twingate for the duration of the test. After the test, remove the user from the test Group and delete or disable the test Resources.

• In the Admin Console, create two new Resources on the same Remote Network as the application you are troubleshooting:
  • A DNS Resource with the address *.* - name it something like “Test DNS”.
  • An IP address Resource with the address 0.0.0.0/0 - name it something like “Test IP”.
  • Leave both Resources with no port or protocol restrictions.
  • When prompted to assign Groups, uncheck all Groups including Everyone. The test Resources should not be assigned to any Group at this point.
• Create a new Group (e.g., “Test Group”) and add both test Resources to it.
• When you are ready to test, add the affected user to the test Group. Wait until both test Resources appear in the user’s Client.
• Have the user load the application and complete the workflow that was previously failing. With the test Resources in place, all traffic flows through Twingate and the application should function correctly.
• Remove the user from the test Group immediately after the test is complete.
• In the Admin Console, review the network activity logs for the test. You can find these on the user’s profile page or on the activity page for each test Resource. Look for domains and IP addresses that were captured by the test Resources but are not covered by your existing Resource definitions. These are the missing entries you need to add.
• Add the missing domains as permanent Resources with the appropriate Groups and Security Policies assigned, then retest without the test Resources in place.
• Delete or disable the test Group and test Resources.

If you have systematically worked through all of these steps and are still unable to resolve the issue, it is time to gather comprehensive logs and consult additional resources.