I’ve been trying to diagnose a workstation that consistently has DNS resolution problems when Twingate is enabled. All other VPN/AV software has been disabled on this system to isolate potential causes. In the screenshot below, I have performed two nslookup requests, one using a static DNS server of 8.8.8.8 that fails to resolve ebay.com and another using my default DNS server.
The default DNS server in the case, is located in AWS and accessed through an IPsec VPN between HQ and our VPC. The DNS server shares the same AWS subnet as the Twingate connector.
When reviewing the network traffic using wireshark, I see all DNS requests are being forwarded to a CGNAT address using the twingate virtual adapter.
When manually specifying this address using NSLOOKUP, DNS request are resolved but inconsistently and sometimes with a long delay.
It feels like the connector is intercepting the DNS requests and forwarding them to the AWS DNS because it’s in the same subnet as the DNS server instead of allowing the workstation to send them to the AWS DNS server itself causing the packet to drop.
The way DNS and Twingate work is a little bit different than the “norm”.
First, if the Twingate service is running, we generally prevent DNS requests from going anywhere but to us, which is why you’ll see the timeouts trying to use 8.8.8.8 or any other specified server.
The CGNAT DNS server addresses you see aren’t “real” as much as they are placeholders for the Twingate service to intercept the requests and forward them appropriately one of two ways:
A) If the hostname being looked up is a Twingate resource, the DNS request will be answered with another CGNAT IP which will be used to handle the connectivity through the connector to the resource.
B) If the hostname being looked up is not a Twingate resource, the request will be forwarded over to the originally defined DNS servers on the machine when the Twingate service was started, and the answer we get from there is returned.
What’s interesting, is in your first screenshot, second query, when you do NOT specify a DNS server, I would expect to see the Twingate CGNAT DNS address in there (much like your lower shot where you do specify the CGNAT DNS Address) if Twingate was running, but it’s not showing up. Was it not actually running then? If it was running, there may be an issue with the service not actually running successfully, which might explain the intermittency.
The connector won’t do any sort of interception of traffic, it’s not designed to do that and is incapable of it.
Are you, at the time of these screenshots, in your HQ? and is the IPSec tunnel for DNS at the far end of the network or are you running a client or something on that local machine simultaneous with Twingate?
I’m sure we can figure out what’s going on, we’ll just need to do a little back and forth.
The workstation is at HQ when experiencing the issue. The DNS server is a domain controller so all local workstations at HQ use it to resolve records that would be both, local and remote.
We have other resources in AWS that “COULD” be accessible through the IPsec VPN but the centralized auditing and identity management capabilities of Twingate provide a lot of value.
Instead, the IPsec tunnel is almost purely for DNS and access to remote resources are run through Twingate.
As a test, I added the domain controller (DNS server) as a Twingate resource and the client can resolve all requests now. This would mean that the requests go through Twingate instead of using the IPsec VPN though (that might be fine but I don’t fully understand why this is occuring).
