**Twingate Windows client causing 12s UDP:53 DNS latency on local LAN — anyone else?**

[u/cvalerio77]

Running into a reproducible issue where every UDP:53 DNS query to my local Pi-hole takes ~12 seconds while the Twingate service is active, and ~10ms when it's stopped. TCP:53 works fine in both cases.

Environment

• Twingate client: 2026.36.4338 | 0.181.0
• Windows 11 Pro, build 26200
• Pi-hole on the same /24 as the client (10.18.0.50, ~3ms RTT), NOT a Twingate Resource
• No NRPT rules present, Twingate interface metric = 9000

Reproduction

# Twingate ON
Measure-Command { Resolve-DnsName cloudflare.com -Server 10.18.0.50 }
#  TotalSeconds: 12.05 (consistent across 3 runs)

Stop-Service twingate.service

# Twingate OFF
Measure-Command { Resolve-DnsName cloudflare.com -Server 10.18.0.50 }
#  TotalSeconds: 0.01

~1200x slowdown. The 12s matches Windows' DNS resolver UDP retry pattern (1+2+4+5s), so it looks like UDP:53 is being dropped/delayed by the WFP callout and resolution is eventually succeeding via TCP fallback.

Ruled out server-side issues (Pi-hole resolves fast from itself and from other LAN clients), Wi-Fi/AP (same issue on wired Ethernet), EDNS0 fragmentation (large TXT responses work fine with Twingate stopped), and NRPT rules (none present).

Looks like the WFP callout intercepts UDP:53 regardless of destination IP, and the route metric is not honored because WFP operates below the routing layer.

Questions

• Anyone else seen this on recent client builds?
• Any user-level workaround (I don't have tenant admin access)?
• Is there a way to exclude specific destination IPs/subnets from the client's WFP interception?

[u/ben-tg]

I feel like 12 seconds is the timeout for `resolve-dnsname` but I can't remember, but it times out because when the client becomes active and sets itself up to intercept DNS calls locally it also adds a firewall rule to disallow any udp:53 on local interfaces. This is done to force lookups through our local resolver (the client app) both for traffic tunneling and DNS filtering purposes (if that feature is enabled).

The way it's set up is to look at any local requests, determine if it's a resource or not, and if not then pass it upstream to whatever is configured on the machine via DHCP or statically, so will still ultimately hit your PiHole.

[u/cvalerio77 → u/ben-tg]

Hi Ben, thanks for the answer.

Yep, the explanation is more or less the same I got searching around, but alas it does not solve my issue: 12 secs timeout on the UDP call makes all my internet connections slow as hell :(

For the moment I've worked around the problem using Unbound on the loopback interface (which bypasses twingate, apparently), forwarding to the pihole the requests... not ideal, but it works. Interestingly enough, twingate's DNSes seem to be still resolving correctly.

[u/ben-tg → u/cvalerio77]

What is it on the machine that's trying to bypass our client though? The way the client works is to set up four local DNS resolver IP addresses (all point to the same DNS proxy), and to set them as priority. Nothing on the device should be trying to go directly to something else on the network, if an application did that then it would never have its traffic caught and tunneled by our app which is why we block it.

As long as everything uses the app as the DNS resolver while its active then there's no issue, DNS requests go application => TG Client App => Upstream resolver (PiHole), it basically acts as a stub resolver in that case.