DNS Failures

DNS Resolution Problems

A cornerstone of Twingate’s functionality is its handling of DNS. The Client intercepts DNS queries for protected Resources and securely forwards them to a Connector, which resolves the name using your internal DNS servers. A failure in this process means the user’s application never gets the correct IP address to connect to.

Common Symptoms:

• A user is connected to Twingate, but when they try to access an internal web application, they get a browser error like DNS_PROBE_FINISHED_NXDOMAIN or “This site can’t be reached.”
• A desktop or mobile application fails to connect, with logs showing errors like “host not found” or “cannot resolve hostname.”
• In the Twingate Admin Console, the Activity report for the Resource shows events with a “DNS lookup error” status.

How to Identify and Troubleshoot:

• Test DNS Resolution on the Client device: Use standard command-line tools on the user’s device to see how DNS is behaving.
  • Open a command prompt or terminal and run nslookup <resource_fqdn> (e.g., nslookup jira.mycompany.internal).
  • Correct Behavior: If the Twingate Client is correctly intercepting the request, the command should return an IP address from the Carrier-Grade NAT (CGNAT) range: 100.96.0.0/12. This is a virtual IP address that Twingate uses internally and it confirms that the Client has identified the destination as a protected Resource. (See our guide on How DNS Works with Twingate for more information.)
  • Incorrect Behavior: If the command times out, returns a public IP address, or returns an error, it means the Client is not intercepting the request. This could be because the Resource isn’t defined correctly in the Admin Console, the logged-in user isn’t a member of a Group with access to the Resource, or the Client itself is having an issue.
• Check for CGNAT IP Address Conflicts: This is a critical and often overlooked issue. Twingate reserves the 100.96.0.0/12 IP address range for its internal operations. If the user’s local network or their ISP uses this same range for device IP addresses or DNS servers, it will cause a conflict.
  • Diagnosis: On the user’s machine, check their network configuration. On Windows, run ipconfig /all. On macOS, run scutil --dns. Look at the assigned IP addresses and, most importantly, the DNS server addresses. If any of these—except the Twingate adapter—fall within the 100.96.0.0 to 100.127.255.255 range, there is a conflict.
  • Resolution: The simplest fix is to have the user manually configure their device’s DNS settings to use a public DNS provider that is outside the conflicting range, such as Google DNS (8.8.8.8, 8.8.4.4) or Quad9 (9.9.9.9).
• Check DNS Resolution on the Connector Host: If the Admin Console’s Activity report explicitly shows a “DNS lookup error,” the problem isn’t on the Client’s end. It means the Client successfully sent the request to the Connector, but the Connector itself couldn’t resolve the name.
  • Diagnosis: Log in to the server or container host where the Connector is deployed. From that machine’s command line, run nslookup <resource_fqdn> or dig <resource_fqdn>.
  • Resolution: If the command fails on the Connector host, it confirms a local DNS issue. You must resolve the DNS configuration on that host. This might involve editing /etc/resolv.conf on Linux, checking VPC DNS settings in your cloud provider, or ensuring the host has a network path to your internal DNS servers. This is why it’s a best practice to shut down all but one Connector when troubleshooting - it isolates the problem to a single host machine.
• Check for Multiple Active Network Interfaces: On some operating systems, particularly Windows and Linux, having both a wired (Ethernet) and wireless (Wi-Fi) connection active on the same subnet can lead to unpredictable routing and DNS behavior.
  • Resolution: The most reliable fix is to ensure network interface card (NIC) drivers are up to date, especially for Realtek chipsets. As a workaround, advise the user to disconnect from one of the interfaces (e.g., unplug the Ethernet cable or turn off Wi-Fi) so that only one is active.

If DNS is resolving correctly to a 100.x.x.x address on the Client, but the connection still fails, the issue lies further down the path with the Connector or the network route to it.