In this article:
When connected to Twingate, all end users connections transit through one of the Connectors and all connections attempts are logged. The Admin Console makes those connection attempts easy to review thanks to the traffic activity reports.
Shutdown all but one Connector
When trying to troubleshoot why a given end user cannot access an existing Resource they have legitimate access to, the best practice is to:
1. Identify the Remote Network the problematic Resource is assigned to.
2. Only keep a single Connector running in the identified Remote Network
This makes it easier to identify issues with single Connectors (for example, all Connectors in a single Remote Network need to be able to resolve all Resources attached to their Remote Network).
Connection events
Once you have a single Connector running in your Remote Network:
1. Attempt a connection to the Resource from the end user's device.
2. Upon failure, go to the Admin Console, under the **Network** tab, locate the Resource and click on it, you will see the activity report for the Resource under **Activity**.
3. Take a look at the detailed activities, every record with show a **Show details** button when you hover over them.
Connection troubleshooting
If there is no event showing any connection attempt from the Client
Only connection attempts that reach the Connector get logged as events in the Admin Console, if there are no event for the problematic Resource, it usually means that:
* either the Client is not able to intercept the traffic meant for the Resource,
* or the traffic is unable to leave the Twingate network interface from the end user's device.
In this case, we advise checking connectivity from the Client's standpoint.
If events show connection events with DNS lookup errors
When connected to Twingate, the actual DNS resolution of a hostname or fully qualified domain name is done by the Connector handling the connection. If you see DNS lookup errors, it means the Connector is itself not able to resolve the hostname or FQDN.
The best next step is to connect to the machine hosting the Connector (via ssh or any other applicable method) and try to resolve it from there by using a dig <resource fqdn> or nslookup <resource fqdn> depending on the OS your Connector is deployed on.
The solution is to simply make sure the Connector can itself resolve the Resource.
Note: this is why you should only have a single Connector up when troubleshooting: it will make it easier to troubleshoot DNS resolution issues since it is possible that not all Connectors in the same Remote Network are configured in completely identical ways.
If events show successful connection events with no error
If there are events for the problematic Resource and none of the events show any error, it means that the issue is somewhere between the Connector and the Resource the Connector is sending the traffic to.
In this case, you should investigate the following:
1. Firewalls blocking traffic between the Connector and the application or service
2. Correct resolution of the FQDN (check for DNS misconfigurations)