Skip to main content

Unable to access a Resource

Aaron
  • Updated
In this article:

     

    Applicable to:

    • Twingate Component: Client | Resources

    Overview

    The following are possible reasons that you cannot access a Resource you expect to be able to access via Twingate. They are sorted from most to least common based on our experience.

    Troubleshooting

    1. Verify the user is authorized to access the Resource. If the Remote Network is green but clients do not show the Resource in question in the Resource list (in the tray menu for Windows/macOS) 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.
    2. Verify the Client's device's DNS configuration. If you are attempting to access a Resource using its name, and you have verified that you are authorized to access the Resource in Twingate, the Twingate Client might not be intercepting DNS.

      Via the device, perform an nslookup or dig against the DNS resource. It should return a CGNAT IP instead of the real IP. If it does not, Twingate is not able to intercept the DNS resource. Something is likely resolving the lookup prior to it reaching Twingate. Further readings on how this works can be found at How DNS Works with Twingate.

      You may be overriding DNS with a local hosts file. If present, remove any entries in your local hosts file that refer to the Resource. Windows users can find this file at c:\windows\system32\drivers\etc\hosts and macOS/Linux users can find this file at /etc/hosts. 
    3. Installed incompatible third party software. Endpoint security software, DNS, VPN, or VPN-like software can prevent accessing a Resource. See Known Incompatibilities for further details.

    4. Verify that the device is not blocked from outbound Internet access to our service. For client connections to Twingate to succeed, access must be allowed to *.twingate.com and the full range of Google Cloud Provider external IP addresses, available here. Note that this list is updated by Google from time to time (context here).

    5. View Network Traffic in the Admin Console. This will return any flows that reach the Connector. If there isn't a connection returned, the issue is likely at the Client level. If there is a connection returned, leverage the details returned to see if there is an issue with the Connector accessing the Resource. 

    6. Verify that the destination Resource is available. If none of the above steps are successful, it's possible that the destination service is not running or the host is shutdown or offline. Verify the Connectors have access to the destination service. If using a systemd or AWS AMI deployment, SSH to the Connector(s) and test port connectivity with the example test command: curl -v telnet://<IPorHostname>:<port>.
      Note: port tests from the Client side to a Twingate Resource will return false positives. See TCP/IP port tests or scans produce inaccurate results for further information.

    7. (DNS Resource) Verify the resource resolves from the Connector. DNS Resources will initially be "resolved" from the Twingate Client IF the DNS lookup matches the user's ACL (Twingate Resources). It will then request a DNS lookup from the Connector. If the Connector does not resolve or resolves the wrong IP, the connection will fail. Perform a dig or nslookup from the Connector to ensure the correct real IP is resolved.
    8. Geo blocking preventing access. While Twingate does not explicitly block certain regions or countries, our upstream provider Google Cloud Platform does block some regions or countries. Access to <tenant>.twingate.com in a browser might be allowed, but access to other Twingate Controller or Relay services might be blocked.
      Additionally, some countries may limit certain outbound internet flows, preventing Clients or Connectors to operate as expected. The Great Firewall of China can possibly interfere with connectivity to either the Connector or Relay services, rendering instability or full connection.
    9. DNS Rebind Protection. If the Resource is a private IP or CIDR and public DNS is used to resolve the IP, consumer modem/routers or ISPs may block the DNS lookup. In such instances a dig or nslookup will return an empty response. See Address Resolution of Resources for further detail.

    If none of the above steps do not resolve your issue and you have a Business or Enterprise account, please collect detailed client logs and open a support request with as much detail as possible (timestamps, name or IP of the Resource, what you've tried, etc).

    Related articles