Provide an option to disable fallback

[lessload]

Issue Details

• AdGuard version:
  • v3.4.120
• Filtering mode:
  • Local VPN, DNSCrypt (Adguard)
• Device:
  • Mi CC9 Pro (Xiaomi)
• Operating system and version:
  • Android 10
• Root access:
  • No

Expected Behavior

App should always filtering traffic or have something like Kill Switch. and stop only when disable protection.

Actual Behavior

After update to v3.4. I found dns traffic leak to my pi-hole randomly but too many dns leak. Adguard show as protection enable but traffic still leak need to re-enable to fix it. i always active Adguard, and enable Always-on VPN function in android setting. The traffic that leak not show in Filtering log. Please check.

Additional Information

[already set battery - No restrictions / enabled - auto start] but when update blocklist it couldn't leak the traffic. it shoult have something like kill switch to protect the traffic.
Adguard not work with multi-user android? (dual-app on MIUI)

[lessload]

Long time test nothing can fix. not sure the problem was from. now go back to 3.3.3. Not found such a problem.

[ameshkov]

@lessload is there any change when you select DNS-over-HTTPS traffic?

[lessload]

@lessload is there any change when you select DNS-over-HTTPS traffic?

it's still leak. it may MIUI campatibility problem.

[the4anoni]

I've got dns leaks too.
Galaxy S10 OneUI 2.1

Leak was from mobilewips app com.samsung.android.server.wifi.mobilewips.client

[the4anoni]

@lessload is there any change when you select DNS-over-HTTPS traffic?

I used Opendns DoH in adguard

[Chinaski1]

To troubleshoot the issue, I would ask you to collect the following information:

• AdGuard > Settings > Advanced > Logging Level > Record All.
• Reproduce your issue.
• Note the time the error occurred and let us know.
• Don’t forget to return to the default logging level.
• Logs can be sent on devteam@adguard.com

[flammschrein]

Logs received from 2520013.

[the4anoni]

I've got dns leaks too.
Galaxy S10 OneUI 2.1

Leak was from mobilewips app com.samsung.android.server.wifi.mobilewips.client

My mum Galaxy S9 with latest AdGuard 3.5 nightly 3 also has dns leaks.
Sample leaked domains:
lh4.googleusercontent.com
connectivitycheck.gstatic.com
dls-udc.dqa.samsung.com

[ghost]

I've got dns leaks too.
Galaxy S10 OneUI 2.1

Leak was from mobilewips app com.samsung.android.server.wifi.mobilewips.client

Подтверждаю

[ameshkov]

Quick update on this.

1. AdGuard may fall back to the system DNS if the upstream DNS does not answer in 2 seconds which may happen.
2. This is intended and there are multiple reasons for making this the default behavior. Otherwise, AdGuard would break authentication in some hotspot Wi-Fi networks. Also, we don't want to break internet access when the upstream is not available for some reason.

You can change the fallback DNS server addresses in the low-level settings.

@artemiv4nov what we need to do in this task is providing an option to disable fallback via low-level settings.
For instance, we could change the default behavior when pref.dns.fallback is set to "none" -- explain this in the description.

How to test fallback:

1. Set upstream DNS to some non-existing DNS server
2. Check the filtering log -- what "Upstream" server is shown for DNS queries there
3. Disable fallback
4. Ensure that the internet does not work anymore

[techIndia-hacker]

Got dns leak from adguard 3.2.120, android 10 One UI 2.0

Used cloudfare dns over TLS

Steps to reproduce-

Turn off internet completely for android device
Restart device
After reboot start adguard vpn, grant root access.
After vpn services have started, turn on the internet now.
Open chrome now.
Observe vpn logs. I found multiple DNS resolution request through system default dns.

Temporary fix-

Turn off internet.
Stop adguard vpn and delete vpn profile for adguard
Switch back to adguard app and toggle the switch.
System OS requests vpn creation permission. Wait.
Turn on internet now and then grant vpn permission.
The dns leak can't be seen anymore
A note:-Chrome bydefault uses Google DNS to resolve queries. We need to disable this feature before adguard can actually block chrome dns requests. Go to Chrome://flag. Search for DNS. Disable what u see

[techIndia-hacker]

While I carried out the test 1.1.1.1 was perfectly reachable from my pc @60ms

[ameshkov]

Observe vpn logs. I found multiple DNS resolution request through system default dns.

Could you please show a few records?

[techIndia-hacker]

Yeah I have mailed 4 screenshots at support@adguard

[techIndia-hacker]

Another update. Chrome 84.0.4147.89 uses inbuilt DNS resolver activity and does not send resolution requests anymore.

Steps to reproduce my observations-

1. clear chrome data. Let's start clean🙂 to avoid cached dns
2. open adguard filtering log and now tap the chrome icon
3. initially few domain resolutions get logged like update.googleapis.com etc as u go though the initial setting options ( or u may not because of DNS request leak though system dns as discussed in previous comments)
4. wait a minute for initialization to complete and then type in any website like Sony.com or ti.com. just see that u don't have any app installed that also visits same website otherwise it will be confusing.
5. i didn't observe any domain resolution requests that match with the site i visited

Temporary fix-
Restart adguard while keeping internet on

[techIndia-hacker]

Ok breakthrough in experimentation 😅😅😇

Disabling "pref.vpn.disable.reconfigure" in low level settings solves the DNS leak issue 100% according to my observations atleast on my phone (samsung android 10 one ui 2.0) for most apps like chrome etc

But some apps uses tcp://8.8.8.8:53 for dns. They r still leaking. These things are hardcoded into specific apps I guess.

[lessload]

Ok breakthrough in experimentation 😅😅😇

Disabling "pref.vpn.disable.reconfigure" in low level settings solves the DNS leak issue 100% according to my observations atleast on my phone (samsung android 10 one ui 2.0) for most apps like chrome etc

But some apps uses tcp://8.8.8.8:53 for dns. They r still leaking. These things are hardcoded into specific apps I guess.

I can accept some traffic leak from hardcoded. But can not accept when it leak while Adguard update itself (a lot of traffic leak show on Pi-Hole) (sorry if you already fix it, i still use old version)

For me, Block Google DNS make all (maybe) traffic go through Adguard app.

[techIndia-hacker]

I can accept some traffic leak from hardcoded. But can not accept when it leak while Adguard update itself (a lot of traffic leak show on Pi-Hole) (sorry if you already fix it, i still use old version)

In the previous versions of adguard vpn or proxy reconfiguration was not needed to prevent dns leak but in latest version it's the only fix I found [I am not in anyway linked to adguard development team].

But u r taking about leak during update which is quite normal as the vpn or proxy is killed and restarted shortly after update completion. Though this issue should be fixed, it was there from the very beginning.

For me, Block Google DNS make all (maybe) traffic go through Adguard app.

Yeah i tried that but websites load very slowly if done, according to my observations

[artemiv4nov]

I have checked in latest nightly too. Only solution for me is to enable vpn reconfiguration on network change
…

Did you try to disable the DNS fallback at all? I described this case a few comments above

[techIndia-hacker]

Yeah it's set to none

…

On Thu, 20 Aug, 2020, 4:52 pm Artem Ivanov, ***@***.***> wrote: I have checked in latest nightly too. Only solution for me is to enable vpn reconfiguration on network change … <#m_8643084292967767579_> Did you try to disable fallback at all? I described this case a few comments above <#3447 (comment)> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3447 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN3FHQ47H45LVBLBWM27KQDSBUBOJANCNFSM4NMZK44Q> .

[artemiv4nov]

@techIndia-hacker Can you send the debug logs again, please? Can't find them

[techIndia-hacker]

Search in the devteam mail box for my name

…

On Thu, 20 Aug, 2020, 4:56 pm Artem Ivanov, ***@***.***> wrote: @techIndia-hacker <https://github.com/techIndia-hacker> Can you send the debug logs again, please? Can't find them — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3447 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN3FHQ6EOAUZ7TVPXEK7O3TSBUB65ANCNFSM4NMZK44Q> .

[ameshkov]

@techIndia-hacker the latest logs are from the week ago, please collect the logs with the new nightly and send them to devteam.

[techIndia-hacker]

Ok will send u when i get time

…

On Thu, 20 Aug, 2020, 5:03 pm Andrey Meshkov, ***@***.***> wrote: @techIndia-hacker <https://github.com/techIndia-hacker> the latest logs are from the week ago, please collect the logs with the new nightly and send them to devteam. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3447 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN3FHQ45QJOWMPMY4EQ7WUDSBUCX5ANCNFSM4NMZK44Q> .

[techIndia-hacker]

Sent logs On Thu, 20 Aug, 2020, 5:31 pm Ayan Chakraborty, < ayanchakraborty3199@gmail.com> wrote:

…

Ok will send u when i get time On Thu, 20 Aug, 2020, 5:03 pm Andrey Meshkov, ***@***.***> wrote: > @techIndia-hacker <https://github.com/techIndia-hacker> the latest logs > are from the week ago, please collect the logs with the new nightly and > send them to devteam. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#3447 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AN3FHQ45QJOWMPMY4EQ7WUDSBUCX5ANCNFSM4NMZK44Q> > . >

[artemiv4nov]

@techIndia-hacker Got it, thanks. We will investigate your logs tomorrow.

[admitrevskiy]

@techIndia-hacker Hi!
This case looks like built-in Android Personal-DNS behavior. Please, check if it's enabled in system settings:

Settings -> Network -> Advanced -> Personal DNS.
For new Android versions it's enabled by default and set to Auto mode. It should be disabled, our DNS will conflict with the built-in otherwise

[admitrevskiy]

BTW about plain-DNS leaks. if you want you can use DoT server with ip e.g. tls://1.1.1.1 (if the server allows it) as a bootstrap for DoT and DoH servers: you can configure it in Advanced Settings -> pref.dns.bootstrap

Or you can use true DNSCrypt servers

But this refers to a single one bootstrap query to resolve DoH/DoT server address

[techIndia-hacker]

Private DNS is turned off even when the logs were being generated.

Bootstrap DNS is a totally different thing. It's a single DNS query sent by adguard and not logged in filtering logs section. But I get multiple DNS requests leaking to isp DNS visible in filtering logs in adguard, as soon as I open any browser. Did u even look at the logs I sent!! 😐

[admitrevskiy]

We seem to have established the cause of the leak. This bug is incredibly difficult to reproduce, because it is not reproducable on most devices. As I've seen in the logs you used Samsung with Android 10, in my case the only one device with the same behavior was Xiaomi Mi 10.

So, what happens:
When creating a local VPN we set fake DNS server to reroute all requests to.
Documentation says: Adding a server implicitly allows traffic from that address family (i.e., IPv4 or IPv6) to be routed over the VPN.
However some Android 10 devices routes their traffic via system netd (uid 1051) instead of configured in VPN DNS server.
Henceforward we will start to route all the traffic from port 53 to DnsLibs if DNS module is enabled. Nightly version will be released before long.

Why did I assume that the problem was caused by a private DNS?
Private DNS acts very similar: it uses AdGuard DNS as a bootstraper for it's DoT server and there are similar requests in the filtering log. I was a little hasty and made the wrong conclusion, it's my bad.

It's a single DNS query sent by adguard and not logged in filtering logs section.

Yep, as I've mentioned above this refers to a single one bootstrap query to resolve DoH/DoT server address and it was more of a comment about AdGuard's ability to protect you from this type of leak.

I hope our changes will help solve the problem.

[techIndia-hacker]

Ok I understand. It's nice to know that it's getting fixed.
And u r right, my OnePlus does not have this problem.
But in OnePlus adguard fails to install certificate in system store with su. That's a problem of another world 😂

Also see this Magisk-Modules-Repo/movecert#9