Skip to content

Troubleshooting your connection

Under Windows, open an Admin Command prompt.

Under other operating systems, open up a Terminal window.

1. Is direct network access working?

On the command prompt, type

Windows:

ping 8.8.8.8

Others:

ping -c 4 8.8.8.8

If this works, then this indicates direct network access is working. The following are example criteria for success or failure.

Success

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=14.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=14.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=14.0 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 13.979/14.488/14.853/0.325 ms

Failure

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3075ms

It looks like your network isn't working at all. This is likely not a problem with Connect.

Things to try:

  • If on WiFi, ensure you have correctly identified to the network with your WiFi password.
  • Check if you can access any sites on the internet
  • Reset your router

2. Is direct name resolution working?

This validates whether direct name resolution is working for your network. This requires that direct network access is working as it should.

On the command prompt, type

Windows:

ping dns.google.com

Others:

ping -c 4 dns.google.com

If this does not work, then direct name resolution is not working. The following are example criteria for success or failure.

Success

PING dns.google.com (8.8.8.8) 56(84) bytes of data.
64 bytes from dns.google (8.8.8.8): icmp_seq=1 ttl=117 time=16.8 ms
64 bytes from dns.google (8.8.8.8): icmp_seq=2 ttl=117 time=20.9 ms
64 bytes from dns.google (8.8.8.8): icmp_seq=3 ttl=117 time=17.6 ms
64 bytes from dns.google (8.8.8.8): icmp_seq=4 ttl=117 time=15.0 ms

--- dns.google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 14.957/17.565/20.851/2.130 ms

Address 8.8.4.4 is also known to be valid for dns.google.com.

Failure

ping: dns.google.com: Name or service not known

A reply such as this indicates that direct name resolution is not configured correctly on your network.

Things to try:

  • See if you can access any other known sites on the internet by name.

3. Can you ping any devices on the TAN by their TAN IP address?

Look up the TAN IP address of a Connect Endpoint which you should have access to. The TAN IP address will look like 100.x.x.x.

Replace the IP address below with the TAN IP address you wish to validate.

Windows:

ping 100.221.17.231

Others:

ping -c 4 100.221.17.231

Success

You receive responses from the remote peer.

PING 100.221.17.231 (100.221.17.231) 56(84) bytes of data.
64 bytes from 100.221.17.231: icmp_seq=1 ttl=64 time=7.17 ms
64 bytes from 100.221.17.231: icmp_seq=2 ttl=64 time=2.56 ms
64 bytes from 100.221.17.231: icmp_seq=3 ttl=64 time=11.2 ms
64 bytes from 100.221.17.231: icmp_seq=4 ttl=64 time=4.16 ms

--- 100.221.17.231 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

Failure

You don't receive any response.

4 packets transmitted, 0 received, 100% packet loss, time 3075ms

Things to try:

  • Restart Connect and ensure it is running on both ends
  • Ensure both devices are listed and showing as "Online" on the Control service
  • Ensure that the IAM (access control) policy permits the two devices to access each other.
  • Check the connection relay settings of each device on the Control service. Toggling between manual and automatic settings may improve the connection as this will re-establish a connection based on the latest collected latency metrics.

Nothing works!

If you made it this far and still cannot access another Connect Endpoint, we are sorry to hear that. Please contact us with the information you have collected above, and we'll do what we can to help.