VPN killswitch - conflicts with local connections and captive portals

EphemeralPermanence

Dear all,

I always have issues with having to toggle off my "block connections without vpn" toggle and the vpn connection entirely whenever I have to connect to public wifi. Then, when I access the captive portal and accept terms and conditions, I have to very quickly turn on my VPN in order not to leak my IP. I actually have no idea whether this is even correctly addressing potential IP address leak.
Could you please tell me how are you making sure that there are no IP address leaks when connecting to public wifi with captive portals?

Are there any plans from the grapheneOS developers to at least add a feature to allow local outgoing connections when having "block connections without vpn" toggled on? This would be really helpful.

Additionally, similar issue arises when using private DNS resolver. Since captive portals don't let you use the internet without previous interaction, I'd have to switch from custom domain name to automatic, accept terms, and then switch back to private one, which is very tedious and probably doesn't prevent DNS leaks until the switch. Especially when having multiple accounts and DNS settings are only accessible from admin account.
Is there a way to also address this issue?

Thank you.

Mintou

EphemeralPermanence try whitelisting the portal app from your vpn, I forgot the name but it's on system app.
Basically it's a mini browser that works only for portals.

GrapheneOS

EphemeralPermanence The built-in captive portal handling triggered by the connectivity checks already works with a VPN when leak blocking is enabled. This is already a supported feature. It sounds like you disabled connectivity checks and are using a browser app to handle the captive portal instead of the dedicated WebView-based captive portal login app which is triggered by a connectivity check. No need to disable your VPN or disable leak blocking to handle captive portals.

Private DNS is not a feature we generally recommend and this is one of several downsides. If you're using a VPN, mixing that with Private DNS will make you stand out from other users.

GrapheneOS

EphemeralPermanence Turn off Private DNS. If you turned off connectivity checks, turn them back on. When the OS prompts you to handle the captive portal, use the notification to open the captive portal handling app built into the OS. This approach will work with an always-on VPN + leak blocking.

GrapheneOS

Mintou Whitelisting apps in a VPN app doesn't work when leak blocking is enabled. It isn't needed anyway because the captive portal app already works with a VPN active due to having special handling.

EphemeralPermanence

I'm not sure if this would work. Killswitch is android setting and not in-app setting.
Besides, when I connect to new network with captive portal, VPN won't connect until it gets internet access. It will stay in permanent "trying to connect" loop. This prevents all non-vpn connections at the moment. When I turn it off, the "block connections without vpn" toggle kicks in and blocks all connections, even local ones. Then I have to toggle it off in order to connect to captive portal, accept terms, but then I have somehow to quickly start vpn connection in order to prevent IP address leak. As you see, it's very bad for OpSec.

AloofChocolate

I had a similar issue a while back, and the best fix depends on the VPN app you're using. Go to Settings, Network & Internet, and scroll to the bottom for VPN. Open the gear icon next to the VPN app and deselect Always-on VPN. Return to the home screen, drag down the tab menu and rearrange the app VPN tab.
With this technique, the VPN is not continuously running in the background and can still function as intended when the user requires it through the tab menu.

GrapheneOS

AloofChocolate No, this is not needed to use captive portals. Always-on VPN with leak blocking enabled is fully compatible with the standard captive portal handling in the OS.