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:
Others:
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:
Others:
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¶
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:
Others:
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.
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.
Known issues¶
Intermittent connectivity and frequent port changes¶
Some NAT routers don't cope well with several endpoints using the same listening port inside the LAN.
This manifests itself in intermittent connectivity and the Connect Control Service showing frequent port changes.
To work around this router issue, configure each endpoint on the LAN with a unique listening port number.
Connection not working after an upgrade¶
Restarting the service may drop manually-applied network settings to the TAN network interface, especially complex configurations involving routing to Subnets behind an Endpoint, or updates to firewall rules.
To make applying such settings repeatable, keep them in a start-up script.
Installing the Connect package will not automatically restart the Connect service on Linux. As such, restarting the service on Linux will have to be done manually.
You can do this either by rebooting (which would also run the start-up scripts mentioned above), or by restarting the Connect service from the command line.
On Windows, if a reboot is required after installation, it will be requested by the installation package.
Backwards compatibility between Connect clients is not guaranteed across major version updates (for instance from 3.x.x to 4.x.x). Please ensure all your clients are running a Connect version with the same major version number.
Restarting the Connect service from the command line (Linux)¶
Linux:
Be sure to also re-run any scripts that apply changes to your firewall rules or routing table.
If you have a different problem¶
If you made it this far and still cannot access another Connect Endpoint, we are sorry to hear that. Please contact us with any information you have collected above, and we'll do what we can to help.