I am able to setup twingate without issue everywhere but in our data center. When I install the connector on docker there it gives me the following error on the connector
Could not connect
Could not connect to the Twingate Relay. Be sure to unblock outbound ports 30000-31000.
I have verified all outgoing ports are open, there are no issues or logs showing errors with docker. We have tried with 1 to 1 natting and without and regardless of what we do the connector never connects. If I setup anywhere else outside of the datacenter environment it works right away. There is very little documentation on what might be causing this so I wanted to ask if anyone knew what might be going on here?
unfortunately, it does sound like a connectivity issue between the Docker host and Twingate’s Relay infrastructure (outbound port range 30000-31000 is indeed part of it but there is a bit more (see here).
One thing that is potentially worth a try is to deploy a Connector on a VM within the data center: if it also fails to come online, it’s probably an issue with the firewall, if it does not, that would point towards a docker host issue.
got it, I meant to suggest deploying an additional Connector on a VM directly without docker (using systemd, Ubuntu is perfect for this) and see if it comes online.
Same issue again. Bummer we would really like to use your platform but this has been pretty hard to get working without more documentation. Any other suggestions?
Could you activate debug level logs on your Connector installed via systemd in Ubuntu?
In order to do that, add TWINGATE_LOG_LEVEL=7 to the /etc/twingate/connector.conf file and restart the Connector by running the following command: sudo systemctl restart twingate-connector
Once you have restarted the Connector, take another look at the Connector log file and post it here, it should tell us a bit more! (you can use the same command as before for this: journalctl -u twingate-connector -n 1000 -f or something similar)
In the meantime, one thing that strikes me as odd from the logs is that Connectors establish connections to relays.twingate.com, in this case the log shows that the Connector host does resolve our Relays properly (in your case the resolution returned is to 34.102.42.240).
The Connector seems to be unable to establish outbound connectivity to port 30011 for that public IP but why connectivity isn’t there, I cannot tell.
Here is a couple of things to try:
Run a telnet command to the public IP of the Relay (34.102.42.240) and port 30011 from various locations to determine where the issue is:
Run telnet 34.102.42.240 30011 from the host machine where the Connector is hosted
Run telnet 34.102.42.240 30011 from your own machine (Assuming you are on the same network)
Run telnet 34.102.42.240 30011 from your own machine but from a different network (home wifi for instance)
(I ran the command myself from my home and it connected successfully)
test 1 will likely fail.
If test 2 fails as well but test 3 succeeds, it will likely be a network issue (firewall?)
if test 2 and test 3 both fail, perhaps there is something installed on machines preventing those outbound connections?
@Marvistec, Support got back to me: It really does look like the Connector cannot connect to our Relays. The tests I mentioned above should tell us more about your side but if you could also send us your Twingate tenant name along with the public egress IP of your Connector then we can check on our side if it was blocked by us. (feel free to send the info to onboarding@twingate.com btw if you don’t want to share it here, you can simply reference this thread in the email).
You should be able to see if there is a drift from the Admin Console, if you open up your Connector page, you will see a “time Offset” field, let us know what value it has.
EDIT: it turns out I cannot post more than 3 responses in a row on our Forum so editing my last response @Marvistec! I have heard back from our support team: there is no blocking on our side however we now see a live and functioning Connector in your environment. I assume you found the root cause or found a workaround?
@Marvistec! I have heard back from our support team: there is no blocking on our side however we now see a live and functioning Connector in your environment. I assume you found the root cause or found a workaround?
I just checked again and still see a single Connector in your environment that appears to be live and healthy. Just to confirm: are you still experiencing the same issue on your Connector?
Yes still no relay connection. I then deployed another connector using systemd and still same issue. I’ll do another in docker as well but so far haven’t seen any that have come online or are working.
Something does not add up between the issue you are experiencing and what we see on our side:
We see 2 Connectors in your environment (both under 1 Remote Network).
The first Connector was created 22 hours ago and appears fully functional (we see it connect to our Relays successfully). The Egress IP we see for this live Connector is indeed the one you have shared offline with us, indicating that it is actually live and communicating.
The second Connector is not live but was only created 17 min ago.
BTW, we see no Resource added to Twingate environment, is this expected?
Ok I think the one you are seeing is the one that was setup in docker a while ago. The network for that one has since been deleted but I can see that it is still showing onlien and connected.
319b845ca7fa twingate/connector:1 “/connectord” 2 days ago Up 23 hours (healthy) twingate-charcoal-corgi
The one I just deployed was using the systemd method for a network that we have in our account.
How should I proceed. Deleted all and setup a new network and try to re deploy the docker connector on the new network?
