This document attempts to cover some of the most common issues people run into using Twingate, and how to resolve them.
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.
- 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.
- Clients used in fully automated workflows are currently not supported, because the client requires interactive user authentication. We plan to release a "headless" client that can be run on servers with a service account or other automated systems in the near future.
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
10.0.0.15and you have
10.0.0.0/24defined as a Resource in Twingate, the connection will fail unless you also add
test.yourcompany.intas a Resource. Wildcards also must be defined carefully, for example
*.yourcompany.intdoes 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.intis 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.
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
systemdservice, add the line
/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=7to the
docker runcommand. 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.
Updated 4 months ago