GrapheneOS
[feature request] - add a configuration option to add exceptions to "Block connections without VPN" mode
Android already features infrastructure for adding particular apps to a whitelist that allows them to bypass limits of VPN lockdown (aka "Block connections without VPN" )
https://xdaforums.com/t/adding-exception-to-block-connections-without-vpn-question-my-research-so-far.4081883/
This infrastructure is hidden deep and mostly unused. There are situations where ability to bypass VPN is desirable for a small subset of apps (particular trusted banking apps that I might want to be able to use even if VPN is down hard, navigation app, etc.) but allowing random components of the system, browsers, assorted messengers and social networks to leak out in case of VPN breakdown is still undesirable. A straightforward solution would seem to leverage the existing "exception from VPN lockdown" infra. Might want to put it into Developer Options to make sure that only people who really want it and read the manual can use it.
It would be nice to add LAN connections as an exception to the VPN, since that's reserved as a paid feature for most VPNs.
, @An-anonymous-coder it would seem "standard" feature several "hairy" high-penetration multi-protocol V2Ray/RealityXTLS/Trojan/etc apps like hiddify (or maybe it was happ-proxy? ) even if you use those with a free service...
but now that you have mentioned it, the VPN lockdown mode ("block connections without VPN") breaks this functionality
Which is now that I think of it a gripe of mine because I love using FTP over USB tethering interface to move large numbers of files from the phone to the PC (using "normal" way would take literally forever, and I would rather not enable ADB debugging unless actually needed) and of course that breaks if VPN lockdown is on I run into this every now and then, curse under breath, and then forget.
Also had to move my LAN CCTV app to a work profile because of this.
I would presume that if bypass VPN master whitelist was implemented in Graphene and you would add your "LAN aware" app and then enable "allow LAN access" in the VPN app (or exclude the "LAN-desiring" app via split tunneling) things would work out reasonably well without need for extra "lan specifically" feature
but now that you have mentioned it, the VPN lockdown mode ("block connections without VPN") breaks this functionality
It's currently intentional that it does this It can be worked around using profiles as you discovered, which is safer in terms of avoiding unintentional leaks. Support for this could be added upstream but it's not clear if it's a good idea.
While I agree legitimate use cases exist for such a toggle (obviously recognized in part by the mere existence of the whitelist/app bypass function), I think I agree more that lockdown_vpn is too sensitive a traffic (including localhost traffic) leak 'default deny' to be able to punch holes through from userspace.
I'm not familiar with the commercial VPN service feature mentioned above, but from the perspective of a privately hosted VPN with GOS devices connected road warrior-style via natively configured AOVPN profile, VPN lockdown seems to be the lowest any network filter goes in the AOSP network stack (i.e., "a netd blocking rule for every UID except for the VPN UID and UID 0 (root)") while out on the road and with SIM connections enabled.
@thestinger What would cause the checkbox to make a built-in IPsec VPN profile 'always-on' be greyed out? Something to do with Private DNS explicitly enabled by hostname?
What would cause the checkbox to make a built-in IPsec VPN profile 'always-on' be greyed out?
It's not relevant to it.
I know it is not exactly relevant to the issue but if I may ask a tangential question is there a known rationale why "VPN lockdown" was not done by means of policy routing (which has very convenient uidrange and priority features) or iptables/nftables/somesuch ?
Is there some intrinsic unreliability or performance problem with those?
@LindaFerum This feature request is helpful. I don't know the answer to your question but FWIW...
I would take a step back and suggest that "Block connections without VPN" is obscure to the point of not being useful, unless one knows (as you all seem to) how to leverage this via various filter lists. Logically, those filters would appear in the same place in the UI. So for example a table would pop up below the toggle where I could enter 172.16.0.1 (so I could log into a hotel wifi, which is a very common problem and perhaps the most common use for this toggle).
And of course, just because App A should be allowed to hit 172.16.0.1, doesn't mean that App B should have the same privilege (not that you said that). So the problem seems to need filtering by app as well. But that all gets very complicated very quickly. Hence my personal workaround for 172.16.0.1 (which will also apply, with minor changes, to other VPN bypass needs):
-
Get into the Owner profile. If you're in another profile, then Owner is still active, meaning you have more than one VPN context at the same time, potentially with different policies. Chaos! Ditto if you've set "Allow running in background" for any profile.
-
Disconnect from the internet. Probably this means airplane mode.
-
Go into the phone's VPN settings (under "Network & internet") and disable "Block connections without VPN". But keep "Always-on VPN" enabled.
-
In Apps, clear your VPN storage and cache (so if you might need to log in again and reset all configs and exit node). Do the same with your browser, e.g. Vanadium. (I'm assuming that you don't want persistent browser state anyway, so good riddance!) If you don't do these storage clears, then you'll dump previously-VPNed traffic on the local network (e.g. due to Vanadium page autorefresh), which instantly makes them equivalent from a traffic identification perspective, even at the target website end. (Not that VPNs are anonymous but we don't need to exacerbate the problem.)
-
Go into Permission Manager and open up the Network permissions.
-
Disable Network permissions for everything except the VPN app itself and the browser. Just make a note of the apps you've disabled.
-
Connect to wifi.
-
Do your bypass business, for example log into the hotel wifi via 172.16.0.1 (or, failing that, go to google.com and let it redirect you, after jumping through several security warning pages).
-
Close all the browser tabs and then close the entire browser so hopefully it will stop jabbering.
-
Enable "Block connections without VPN".
-
Clear the browser storage so as to force it to forget its local network context, such as the hotel you just logged into.
-
Open your VPN app, login (if needed), restore your settings (or randomize them), and connect to your desired exit node (which should work because your wifi hasn't disconnected since you signed into the hotel, so your per-connection-randomized MAC is actually still the same, and thus privileged by the hotel).
-
Reenable Network permissions that were disabled in step 6.
-
Use the internet normally.
If this procedure could somehow be simplified without creating leaks, even for just the 172.16.0.1 case, life would be a lot easier for a lot of people. I'm pointing this out just to raise awareness, not because I have a magical solution.
@graphener Wi-Fi captive portals are detected by connectivity checks with a VPN active and the OS captive portal handling bypasses the VPN automatically. If you want to have applications bypass the VPN, you should use a secondary profile without a VPN since each profile has their own VPN configuration. Profiles are the right way to have different VPN handling for different groups of apps.
@thestinger The Captive Portal system app has never worked for me. I've got my VPN in always-on mode, so that would explain it except that I think you're saying Captival Portal has an implicit right to bypass. In which case I'm stumped as to why I always need to resort to the antics above. I don't want to bypass VPN for any other reason.
The captive portal app is supposed to bypass the VPN similar to connectivity checks.
The issue with using multiple profiles to work around VPN lockdown mode restrictions on local network connections is that my use case is syncing files that are present in my main profile via LAN. Being able to exclude apps from VPN lockdown mode or allowing local network access while in VPN lockdown mode would be super helpful.
@CrossRoast What defines "local network access" when you're connected to a VPN?
@CrossRoast What defines "local network access" when you're connected to a VPN?
You know what it means. Being able to access devices on the same subnet as your main network interface and/or whitelisted LAN address blocks.
I do not agree that that's what "local network access" means (nor do I think that's a very coherent definition of a LAN, either).
By VPN, you apparently mean a (presumably commercial) VPN service that you're utilizing to egress your device traffic out to the Internet. This is but one limited VPN use case.
Another much more common VPN use case, for example, is to connect to a VPN that hosts private resources from a remote network. In this case, the VPN connection actually provides so-called 'local network access.'
The point is that tunneling traffic from your device to a remote VPN over your own LAN may very well be a legitimate use case. But the sensitivity of such a use case should preclude the need to simultaneously access local network resources outside of that tunnel.
If you merely wish to tunnel all device traffic leaving the LAN edge but maintain connectivity to LAN resources, then policy-routing would be a much more effective solution and doesn't require any complex changes to such a sensitive component of GOS's VPN logic. That way, when you're not on your own LAN, there's less potential for VPN leak.
I do not agree with your objection either and I believe you're being obtuse on purpose. I would still define the network you're accessing via VPN as a remote network, not local. Whatever we call it, the idea is the same.
Whether the VPN is commercial or corporate, the ideal solution is the same. Traffic must go where it's intended to go.
Addition of an option to allow local traffic should not lessen the security of forbidding it in any meaningful way, apart from user error. It would be optional, after all. On the other hand, policy routing without VPN lockdown is susceptible to VPN daemon crashes. If a VPN daemon crashes, even with the Always-On toggle enabled, traffic continues flowing outside of your LAN without the VPN.
You can 'define' things however you want. That doesn't bestow any credible networking knowledge upon you.
It's clear from your reply that you don't follow mine.
VPNs can already allow local traffic if they do it properly.
https://github.com/mullvad/mullvadvpn-app/issues/9550#issuecomment-3670669904
Mullvad states that VPNs can't work around "Block connections without VPN" to provide local network sharing. That was my understanding too, since they work with limited APIs provided by the system, not pure Linux root.
Mullvad states that VPNs can't work around "Block connections without VPN" to provide local network sharing.
That's not true. They can route the traffic themselves.
That was my understanding too, since they work with limited APIs provided by the system, not pure Linux root.
This is completely inaccurate and it's not clear why you're bringing up the Linux kernel here, it does not make sense.
They can route the traffic themselves.
So like—reflected back to the VPN client, if the traffic is determined to be destined for a subnet 'local' to said client?! Jesus christ. Whatta mess.
So like—reflected back to the VPN client, if the traffic is determined to be destined for a subnet 'local' to said client?! Jesus christ. Whatta mess.
I don't know what you mean by reflect back to the VPN client. If they want to implement special rules for local network IP ranges, that's something they can do without special OS support. The special OS support for this doesn't work when blocking non-VPN connections is on but this can absolutely be implemented by a VPN themselves.
I admit that I'm not using the word 'reflect' in a technical sense. 'Policy-routed back to the VPN client' would be more precise.
But I'd maintain that Mullvad is enabling a root problem here (i.e., that being locally-destined traffic leaving one's LAN edge).
You're misunderstanding what was stated. If Mullvad wants to make a feature for enabling local traffic to bypass the VPN while blocking non-VPN connections is done, they can do that within their VPN client. There's no need for them to do anything on their server.
Oooh, the policy-routing is performed via the Mullvad app. Got it.
Yeah, so then that's all a perfectly workable solution to those using VPNs in this specific way (i.e., as egress out to the Internet) and expressing support for this feature request. Completely agreed.
If they want to implement special rules for local network IP ranges, that's something they can do without special OS support. The special OS support for this doesn't work when blocking non-VPN connections is on but this can absolutely be implemented by a VPN themselves.
From what I see, VPNs on android are implemented with VpnService.Builder. It allows adding and excluding routes from your VPN connection. "Block connections without VPN" forces all packets to go through the VPN tun network interface and discards those that don't. VPNs must establish a socket to their server and then "protect" it to avoid traffic being looped back to the VPN interface. If you wanted to have a connection on the local network in VPN lockdown mode you'd need to establish and protect a socket beforehand. That would require you have a specific host you want to be connected to, instead of the entire subnet(s).
Is there another way I'm missing?
If you wanted to have a connection on the local network in VPN lockdown mode you'd need to establish and protect a socket beforehand. That would require you have a specific host you want to be connected to, instead of the entire subnet(s).
That's actually interesting. I could be convinced that the exception whitelist should be limited to only explicit RFC 1918 (and possibly also fc00::/7), meaning not globally routable, addresses.
But then—what if you're on an untrusted connection, VPN app connected, and then whatever other app or service which relies on that exception whitelist attempts a connection in the background to one of the explicit exceptions? Couldn't that traffic leave the device out onto the untrusted provider's network?
So now not only do you have to create the "Block connections without VPN" exception logic, but also logic to stop said traffic—the "Block connections without VPN" excepted traffic—from leaving the device in certain highly-specific and unpredictable connectivity scenarios.
what if you're on an untrusted connection
Then you need to remember to disable the local network exception. If you're worried you'll forget, just don't enable it in the first place.
Hate that. Could see the exception whitelist being automatically disabled upon any connectivity change. But then it feels like we're back to all this needlessly complicating what's supposed to be a privacy-protecting feature in the first place.
I do agree, though, that if there's a legitimate need to tunnel device traffic over a LAN, then there becomes no way to access anything else on the LAN with "Block connections without VPN" mode enabled. It's all-or-nothing in that way with built-in VPN profiles. I've learned that some VPN apps contain policy-routing functionality to 'circumvent' this protection. Interesting.
Linking Mullvad discussion here for reference: https://github.com/mullvad/mullvadvpn-app/discussions/9552