Unable To Install Twingate Latest Connecter from Docker

Support / Troubleshooting
1

Unable to install docker connector on my centos 7 server.

Error message was:

docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.0.1:53: read udp 192.168.0.91:50321->192.168.0.1:53: i/o timeout.
See 'docker run --help'.

Please advise what I should do to install Twingate on my server. Thanks so much in advance

2

Have you double checked the firewall permissions?

3

If you try running curl https://registry-1.docker.io/v2/" do you get a response or does it time out? How about curl https://www.google.com? It seems like there might be a DNS resolution or connectivity issue with your machine.

4

Thank you so much Arthur.

I am able to curl https://www.google.com, but when I try running curl https://registry-1.docker.io/v2/

I got an error:
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":null}]}

5

Thanks mlab.

Yeap, my firewall on my centos7 is down.

6

Hi Arthur,

when I run curl -vvv https://registry-1.docker.io/2/ , I ge the following error:

curl -vvv https://registry-1.docker.io/v2/
* About to connect() to registry-1.docker.io port 443 (#0)
*   Trying 2600:1f18:2148:bc00:e947:5a7f:a49f:9126...
* Connected to registry-1.docker.io (2600:1f18:2148:bc00:e947:5a7f:a49f:9126) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer
7

So I also get the same 401 response if I curl it from the CLI. If you attempt to install the connector again do you get the same message about i/o timeout again/consistently?

8

Thanks, Arthur, but yes I have been facing the error. I have tried uninstalling and removing docker from my Centos7 VM but still face the same error when I reinstalled Docker and tried pulling Twingate from Docker

9

Can you confirm what version of docker is installed on the system for me

10

Hi Arthur, current build is Docker version 24.0.5, build ced0996 but I just ran a yum update command and is now Docker version 24.0.6, build ed223bc. Will test it out again to see if I can pull Twingate image from docker.

Thanks in advance.

11

Hi Arthur,

I still faced the same error while running on Docker version 24.0.6, build ed223bc

docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.0.1:53: read udp 192.168.0.91:49692->192.168.0.1:53: i/o timeout.

Thanks a lot in advance

12

I see a DNS problem. Your Docker client is on 192.168.0.91, and it’s asking 192.168.0.1 to do a DNS lookup for it. That lookup is failing: “i/o timeout”

Is that the right DNS server for the network? If yes, is that DNS service up and working?
Quick and dirty workaround would be to give your Docker host a 2nd DNS server to query. It appears to only have one, it’s not working, and the effort has to fail there.

13

Hello,

Thanks so much for pointing out the error. I have modified my DNS IP address but still encounter the same error. My VM runs on a bridge network with my server and shares the same IP address of 192.168.0.91. The server is connected to my router which has an IP address of 192.168.0.1.

I have attached the DNS configuration of my Centos VM.

This is my /etc/sysconfig/network-scripts/ifcfg-eth0

image

This is my /etc/resolv.conf file:

; generated by /usr/sbin/dhclient-script
nameserver 192.168.0.91
nameserver 192.168.0.1

I still get the error message of:

docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on 192.168.0.1:53: read udp 192.168.0.91:59976->192.168.0.1:53: i/o timeout.
See 'docker run --help'.

Thanks so much in advance and hope to hear from you soon.

14

This then looks to me like a routing issue. I think your traffic is never hitting the DNS server.

Does the DNS server have a log that could confirm or deny if a request for a resolution from 192.168.0.91 is being seen? I suspect it isn’t.