Controller could not connect

Support / Troubleshooting
1

Over the weekend I was not able to get any of my connectors connecting. As I drilled down the reason was that the Controller was not connecting. This morning the Controller was connecting but this afternoon was not connecting again for one of my two remote networks. It’s beginning to look intermittent.

Since I have a free account Twingate tech support can’t help. I’m at a loss since it seems that the Controller is on a Twingate server and I have no control over it.

Ideas and suggestions would be appreciated.

2

This is interesting.

The only thing the connector needs to connect is ports 443 and 30000-31000 outbound. Nothing inbound.

What does your setup look like? Where are the connectors running?
What is your tenant name (I can look on the backend).
When you say you think it is the controller not connecting - what did you find that made you think this? Logs? Can you share what you found?

You are right. Support isn’t available for free tiered accounts, but that doesn’t mean you cannot get help here! Happy to assist as best we can here.

3

Hey Jason,

Thanks for replying.

Both of the Connectors are running in a Synology NAS Docker container. There is 1 Connector and 1 Resource defined to each of the two networks, I’ve just recently started using Twingate and I’m still familiarizing myself with it. Both of the NAS devices are on the same network at my house.

Tenant is https://bimpy.twingate.com

I identified the Controller was not connected from the remote networks Connector page in the section ’ Connection Status’. Here it shows the status of the Controller. For one of my remote network Controllers it shows ‘Connected’ with a nice green light. Below it shows the Relay green and connected. From the Connector page of my other remote network the ‘Connection Status’ for the Controller it says ‘Could Not Connect’ along with the red dot. The Relay connection says ‘Requires Controller connection’ and a gray dot.

Over the weekend neither of the networks Connector/Controller connected.
This morning they were both connected.
Now just 1 is connected.

Roger

4

Lets see if you can grab the logs from one of the affected connectors. That should tell us what is going on.

It is interesting that this is intermittent and the logs should give us some insight into what the connectors are seeing.

5

Can you be specific on which logs you need.

The Docker log is:

Level Time User Event
Information 2023/02/20 14:30:29 roger Add image from docker.io/twingate/connector:latest
Information 2023/02/20 15:32:09 roger Create container twingate-lilac-spoonbill.
Information 2023/02/20 15:32:10 roger twingate-lilac-spoonbill connect to network bridge.
Information 2023/02/20 15:32:21 roger Start container twingate-lilac-spoonbill.
Information 2023/02/20 23:16:32 roger Stop container twingate-lilac-spoonbill.
Information 2023/02/20 23:16:57 roger Start container twingate-lilac-spoonbill.
6

I think we can get what we need with:
docker logs CONTAINER_ID_OF_CONNECTOR

7

I was given some more context here:

-t will include timestamps, otherwise there won’t be any. Then 2>$1 will ensure we get both stdout and stderr logging.

sudo docker logs -t $cont 2>&1

Also you might want to enable debug logging.

curl -s https://binaries.twingate.com/connector/docker-change-log-level.sh | sudo bash -s 7

8

Jason,

The logs are here, Dropbox - putty.log - Simplify your life

Hopefully they show you something.

9

ok!

So we see a 410 gone message.
It looks like perhaps someone clicked “generate new tokens” on the connectors being used.

Is there any chance you can deploy the container again?
Grab the logs again, but we should not be seeing a message at the time of grabbing the tokens/authenticating.

10

I deleted the Docker container as well as the connector and created both a new container as well as a new resource and wouldn’t you know it connected. I had done this over the weekend including deleting and recreating the remote network and nothing worked.

I’m happy to see things connected again and being able to get back to my testing.

Thanks for your help and working with me so quickly.

Roger

11

That is awesome Roger. I am going to replicate this as well. I am about 80% there to make sure this was the cause.

This was actually answered internally, so I cannot take the credit. We have some really smart people on the team here who are happy to help!

Keep us in the loop as you explore Twingate!