Twingate overriding private DNS for undefined resources

One Twingate resource defined - (private LAN)
DNS manually configured as (Private DNS server) on internet adapter

When Twingate is connected, I can ping any IP on my private LAN, including private DNS server, as expected, but private hostnames are not being resolved by my private DNS server. Instead NSLOOKUP returns “Non-existent domain”

I thought I understood the Twingate connector to resolve DNS like this:

  1. Intercept all DNS requests
  2. Check if hostname is defined as a resource in the connected Twingate network, and the resource is available
    (a) if resource is defined & available, return IP as defined in Twingate network
    (b) otherwise, pass the DNS request to system’s DNS server

(b) doesn’t seem to be happening though. Instead of passing the DNS request to the DNS server I’ve specified for the connection, it seems to be passing it to a public DNS server.

How do I get Twingate to pass ‘undefined’ requests to my private DNS server instead ?

Hi @Mike,

your understanding of how the Connector deals with DNS queries is almost entirely correct but is missing a small piece:

How you define Resources determines what traffic gets intercepted by the Twingate Client (a Resource is essentially a split tunneling rule), this means that if your Resource is declared as an IP or CIDR range and your Client is on; connecting to a FQDN corresponding to the IP of your Resource will NOT be intercepted by the Twingate Client:for this to work, you will need to declare a Twingate Resource on the FQDN itself: this will ensure the Twingate Client intercepts traffic and passes it to your Connector.

On DNS specifically: while the Connector does indeed resolve the FQDN locally, on the Client side a DNS query against your private DNS server will return a CGNAT IP and not the private IP of the actual end point. That is because, in order to intercept traffic, the Twingate Client does the following:

  1. Inserts itself as the primary DNS resolver locally
  2. If a query on a FQDN corresponding to a Resource is seen, the local adapter returns an arbitrary CGNAT IP for it
  3. the Client routes all traffic on the CGNAT range to its own network adapter and to the Connector

If you want to retrieve the actual result of a DNS query client side, all that is needed is to:

  1. declare your DNS server as a resource (sounds like you have done just that)
  2. change your DNS queries to query your private DNS server explicitely

Take a look here for more details on how Twingate handles DNS traffic: How DNS Works with Twingate | Docs

Thanks for the reply, Bren.

We can consider this closed as I found another way to configure things, but I tried what you suggest at the end of your post and, even when declaring and querying the private DNS server explicitly, the Twingate connector blocks the request on UDP port 53 and the query never makes it to the private server.

Hi @Mike!

interesting, having the DNS server declared as a Twingate Resource and changing DNS queries to explicitly specify the DNS server to use when running DNS queries with dig / nslookup etc. should work flawlessly. The Connector itself shouldnt be blocking any communication however perhaps there is something on the host where the Connector lives that is blocking outbound UDP on port 53?