This document attempts to cover some of the most common issues people run into using Twingate, and how to resolve them.

Known Incompatibilities

We do our best to make our software compatible with most products and services that are used in the corporate environment. However, some products are not compatible at this time, generally because they are trying to use the same system functionality that we require for operation.

• Cisco Umbrella is currently incompatible due to conflicts around DNS resolution. If both Twingate and Umbrella are installed, neither will likely work properly. Umbrella must be uninstalled or permanently disabled from launching (not simply exiting the program) for Twingate to work properly. Other similar products, such as DNSFilter are compatible with Twingate.

• Most VPNs and VPN-like software, for example other ZTNA solutions, are not compatible with Twingate because we are both trying to forward the same network traffic. Enterprise VPNs will generally not interfere with Twingate unless they are actually connected, but many consumer VPNs (e.g., TunnelBear, NordVPN, ExpressVPN) attempt to run in the background all the time, even if they appear to be disconnected, and will not let Twingate connect. if you are having connectivity issues with your client and have any VPN software installed, even if you do not think it is running, we strongly recommend you do a full uninstall and see if that resolves the issue.
• NetBIOS name resolution (e.g., \\MYCOMPUTER) will not work on Windows Workgroup networks because it relies on broadcast communications. It will work on domains powered by a domain controller. As a workaround, you can type in the IP manually (e.g., \\192.168.1.6) and connections should work normally. We are currently working on a fix and expect to have this working shortly.
• AD Domain joins are not supported currently, but most other Active Directory operations are, including access for devices that are already domain-joined.
• Some security software like MalwareBytes and Trend Micro have incompatibilities in how their web protection analyzes URLs that users are visiting. Turning off the web protection feature should resolve the issue, the core anti-malware functionality remains compatible.
• Connectors hosted in China can sometimes be impacted by local restrictions imposed within China. This is because Connectors maintain outbound connections to our GCP-hosted Relay infrastructure, and connections to GCP may be subject to those restrictions.
• Google Workspace as an IdP for users in China is not supported as local restrictions imposed within China block connections to some of Google’s services, including Google Workspace and Gmail.

Unsupported Use Cases

• Twingate clients can only initiate connections to remote servers on the private network, they cannot receive connections initiated by machines on the private network. Clients do not get their own IP addresses like a typical VPN and hence cannot receive inbound connections from the private network. It is very rare for a modern enterprise application to require inbound connectivity to clients, though some VoIP software still works this way. If you think you might be in this situation, please contact us as we may be able to offer an alternative solution.

Troubleshooting Checklist

If you encounter an issue setting up Twingate, following some simple steps can save you time and reduce the amount of diagnostic steps required if you contact our support team.

The first step is to identify what component is not working correctly:

• If the Remote Network of the Resource shows up in red on the Admin Console, that means the Connector is not working correctly.
• If the Remote Network is green but clients do not show the Resource in question in the Resource list (in the tray menu) when signed in, it is likely a permissions problem. Make sure that the user is in a Group that contains the Resource. If the client does not show the Resource, it will not be reachable.
• Try to use a different machine to connect to the Resource to isolate the problem. Macs and especially Windows PCs may have third-party programs running that can interfere with our private connection, so using an iOS or Android device can be very helpful as a debugging tool to isolate any interference from third party software. If other clients work, the issue is on the user’s specific device.

If none of these steps helped:

• If possible, log into the machine running the Connector and attempt to initiate a connection to the Resource’s DNS name or IP address in the same manner as your client. If it fails, that is almost certainly the root cause of any connectivity issues. All connections flow through the Connector, so you cannot connect to a Resource that the Connector for its Remote Network cannot reach.
• If you are trying to access a Resource by a DNS name, remember that the exact name or a wildcard that matches it must be defined in the Admin Console. This is the case even if the IP address the name resolves to is defined as a Resource, for example if test.yourcompany.int resolves to 10.0.0.15 and you have 10.0.0.0/24 defined as a Resource in Twingate, the connection will fail unless you also add test.yourcompany.int as a Resource. Wildcards also must be defined carefully, for example *.yourcompany.int does not match yourcompany.int, only subdomains of that domain.
• Many web applications connect to other domains “under the hood,” often without the user’s knowledge. If an internal web application is not functioning correctly, try creating a broader wildcard DNS zone, and seeing if that helps. For example, if yourapp.yourcompany.int is not loading correctly, try defining *.yourcompany.int. Note that we do not recommend leaving it this way as overly broad permissions do not comply with zero trust best practices, but you can use network analytics to determine what other domains are being connected to, and then define those more precisely.

How to Collect Logs

If you can’t figure out the issue, our support team is here to help! You can contact us via email or via chat in the Admin console. The first thing we will likely ask you to do is to send us the Client application logs from the Client and/or Connector experiencing the issue, so it’s best to provide them at the beginning when contacting us.

For Connector logs, you will need to redeploy the Connector with a setting that turns on more verbose logging:

• For a Connector deployed as a systemd service, add the line TWINGATE_LOG_LEVEL=7 to your /etc/twingate/connector.conf, then restart the service by running sudo systemctl restart twingate-connector. Retrieve the logs by running sudo journalctl -u twingate-connector.
• For a Connector deployed as a Docker container, redeploy the Connector, adding the argument --env LOG_LEVEL=7 to the docker run command. Retrieve the logs by running docker logs [ID of container].

Please make sure to replicate the issue you experienced after detailed logging is turned on, and note the time where the issue occurred so our support team can cross-reference with the logs.