I’m working in a Windows AD domain, so the computer running the connector uses the private/AD DNS servers. So, any DNS requests not hijacked by Twingate should be resolved on those private servers, with public DNS forwarded to public servers.
That works as expected, until I installed the Twingate client on the DNS servers so they could connect to an Azure Monitor Private Link Scope (AMPLS) for log ingestion.
Running the Twingate client on the DNS servers completely kills public DNS requests.
After reviewing how Twingate handles DNS, I believe that a DNS loop is being formed.
With the client service running on the DNS servers, instead of the Windows DNS server using the defined public servers, Twingate re-routes those requests to the connector, which sends it back to the private DNS server.
How can I run the Twingate client on the DNS servers to access the AMPLS, without creating this loop which prevents public DNS resolution?
Hi Mike. I am reading through your post above. I have two starter questions:
In the IP configuration what do you have configured for DNS Server(s)?
In the DNS Management MMC, how are your forwarders configured for the DNS server where you installed the Twingate client?
Our DCs/DNS servers are at IPv4 .201 and .202, and both have the Twingate client installed.
All domain computers are set to those two IPs in their network connection / IPv4 configuration (.201 as primary).
The DCs/DNS servers’ network connections are set to use themselves (127.0.0.1) as primary DNS and the other server as secondary.
In the DNS MMC, both servers are configured to use Google’s public DNS servers - 8.8.8.8 and 8.8.4.4.
Thank you for the response. It helps, as I do not work on Domain Controllers that often. One additional question, are you using Headless Windows client or are you performing user authentication on the DC for Twingate?
So, if DC.201 looks at loopback for DNS resolution and DC.202 for Secondary and DC.202 does the opposite. I think the loopback entry might be the issue. When you launch our client we take over DNS Client resolution and if nothing that is requested is in the “tunnel” we send to the locally configured resolver. What happens if you swap the DNS entires? (e.g DC.201 looks at DC.202 for Primary and itself as Secondary) I do understand that this is not a Best Practice, but as a test it should be easy enough to swap.
Both servers are using the Headless Client, and I also have both servers configured for Windows Start Before Login (SBL), though I’m not sure if that’s a factor here.
I will have to test your configuration after hours this evening or early tomorrow morning - I can’t risk an “intentional” interruption during office hours. I’ll get back to you as soon as I have an answer.
I don’t think it will have an effect, though.
When the DNS entry is not found “in the tunnel” and the request is sent to the locally configured resolver (be it the localhost or the other server), that locally configured resolver ALSO has the Twingate client installed and the request is intercepted again, not found in the tunnel, and sent to be intercepted again. (Since both DNS servers are DCs, both need the client to connect to the Azure Monitor private link). I may be forced to implement a separate DNS server that isn’t running the client, but I’d really prefer not to have to go that route.
As I said, I will try your suggested configuration as soon as I can and get back to you with the result.
Tried your idea this morning; clients still fail to resolve DNS requests (no response).
I’m hoping you have another idea, if not I can try to setup a separate DNS server that doesn’t require the Twingate client and point the primary DNS servers to it for resolving non-local IPs.
That seems like a poor solution , though, so I’m hoping you have other ideas we can try.
Actually, I do have another idea. It will take a few steps but basically you load the headless client on a computer and forward the requests to the AMPLS from the DCs. This doc describes the framework.
Basically you would enable a route table entry and point the AMPLS traffic to forward to the headless client.
I just thought of one more thing…
When the Twingate client connects on your DC does the Network Connectivity Status Indicator (NCSI) change and state that you have no Internet???