DNS traffic can leak outside the VPN tunnel on Android

[Mr-Hitchens]

We are happy to answer your questions about the code or discuss technical ideas.

Please complete the following checklist (by adding [x]):

• I have searched open and closed issues for duplicates
• This isn't a feature request
• This is not a report about my app not working as expected

---

Source: https://mullvad.net/en/blog/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android

I am assuming PROTON is also vulnerable to this problem. How are you addressing this problem?
As PROTON hasn't updated F-Droid in nearly 5 weeks (Google play is up to date) I'm using a VPN that has addressed this issue as a temporary fix.
Is F-Droid not updated because F-Droid has a much more stringent gateway than Google and your app didn't pass inspection or something worse?

[Red00488]

GrapheneOS latest OS release, currently in the Beta channel, implements a new feature for blocking DNS leaks by third party VPN service app implementations. The ProtonVPN app is reportedly having issues with the new feature.

GrapheneOS has stated "We'll give it another couple days of testing. Unless our users find an issue with another VPN app, we'll likely ship this to the Stable channel instead of cancelling the current change. We can't hold back an important improvement based on a single app which appears to be buggy."

https://grapheneos.social/@GrapheneOS/112422961319281582

[edthedev]

I'll be happy to help test any patch for this, if needed. When the Stable branch of GrapheneOS hits my phone, I imagine I'll have this issue.

[mateusz-markowicz]

GrapheneOS latest OS release, currently in the Beta channel, implements a new feature for blocking DNS leaks by third party VPN service app implementations. The ProtonVPN app is reportedly having issues with the new feature.

We did some investigation into GrapheneOS issue and it'll be followed-up here:
GrapheneOS/os-issue-tracker#3442 (comment)

[thestinger]

It's still in our Beta channel and we don't plan to move it to Stable until we resolve this compatibility issue. It's strange that it only seems to be happening with Proton VPN and it doesn't imply that it's a bug in Proton VPN but it COULD be one where it was depending on a leak happening before. We aren't sure what's wrong yet.

[mateusz-markowicz]

@thestinger we managed to reproduce it with some minimal generic VPN app, so it doesn't seem to be anything specific about the client itself. What seems to make the difference is the range our DNS server IP belongs to (10.2.0.1, it's not a public IP and it's accessible only via the tunnel) - if we change it to some public IP like 1.1.1.1 problem goes away - and maybe that's the usual setup for other VPNs (I didn't check that yet, so just speculating) and reason why they are not affected

[flawedworld]

@mateusz-markowicz do you think you could push this minimal app source code please?

My very vague and speculative hunch is that when the VPN is down, and the killswitch is set in the OS, you have a route for 10.2.0.0/24 in routing rules (or some other range where the DNS server is within it), and due to the VPN being down, and the DNS server being within that range, the OS drops all of that traffic, and there is some form of issue then occurring where it would normally fallback to using OS/user provided DNS server and this is what is breaking atm.

[mateusz-markowicz]

@flawedworld I'll try to provide the source tomorrow (I'm off for today), but important to note that we observe this behavior on current GrapheneOS beta regardless of whether kill-switch is on or not and DNS starts failing only after VpnService.Builder.establish() when VPN is actually up - we see successful WireGuard handshakes preceding failing DNS queries.

[mateusz-markowicz]

@flawedworld see https://github.com/mateusz-markowicz/minvpn-dns-issue/blob/master/app/src/main/java/proton/example/vpn/WireGuard.kt. We do there HTTPS call just before opening the tunnel (it works) and then a moment after opening a tunnel. If config will have our DNS (10.2.0.1) second call will fail. With some public DNS it'll work fine. @guandalf will contact you about the config