Name Resolution Failure in Headless Client

Support / Troubleshooting
1

I am trying to set up a Twingate connection from a GCP node to our on-prem node via the headless client. I installed the client on the GCP node and set it up with a service account. When I run twingate resources, I see the following (edited the resource name):

RESOURCE NAME	ADDRESS
onprem1         	onprem1

But when I try ssh onprem1, I get the following error:

ssh: Could not resolve hostname onprem1: Temporary failure in name resolution

I can reach onprem1 from my laptop without a problem using the Twingate desktop client.

Thanks.

2

Hi @kurta,

If you click on the Resource in the Admin Console and check out the Activity events, do you see a connection attempt from your headless client? If so, is it in error?

It should tell us where the connection is breaking (between Client and Connector or between Connector and Resource).

3

I don’t see any connection attempt by the headless client.

4

Ok! Can you try creating another Twingate Resource for the same machine but using its IP instead of the hostname and see if you can ssh via the IP from where the Twingate Client is? This will tell us if it’s a routing issue or a resolution issue.

5

It works as expected when I use the IP address.

6

Great!

if you run a dig onprem1 from the host where the headless client is, does it return anything? If it returns a CGNAT IP, the Client is configured correctly and intercepts connections destined to onprem1. If it returns nothing, it means the Client is not, for some reason intercepting it.

(if interested, take a look at this write up on how the CGNAT IP Range is used by the Twingate Client)

7

It doesn’t seem to return an IP address.

; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> onprem1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39857
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;onprem1.				IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Feb 08 17:48:41 UTC 2023
;; MSG SIZE  rcvd: 33

If I run the same but with the IP address of onprem1, which I set up as a Twingate resource as you suggested previously, I still don’t get a 100.x.x.x IP address. Instead, it just repeats the 192.x.x.x address:

; <<>> DiG 9.11.3-1ubuntu1.17-Ubuntu <<>> 192.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63377
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;192.x.x.x.			IN	A

;; ANSWER SECTION:
192.x.x.x.		0	IN	A	192.x.x.x

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Feb 08 17:50:19 UTC 2023
;; MSG SIZE  rcvd: 57
8

@kurta,

are you running a DNS service on the machine where your headless client is installed? The dig command on ‘onprem1’ seems to be going to 127.0.0.53#53 so it looks like something local is configured to intercept DNS traffic already.

9

I’m not really sure what the correct way of checking for the DNS servers currently in use, but on the GCP node, I get 127.0.0.53 from /etc/resolv.conf. From systemd-resolve --status, I get two lists of DNS Servers. One is a list of CGNAT IP addresses, and the other is 169.254.x.x.

Also, it looks like DNS resolution fails even for the reverse connection (i.e. onprem1 >> GCP), where we also have installed the Twingate headless client. On onprem1, we have this set up via netplan:

...
network:
    ethernets:
        eno1:
            addresses: [192.168.x.x/24]
            gateway4: 192.168.0.1
            nameservers:
                addresses: [8.8.8.8, 8.8.4.4]
    version: 2
    renderer: NetworkManager
...

I get 127.0.0.53 from /etc/resolv.conf, but systemd-resolve --status shows CGNAT IP addresses as DNS servers. On my Macbook where I’m using the Twingate desktop client, which works correctly (no name resolution issues), /etc/resolv.conf lists the same CGNAT IP addresses that show up on scutil --dns.

10

I think I figured out what the issue is. Apparently, this bug with systemd was causing the DNS servers added by Twingate to be ignored. After creating a symlink to /run/systemd/resolve/resolv.conf as suggested in Stack Overflow, things are working as expected.

1 Like