DNS not bypassed when using vpn about adguardvpnforwindows HOT 13 CLOSED

@TommyKing, the root of the issue in the opened (to be more accurate - "no closed") connection(s), which was(were) opened before all the traffic was tunneled via VPN. In other words, DNS resolve was extracted from the so-called cache. Unfortunately, as of now, AdGuard VPN hasn't a "kill connection" feature, but we are going to do it. To reach the same effect you can close the browser or e.g. close all the connections manually, clicking both buttons on the chrome://net-internals/#sockets

from adguardvpnforwindows.

@adbuker can't we add "tcpkill" option just like we do in AG?

from adguardvpnforwindows.

@ameshkov , yes of course, we'll do it.

from adguardvpnforwindows.

@adbuker if this is the case, why in my adg home query log there's vpn ip logged there after 30s no activity?

Shouldn't it use vpn's dns? And also sometimes when on i have no connection ( when i use unbound as dns in windows )

from adguardvpnforwindows.

@TommyKing , these are DNS requests to our injection server only. On the core-level, we intercept them ourselves and get the response, without resolving DNS addresses (injections.adguard.org) "in good faith" in fact. In that meaning, they are not real DNS requests, but the query log continues to show them as a DNS resolved via system DNS server without tunneling. To be shorter, you haven't worry about any kinda leak or smth else

from adguardvpnforwindows.

DNS queries that are being sent by AdGuard itself should also go to the tunnel, this is a legit issue.

from adguardvpnforwindows.

Btw, 193.56.255.114 from the screenshot is an IP address of our VPN server so it was actually routed to our VPN.

The question is why the query ended up in AGH and not in the DNS server configured in AG VPN.

from adguardvpnforwindows.

@TommyKing , could you please enable AdGuard VPN debug logging level (along with the AdGuard logging level), repro the issue, grab the collected logs (from AdGuard VPN and AdGuard) and send it to [email protected] with subject "logs for issue 42".

from adguardvpnforwindows.

@adbuker let me try...i'll sent it when it does occured

from adguardvpnforwindows.

ok got it. @adbuker sent the logs to [email protected]. please check it. let me know if you want anything else

from adguardvpnforwindows.

The issue happens only if the DNS port, which differs from the default 53, is used. Nevertheless, we can recognize DNS traffic among the other ones without binding to a certain port, but we have to work on it. This new approach will be implemented further

from adguardvpnforwindows.

@TommyKing Hi! Let me explain what's happening:

1. AdGuard VPN intercepts network traffic to port 53, which is the standard DNS port, and redirects it through our VPN endpoint to a secure DNS provider.
2. You've convinced your system resolver to, instead, use a custom DNS server address with a non-standard port.
3. As a result, your system's DNS queries go through our endpoint to your custom DNS server.

Solution: disable your custom DNS address:port trickery :) Do not worry about DNS queries leaking to your ISP: AdGuard VPN intercepts network traffic before it leaves your machine, and works transparently (meaning that your apps will still "think" they're using your ISP's DNS settings). You can use various online DNS leak checks to make sure that your ISP is not seeing your DNS queries.

As per your initial problem illustrated by the screenshot, it was most probably caused by your browser reusing a connection already established while AdGuard VPN was offline. This is a known issue and we are working on an already-established-connections-termination function.

from adguardvpnforwindows.

@ngorskikh we should file a new issue about that - allow detecting DNS traffic on the driver level (without passing it to the user mode). It's not urgent, but it'd be nice to have.

from adguardvpnforwindows.