Split Tunnel Failures

Split Tunneling and Local Subnet Collisions

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. 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.

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