How to configure Twingate DNS for Remote AND local/private DNS?

In response to this post, Bren told me to read How DNS Works with Twingate.

That document suggests that Twingate is working under the assumption that the only private resources that need to be accessed are on a Remote network.

I need to be able to resolve DNS for LOCAL resources defined on a private, local DNS server, as well as Remote resources as defined in Twingate.

How can I get both to resolve properly?

Do I have to define my local resources in Twingate? If I do that, will traffic that should be local go through the Twingate relays instead ?

Hi @Mike,

me again :slight_smile:

in short, yes, you should define your local resources in Twingate as well, this way:

  • The Twingate Client on your machine will know to intercept traffic for those resources and send them to your Connectors
  • The Connectors will do the actual resolution of your local resources (meaning that the Connectors need to be able to resolve those)

Thanks, Bren!

What about the second question, though:

Won’t defining local resources in Twingate make host names resolve to CGNAT IPs and route local traffic through Twingate?

Since I could have a remote network with the same IP range as my local network, how does the Twingate client know it’s local traffic so it doesn’t reroute it?

hi @Mike,

I see what you mean, apologies for having missed that part of the question: you are correct, if you have a resource declared in Twingate on for example 192.168.2.4 and your Twingate Client is ON, it will intercept traffic towards 192.168.2.4 and send it to the corresponding Connector, even if that same IP happens to be a valid one on the private network you are on.

There is currently no easy way to handle this as far as I know (apart from logging off of the client when you need to connect to the local IP vs the one that exists in your remote network.)

One way to remove the ambiguity would be to use a DNS server on the remote network and create Twingate Resources on FQDNs as opposed to IPs (the opposite solution can work as well, deploy a DNS server on your local network and use FQDNs for local stuff); however it does require deploying a DNS server…