Network blocked in other profiles when Wireguard VPN active in Owner profile

lbschenkel

I have been experiencing this for a while (months/years) and decided to report this now. It seems to be the same problem reported here: https://discuss.grapheneos.org/d/4195-wireguard-on-second-profile-not-allowing-connections

What is happening is that if I enable a VPN in the owner profile using either the official Wireguard app or the unofficial WG Tunnel app, as soon as that VPN is active then the network becomes completely offline in any other secondary profile. This is only solved by disconnecting the VPN in the owner profile.

I don't have "Always-on VPN" enabled in system settings, but I did experiment with it on and off and it didn't change the outcome. Naturally I also made sure that "Block connections without VPN" is not enabled.

The interesting thing is that if I use the Mullvad VPN app, then this issue does not occur and the other profiles act as the VPN is not active, which is consistent to how the documentation and the explanations I've seen here in this forum say about how the VPN should work (= only in the same profile, invisible in others).

I wonder why this happens only with these two apps but not the Mullvad one? And even if the problem is with the apps, isn't it a OS bug if the app (deliberately or not) can affect networking in other profiles? Aren't they supposed to be independent and kept isolated by the OS?

other8026

lbschenkel I have multiple profiles and VPNs set up in almost all of them. I have never had any issues with a VPN being disconnected while a profile is running in the background.

Have you made any changes to settings in developer options? If you have developer options enabled, try disabling developer options completely, which resets almost if not all of the settings there.

lbschenkel

other8026 Have you made any changes to settings in developer options?

No.

other8026 I have multiple profiles and VPNs set up in almost all of them. I have never had any issues with a VPN being disconnected while a profile is running in the background.

This is not exactly the situation I have described. What I'm experiencing consistently since I started using GrapheneOS years ago is the following:

I have two profiles: "O" (owner) and "S" (secondary). I have 3 apps installed in "O": Wireguard, WG Tunnel, and Mullvad (all of them use Wireguard in userspace). None of those are installed in "S".

What I expect to happen based on documented behaviour: I enable a VPN in "O", "S" is unaffected — it will access the network without going through the VPN.

What actually happens: I enabled a VPN in "O", "S" becomes offline — every single network connection gets "stuck" until it eventually times out. As long as I disconnect the VPN in "O", then "S" recovers immediately and regains access to the network.

To troubleshoot/diagnose this I have tried the same experiment in Wi-Fi, in mobile network, with and without enabling "Always-on VPN", tried rebooting the phone, and tried enabling the VPN before unlocking "S" or after "S" was already running. In every scenario "S" has inoperable networking as long as "O" has a VPN active.

However, this does not happen when the app is the Mullvad app. In that case "S" continues to have networking, without going through the VPN (as expected). Therefore I'm very intrigued as to (1) what are the other two doing differently to result in this difference of behaviour and (2) if there is an OS bug that these apps are triggering in the way they set up the VPN that is bringing down networking in other profiles — in this latter case, my understanding is that this should not be possible.

other8026

lbschenkel I just tried this on my old phone with a fresh GrapheneOS install. I installed all three apps in the owner profile as you said you have. I set up a secondary profile without a VPN set up. I set up VPNs in the owner profile using both Mullvad and Wireguard. I was able to browse the internet in the secondary profile using Vanadium, even when the owner profile was connected to the VPN using the Wireguard app.

lbschenkel

other8026 I don't know what to say. I just repeated this exercise a few minutes ago as I posted the above (and went through testing all the apps, rebooting the phone, messing with the "Always-on" toggle, starting and restarting the profile, etc.) to make sure I was not relying on some old recollection or some old bug that was since fixed. I have a Pixel 6 with latest GOS stable. I can easily record a video that demonstrates all the above as it's 100% reproducible.

I noticed this very shortly after first installing GOS for the first time, years ago, as I quickly learnt that letting a VPN back to my home network was not usable as it prevented other profiles from working as they became "offline". It's a pity I didn't post back then.

I will do some more troubleshooting including capturing packets with tcpdump in my router to see if I can gather some additional insight. There must be some explanation for why I see this and others don't?

Note that I'm a software developer with 25+ years of professional experience (including Java/Kotlin/Android) and hands-on networking experience, so from my end any subsequent discussion can go as deep as necessary in the technical front. I really want to get to the bottom of this.

alfred

lbschenkel Have you double checked the secondary profile to make sure there is not a VPN running? From the thread you linked to, it sounded like that issue could have been using the same Wireguard config on two user profiles.

Is the secondary profile allowed to run in background? If it is not, that will stop network activity while you are in the Owner profile. Not sure that is the issue here, but may be something to check.

other8026

lbschenkel I don't recall anyone else reporting this same issue in the past, so at the very least it's very rare. I'm curious what could have caused the issue you're experiencing.

The phone I tested with is also a Pixel 6, but I flashed a recent alpha to it, so it's Android 15. I'm unsure if there are any changes in Android 15 that might address the issue you're experiencing.

Of course if you figure anything out, let us know. I'd bet that whatever it is is caused by an upstream bug, but it may be of interest to the GrapheneOS developers.

lbschenkel

alfred Yes. I'm 1000% certain. There is nothing configured there, nor any VPN app installed.

alfred

lbschenkel I tested with Android 14, Wireguard running on the Owner profile, and everything works in the secondary without a VPN. So not sure what is going on on your device. That is really bizarre.

Probably9857

This is just a shot in the dark, but is it possible that your Wireguard is configured in such a way that it's trying to use the same port (on the phone) in both profiles.

I've heard of people having this problem with other apps when trying to run at the same time in 2 profiles.

lbschenkel

OK, given that it became clear that I'm alone experiencing this issue, it means that there's something very particular to my phone or VPN or network that is triggering it.

Then it came to me: in my home network, DNS via UDP is hijacked, DoT is blocked and well-known DoH servers too. Only my own DNS server (that implements all 3 protocols) can be used. This is so nothing in my network can bypass my DNS server and any domain rules I might have.

I then played with the "Private DNS" option in GOS and behold: once I changed it from "Automatic" to "Off", the other profiles immediately started to work. And what's more strange, if I change it back to "Automatic", it continues to work too. So mere changing the setting is enough to "fix" the issue.

I just found this out so I need to more experimentation and do some packet capturing as well, but what I suspect that is happening is the following:

When "Automatic" is chosen, the OS auto-detects my own DNS server when in my local network (I tested this before and I know it works: the label changes to "On" and I can see the queries arriving via TLS/HTTPS and not UDP 53). Then I am away from my network, "Automatic" ends up not using any DoT/DoH server, but then I connect to the VPN, and Android "Private DNS" algorithm detects my server again and configures the system to use it.

However, this will only work via the VPN. Other profiles are not in the VPN, but they attempt to use the private DNS anyway as this is a global setting. It has a private IP address, and therefore in the secondary profile it goes to the actual network and it is routed to nowhere and queries are never answered. Eventually they time out. I guess that it might even be the captive portal detection in the secondary profile that is failing and "holding" all other connections from ever completing.

Given that I just found this out and I'm reporting it here, a few details about the above may be slightly off but I think the explanation is consistent. With this new knowledge I'm going to spend more time in the upcoming days to do more testing and gather more evidence.

But it looks to me, even though everything is behaving as it should in a way, the "Private DNS: Automatic" setting in my specific setup ends up being a way in which the VPN in the owner profile ends up affecting a global state at the device level and then "poisoning" the other profiles.

GrapheneOS

Private DNS should be set to Off when using a VPN in secondary profiles. It behaves strangely otherwise. You should use an app supporting both DNS configuration and a VPN tunnel if you want to change how DNS works when using secondary profiles.

lbschenkel

GrapheneOS I understand, but just to make it absolutely clear: I am not using a VPN in secondary profiles, only in the owner profile, but I am using a VPN and secondary profiles (I believe that is what you meant).

Out of curiosity: what's the default in modern Android for Private DNS, is it "Off" or "Automatic"?

I my particular workflow it's indeed not a big loss to change it to "Off", as the intent is to use an app such as WG Tunnel which auto-enables the VPN to my home network when I'm not at home. However, another solution that could work is to actually make my DNS publicly accessible and set the address manually instead of relying on the automatic detection. The address will work with and without the VPN.

Note that although I don't necessarily consider this a very serious problem (and I know this is an upstream one and not in GOS), this is a real-life scenario that demonstrates how the "Automatic" "Private DNS" feature can "leak" state from the owner to the other profiles. Leaking not in the sense that data is revealed, but that the "VPN state" of the owner profile ends up affecting the others — in my case it breaks resolution, but it could have "worked" and caused other profiles to use a "top secret DNS server" that should only have been used when connected to the VPN on the owner profile.

On the surface, if my superficial analysis of how "Automatic" works is correct, then it looks that it would be more sensible to me if the algorithm doing the detection makes sure that it never uses any active VPN (after all this is a global setting and VPNs are per-profile), so it will never risk detecting a DNS server that is actually just reachable by the active VPN in the owner profile and "publishing" that server to the other profiles.

splattergames

lbschenkel it defaults to "auto" by default. Please do not set your DNS to be publicly accessible. That's recipe for disaster in the making.

lbschenkel

splattergames I know better than that, I was discussing only with the perspective of the possibilities of configuration in the Android/GOS side that would work with my setup.

But that said, if your fear would be to expose the hostnames of my internal network, I have multiple layers of DNS servers and if I were to expose it would be the outer one that only looks up for public names and does DNSSEC validation. This one is basically a self-hosted instance of a "public" server. It lives in the DMZ as everything else that could be accessed from the outside.

splattergames

lbschenkel I don't know what your setup is exactly, but as far as I understand, you would have a DNS server publicly accessible for everyone, which is called "open resolver". These can (and are) regularly used in DNS amplification attacks. If you have your DNS hosted on a non-business IP (meaning: at home) your ISP might also block all traffic if they detect any on :53. Not to mention, the danger of DNS poisoning attacks. It is generally seen as a big no-no to selfhost DNS.

lbschenkel

splattergames Right, I didn't realize that is what you meant at first. Sure, I am aware, but if I were going to do this I'm talking about "Private DNS" and therefore only about exposing DoT and DoH, and not UDP port 53. Therefore any amplification attacks don't work as they can't spoof the source IP and force the reply to go elsewhere but the source.

Regarding ISP, I'm lucky to live in a place where you have a choice of sensible ISPs that don't come up with this "business" and other bullshit and if you ask them they give you a public IP and let you have traffic on port 53 and 25 and what not as long as you're responsible. If they don't get any abuse complaints nor detect any problems then they don't get in the way. If they do, they remove your "toys" and that's it. Luckily for everyone involved I do my homework and we have been having a very happy relationship for 15 years...

But anyway, this particular sub-discussion is off-topic and this will be my last response on that subject. The point of this was not to discuss networking in general or the intricacies of self-hosting various services. I just wanted to say that from the perspective of not breaking the secondary profiles when a VPN is on in the owner profile, either a setting of "Off" or a setting off "Manual" with my own server for "Private DNS" would work.