RethinkDNS IP leaks

mmobder

aeououoieaeuaie Note that GOS comes with zero Google stuff of any kind and does not use Google endpoints for system-level activity

strange, I thought that Google servers are available for a lot of stuff in GOS, be it connectivity checks, location or widevine provisioning (though I can't recall what's the default for widevine).
Furthermore, for those who don't want to stand-out in network traffic as GOS users, it's recommended to ensure google-ones are used.
So it's definitely not zero and properly documented in FAQ

aeououoieaeuaie

mmobder Do I need to point out that this is completely unrelated to Play services from private space establishing an FCM socket and logging in while bypassing the VPN, or are you just commenting for the sake of completeness?

mmobder

aeououoieaeuaie

As you can judge from "'I'm not sure if that is also the case on GrapheneOS", @ignoramous is not certain about particular GOS behavior, which is normal.
Your "Note that GOS comes with zero Google stuff of any kind and does not use Google endpoints for system-level activity. " is factually correct only for non-modified setup, which includes privatedns=automatic, that is known to cause problems with VPN. So worth mentioning for @ignoramous re his understanding of GOS in claimed 0-goole servers GOS.

I don't see any mention about your config being non-default, including private DNS be default (incompatible with VPN) or updated to proper OFF.
Have I missed your answer to a quite relevant pre-requisite question https://discuss.grapheneos.org/d/33331-rethinkdns-ip-leaks/17 ?

Without having it OFF, one can't expect VPN+gos to work properly with it without rdns

mmobder

I do use play services/store on few GOS phones, also in private space (just services).
I haven't found connections to security... but there are some to mtalk. All were proxied. WG is in advanced. pdns is OFF, always-on + block connections w/o VPN in both main and PS. No experimental features in rdns. v055u

aeououoieaeuaie

mmobder Yeah, well, for me it only happens in 1.18% of cases, so far.

Lastly, if you explain how exactly private DNS is quite relevant here, in terms of Linux kernel primitives — processes and sockets, routes, and TUN/TAP behavior, not vague gestures at the FAQ — I might tell you if it was on or not.

aeououoieaeuaie

System connections do not matter.

These logs are from the Google takeout. Which is associated with an account. Meaning that the connections were client-authenticated. Which does not happen with system connections.

That's what we knew in the first post. Later on we learned that these were app-level connections routed to RDNS after all, and logged there, without going into the VPN. Making everything else entirely irrelevant, since now we know that this is RDNS behavior, and not an OS leak.

mmobder

aeououoieaeuaie might tell you if it was on or not

wtf man, it's an easy prerequisite question, explicitly mentioned by the gos devs - it must be off if you use VPN if you don't want problems.
if you refuse to answer this simple question, it's already weird.

Novalissoide

aeououoieaeuaie explain how exactly private DNS is quite relevant here, in terms of Linux kernel primitives — processes and sockets, routes, and TUN/TAP behavior, not vague gestures at the FAQ — I might tell you if it was on or not.

But the precise explaination you ask for won't change the outcome. If something works it works, regardless of language about it.

aeououoieaeuaie

Novalissoide True. But it will hopefully help the explainer see that the two are unrelated. The thought process will, not the language, obviously.

RDNS in its internal lockdown mode routed two entire TCP streams outside of the VPN.

Novalissoide

aeououoieaeuaie You could still try disabling Private DNS.

aeououoieaeuaie

Novalissoide I already did yell "Alkazam!" seven times. Should be fine.

aeououoieaeuaie

There it goes — again, again, again, again, again, again, again, again, again, and again.

These are all from Private space. In all the cases, RDNS was stopped. After tapping Start, it leaks the first one or two subsequent connections outside the VPN.

These failures cover 3 scenarios:

Auto-start on power-up on (RDNS has to be started on each unlock);
Auto-start on power-up off (RDNS has to be started on some unlocks);
Manually stopped, then started.

It only happens sometimes, none of the 3 scenarios is a reliable repro. Conversely, I didn't observe failures when RDNS successfully autostarts on unlock — but this is stochastic enough that it can't be ruled out yet. It took about 30 Private space unlocks, and about 20 manual stops.

RDNS v0.5.5t F-Droid; Pixel 9a; GOS 20260307 (roughly Android 16 QPR 2).

Always-on VPN is on, Block connections without VPN is on. RDNS is all off under Network, and all defaults under General (except for the notification, which is on).

Private DNS is off. Likewise, "Alkazam!" was uttered firmly, and with some conviction.

@ignoramous I consider this a bug report now. I understand that this is the wrong place for that, but I can no longer re-raise it on Github for obvious reasons. Happy to provide more info. I also tried recording PCAPs, but they never materialised.

Looks like a race condition in RDNS init.

Edit: URL wrangling.

Novalissoide

aeououoieaeuaie RDNS v0.5.5t

Maybe you could try the latest monthly Alpha, see if things have changed?

https://github.com/celzero/rethink-app/actions/runs/22505364979

jeeringsequel

I also noticed another quirk. I have RethinkDNS set up in the Owner profile with tunnels in advanced mode, DoH is enabled, and the fallback isn't set to System. The same setup is configured in another profile and everything works fine. But for some reason, there was no internet connection in the Owner profile's Private space until I selected System as the fallback DNS. When choosing a fallback DNS other than System option while using DoH / DoT, there's no internet connection in the private space. It's claimed that private space is an another user under the hood, but something's not right.

littlerack

jeeringsequel is there any DNS server in all your PS setup that is defined via IP and not a host name that RDNS can use to resolve configured DoH? Just think of the initial process of DoH hostname resolution. Is all ok with it?

aeououoieaeuaie

Novalissoide Yeah it's an old version from F-Droid, I know, but data migration "might, or might not work" as per somewhere on GH.

I'd actually like to debug this properly because if it really is a race as I now suspect that would be really, really bad, and should be fixed structurally. No time right now, have to debug other things...

« Previous Page