Added support for automatically disconnecting from a tunnel when connected to a specified Wi-Fi network.

[asivery]

Added support for automatically disconnecting from a tunnel when connected to a specified Wi-Fi network.

How does this work for users?

Now when editing a tunnel, there's a field in which the user can enter the names of networks, connecting to which will cause this tunnel to be disconnected.
There's also a checkbox that will enable or disable this functionality for this particular tunnel.

What changes were made to previous components to support this?

1. In tunnel: Two new config fields were added:
   • enableAutoDisconnect (boolean) - whether or not the feature is enabled
   • autoDisconnectNetworks (string) - the comma separated list of SSIDs
     These values are stored in the WgQuick config as comments following the scheme ADD;key;value:

   #ADD;wifi_auto_disconnect;<1 or 0 - enabled or disabled>
   #ADD;wifi_auto_disconnect_networks;<networks>
   

2. In ui:
   • Added the libs.androidx.work.runtime.ktx library for Job Scheduling
   • ConfigProxy was reworked to add the two aforementioned config fields
   • tunnel_detail_fragment and tunnel_editor_fragment now have separate sections for this feature
   • Added the required permissions in Android Manifest (Location permissions are needed in order to get the SSID of currently active Wi-Fi connection)
   • TunnelManager now contains the code for the worker which detaches and (re)attaches a new NetworkCallback every 15 minutes, so that android doesn't kill it. The worker is started and stopped depending on whether or not a tunnel with the feature enabled is active. If the last tunnel which uses this feature is DOWNed, the worker will be cancelled. If there are no tunnels which use this feature, the worker will not be started.
   • TunnelEditorFragment now contains the code for checking the location permission, needed for requesting the SSID. If the user refuses to grant the permission, the feature will be disabled.

Limitations and possible points for future improvement

• The way this feature stores data in the tunnel config files could be improved - I am storing them as specially formatted comments, so that there will be no conflicts with any other software that might use WgQuick-formatted tunnel config files.

Why was this added?

If NAT hairpinning doesn't work correctly in a Wi-Fi network, and there is a tunnel to that same network open, all packets will go through Wireguard, and eventually get dropped. With this feature active, the Wireguard app will terminate the tunnel once the user connects to that network, and, as a result, the user will still have an internet connection.
This is already a feature in the iOS app, but there it has more features (it can f.ex. auto-connect to a tunnel when connected to a certain network).

[msfjarvis]

Can you add a use case for this in the PR description? You've explained how and what but not why, which is a necessity for something this big.

Was this feature discussed somewhere prior to implementation? I can't seem to find anything on the mailing list.

[asivery]

@msfjarvis I've added an explanation. I didn't discuss this feature on any mailing list, because I wasn't aware there was a mailing list. If needed, I can close this PR here, and first discuss it on the mailing list.

[Svenum]

I am waiting for this for a year now. Nice work. If this works then only the automatic connecting to the tunnel if you disconnect from the SSID is missing.

[da-anda]

@msfjarvis if you search the web on how to automatically disable WireGuard on local wifi, you will get a ton of hits where people are looking for exactly this feature.
I am also looking for this for ages, because the VPN causes random issues when I am in the local wifi network. There certainly might be ways to fix this via a special router config as my FritzBox is supposed to support DNS rebind protection (which is hairpinning I suppose?) - but not everybody understands this stuff (me neither). Such a toggle however is as easy and userfriendly as it can get.

[m-klecka]

Will this ever get implemented? I'd like to automatically disconnect from my home VPN, when I'm at home.. And not rely on third party apps to do that.

[bmoore]

@msfjarvis and @zx2c4 Can we get this reviewed and merged? So many people would love this feature, and are looking toward other apps to solve it. I've experienced this with iphones and it's a dream.

[heikojansen]

I'd really love to see this merged BUT I wonder if the opposite functionality - reconnecting the VPN tunnel once the device leaves the configured networks - is also available?
Otherwise I might not notice that I lost VPN protection and would have had to manually reactivate it prior to sending sensitive data over untrustworthy networks ...

[tom-jm69]

Hey, what's the state of this?
I really want this to be merged, because when coming home, the VPN connection is still active :)

[advert665]

I just want to add support for this. The iOS client has it, the android one should too. It's so useful to just disconnect automatically when home and then reconnect when I leave.

[ktmaul]

@msfjarvis I'm curious what's needed to get this integrated into the app? This feature is already present in the iOS and MacOS versions, and there's plenty of easily discovered discussion out there on why users would want this feature.

[zx2c4]

My hesitation about this is that, due to wifi autoconnect, this makes it possible for an attacker to knock a user off the VPN. On iOS the OS provides this functionality for us, and all the dangers that entails. Here we're explicitly adding the potential vulnerability, which makes me uneasy.

That's not to say that I'm nack'ing this. I'm just kind of hesitant and not totally convinced yet that it's a wise whistle to add.

Thoughts on this?

[da-anda]

shouldn't it be up to the user if he is willing to take the risk or not? And could you maybe elaborate as to how this could be exploited? If an attacker already is in my home network/wifi, my least concern would be if my phone is still using the VPN to my home network or not. And spoofing the SSID of the home network alone should not trigger the disconnect, right? It will require an established connection, no?

[da-anda]

I suppose the to is a remnant from a previous iteration of this label (..when connected to...) and should be removed now.

[da-anda]

I personally have no issue with it, but the name blacklist might offend some people these days (just like master branches etc), so it might be good to use a different term..

[bmoore]

My hesitation about this is that, due to wifi autoconnect, this makes it possible for an attacker to knock a user off the VPN. On iOS the OS provides this functionality for us, and all the dangers that entails. Here we're explicitly adding the potential vulnerability, which makes me uneasy.

That's not to say that I'm nack'ing this. I'm just kind of hesitant and not totally convinced yet that it's a wise whistle to add.

Thoughts on this?

I appreciate your concern, and I believe this feature should be implemented with a warning as such. If I'm turning wire guard off when I get home already, the vector is already there. The convenience keeps me connected more often as I don't have to remember to turn it back on.

[AXEBro]

My hesitation about this is that, due to wifi autoconnect, this makes it possible for an attacker to knock a user off the VPN. On iOS the OS provides this functionality for us, and all the dangers that entails. Here we're explicitly adding the potential vulnerability, which makes me uneasy.

That's not to say that I'm nack'ing this. I'm just kind of hesitant and not totally convinced yet that it's a wise whistle to add.

Thoughts on this?

There's a small faction of us that are using the 3rd party WG Tunnel app to fill this gap. As others have stated - I think a warning before enabling it allows the user to make the decision whether the risk is applicable to their scenario.

[asivery]

Since writing this pull request, I have switched to the WG Tunnel app. If anyone wants to make my changes compatible with the current version of this app, go for it, but I myself do not have a reason to do so now.