The prob seems to be the same as reported a year back (closed) here: DNS leak with WARP
BUT, this is new 26/5/22…
Basically, WARP is not doing the resolving, but if flicking resolution over to win10 eth config
– I’m using WFC v6.8.1.0 firewall to test the various hypothii
– Set DNS of win10 via eth card to anything else (such as AdGuards 94.140.14.14 and15.15). Poke firewall rules to allow traffic
– Set up fresh WARP client. Poke firewall holes for 1.1.1.1 and 1.0.0.1 port 53
– WARP client is ON (connects SYD)
OK. This is where it gets weird.
– Using cmd (or powershell)… ping something novel such as foo.com
– Comes back with IP and ping
– BLOCK firewall to AdGuards DNS.
– Ping something novel example.com
– NADA. No resolution.
– Turn off firewall (or change rule to ALLOW) and it resolves… WTF!!!
– Next, check log. Yep, from step above for foo.com the svchost.exe DNSCache wants to get to AdGuards IP’s
HOW IS THIS POSSIBLE if WARP is a VPN and (should be) intercepting ALL the traffic (inc DNS)?
i.e. WARP is leaking ALL DNS requests to use the OS and sending them via svchost which is a Very Bad Thing.
I note that in the WARP client that Preferences–>Connection–>DNS protocol is now set to HTTPS rather than WARP. (it used to be warp, from memory). Upon selection of WARP as the protocol is is ignored and flips/changes it back to https as soon as a different menu-preference is chosen.
This is the result of a nslookup with WARP ON
PS C:\Users\nobody> nslookup foo.com
Server: dns.adguard.com
Address: 94.140.14.14
Obviously NOT what we want… seems to be a bug.
NOTE: I’ve tried this in all permutations to confirm the behaviour - with the firewall on/off, rules on/off, WARP on/off and setting the Eth dns to 1.1.1.1 (which works, but isn’t what we want).