Device Failures

Device or Client Application Failures

The Twingate Client is an application that integrates deeply with the operating system’s networking stack. Failures at this level can be caused by the Client’s own state, missing components, or conflicts with other installed software.

Common Symptoms:

• The Twingate Client UI is stuck on “Disconnected” and the connect button is unresponsive.
• The Client fails to start, and logs on Windows show errors related to TapAdapterExistence or “Twingate adapter is missing.”
• The user is connected, but the Resource list in the Client is empty.

How to Identify and Troubleshoot:

• Check the Twingate Service/Daemon: The Client UI is primarily a front-end - the real work is done by a background service that must be running.
  • Windows: Open the Services Management Console by running services.msc. Scroll to find “Twingate Service” and ensure its status is “Running” and its Startup Type is “Automatic.” If it’s stopped, try starting it manually. If it fails to start, check the Windows Event Viewer (Application Log) for crash reports.
  • macOS: Using the terminal, log show --process Twingate --last 1h.
  • Linux: On systemd-based Linux distributions, you can get detailed service logs with sudo journalctl -u twingate --since "1 hour ago".
• Verify the Virtual Network Adapter: Twingate creates its own virtual network interface to handle traffic.
  • Windows: Twingate requires a “Twingate TAP-Windows Adapter.” You can check for its presence in the Network Connections control panel or by running ipconfig | findstr "Twingate" in a command prompt. If it is missing or disabled, the service will fail to start. This can often be resolved by reinstalling the Twingate Client.
  • macOS: Run scutil --nc list in a Terminal. You want to look for a network extension for Twingate.
  • Linux: Run ip a and look for an interface named sdwan0. If it is missing, reinstalling the Client usually resolves the issue.
• Hunt for Software Conflicts: This is a very common cause of Client failures. Any other software that attempts to control or inspect network traffic can interfere with Twingate. (The Client Logs are a good starting point for identifying conflicts.)
  • Other VPNs/ZTNA Clients: Running another VPN or remote access client simultaneously is a frequent source of conflict, as both applications try to control the system’s routing table.
  • Antivirus/EDR/Firewall Software: Security software that performs deep packet inspection or network filtering can block Twingate’s operations.
  • Network Optimizers: Some computer manufacturers (OEMs) pre-install “network optimization” or “traffic shaping” software that can interfere with Twingate’s routing.
  • Troubleshooting Conflicts: The most reliable way to test for a conflict is to temporarily uninstall the suspected software, then restart the machine and test Twingate again. Simply “disabling” some security products isn’t sufficient, as their drivers may still be active in the network stack. If the issue is resolved, you can try reinstalling the other software and creating explicit exceptions for Twingate’s processes and the domain *.twingate.com.
• Collect and Review Client Logs: When in doubt, the logs usually have the answer.
  • The easiest way to access them is from the Client UI: click More > Troubleshoot > View Logs.
  • On Windows, this will open the %LOCALAPPDATA%\Twingate\logs directory. The most important files are typically Twingate.log (UI logs) and Twingate.Service.log (background service logs).
  • On macOS, this will open the ~/Library/Group Containers/6GX8KVTR9H.com.twingate.com/Logs/private/var/log/twingate/ where the logs are located.

If the Client is connected and appears healthy, but the user cannot access a specific Resource by its name, the problem is very likely related to DNS.