search

eduvpn / python-eduvpn-client

Linux client for eduVPN
https://eduvpn.org/
GNU General Public License v3.0
38 stars 37 forks source link

Connection is immediately removed when stopped #596

Open tribut opened 2 weeks ago

tribut commented 2 weeks ago

Since the latest release, the eduvpn client immediately removes the NetworkManager connection when it goes down, such as when its disabled from the Gnome control center. This makes it unnecessary difficult to toggle the connection using the system provided means and also harder to adjust the connection using dispatch scripts (changing dns priority requires the connection to be restarted, for example).

I consider this a regression and would prefer this behavior be reverted.

Installation

Ubuntu packages

Version

eduVPN GUI version: 4.3.1 with eduvpn-common version: 2.0.1

OS/Distribution

Ubuntu noble

jwijenbergh commented 2 weeks ago

This is intended. This is so that the client cleans up the connection and the IP allocation can be removed server side. If you prefer to have the connection be alive, you might consider using the cli. Or if you just close the client and then deactivate from gnome menu it will not be removed but then you will not get notified for expiry

tribut commented 2 weeks ago

Yes, I added "killall eduvpn-gui" as a workaround to my dispatch script, but that is terribly in terms of UX and is certainly not something I want to recommend to my users. It is also unclear how long I would have to sleep before to allow for tcp fallback. I could certainly start using the cli, but having a GUI is just much nicer for daily use.

Given that cleaning up the connection might fail for a plethora of reasons (and Gnome doesn't have a decent "run in background" option anyway), I don't see how this is a requirement. Would you consider merging a PR that adds a configuration option for this?

jwijenbergh commented 2 weeks ago

Yes, I added "killall eduvpn-gui" as a workaround to my dispatch script, but that is terribly in terms of UX and is certainly not something I want to recommend to my users. It is also unclear how long I would have to sleep before to allow for tcp fallback. I could certainly start using the cli, but having a GUI is just much nicer for daily use.

Given that cleaning up the connection might fail for a plethora of reasons (and Gnome doesn't have a decent "run in background" option anyway), I don't see how this is a requirement. Would you consider merging a PR that adds a configuration option for this?

Yes, I added "killall eduvpn-gui" as a workaround to my dispatch script, but that is terribly in terms of UX and is certainly not something I want to recommend to my users. It is also unclear how long I would have to sleep before to allow for tcp fallback. I could certainly start using the cli, but having a GUI is just much nicer for daily use.

Given that cleaning up the connection might fail for a plethora of reasons (and Gnome doesn't have a decent "run in background" option anyway), I don't see how this is a requirement. Would you consider merging a PR that adds a configuration option for this?

Regarding the TCP fallback. That takes a maximum of 10~ seconds. It pings the server and if it can't connect it falls back to TCP.

Regarding cleaning up the connection, I can consider keeping the profile alive if wireguard is not used, but I prefer to keep the behaviour the same regardless of the protocol used.

Note that deleting the connection has been in the client for a while now, not only the latest version. The latest version just makes the behaviour the same when you use the gnome/nm toggle rather than the UI toggle. Previously when using the gnome/nm toggle it would not delete the connection but with the UI toggle it did, I also don't like this inconsistency.

is certainly not something I want to recommend to my users

Yes that is definitely not a good solution. Could you maybe explain what you need dispatcher scripts for? Maybe something we can support directly? I don't like too many configurable options in the client, but maybe a better way to allow for hooks would be nice.

Finally, I am not trying to dismiss this issue, but it's not an easy issue to tackle as I want to make sure the client does not unnecessarily take IP space. See https://docs.eduvpn.org/server/v3/client-implementation-notes.html#disconnecting.

tribut commented 2 weeks ago

Thank you for the detailed response.

The main problem I tried to solve via dispatch script was DNS priority. I sometimes have to use a second VPN which includes a split-DNS configuration for some domain. The IP traffic is routed through the other VPN just fine, but because eduVPN uses ipv4.dns-priority: -2147483648 names in that domain can never be resolved. I therefore change the setting to 0, which is the default value and ends up as 50 for VPN connections (see networkmanager.dev).

Here's my script. The lines marked with "NEW" were added to deal with the removal of the connection. The sleep adds a race condition which is bad and in general surprisingly disappearing windows are... also bad.

#!/bin/bash

set -eEuo pipefail
connection="$1"
action="$2"

info() {
    echo "[eduVPN-dns-fix] $*"
}

[ "$connection" = "eduVPN" ] && [ "$action" = "up" ] || exit 0

dns_priority="$(nmcli --fields=ipv4.dns-priority c show "$connection" | awk '{print $2}')"
if [ "$dns_priority" -ge 0 ]; then
    info "Connection already fixed ($connection dns_priority == $dns_priority), ignoring"
    exit 0
fi

sleep 30  # NEW: Wait for connection test
info "Fixing $connection connection..."
killall eduvpn-gui || true  # NEW: Prevent eduVPN from removing the connection when it goes down
nmcli con mod "$connection" ipv4.dns-priority 0
nmcli con down "$connection"
nmcli con up "$connection"

My second problem with the change is that during the day, I often switch my laptop from the docking station (wired connection, internal network, doesn't support UDP for some reason) to just wifi (no internal access, requires eduVPN) and back.

Toggling eduVPN using the gnome control panel is preferable here since its always available/visible on screen and it toggles instantly. Opening eduvpn-gui and switching the connection is more tedious and because it contacts the server can take several seconds when the PC just switched from wired to wifi (vice versa its even worse, because now UDP doesn't work so the client can't see the eduVPN server through the tunnel).

I would like to keep eduvpn-gui running for the notifications, though.

I understand that preventing DNS leaks is a good practice (though the only attack I see is some public hotspot announcing "google.com" as search domain to see if I'm using Google?). And obviously I don't have a good solution for the problem of when to release Wireguard IP assignments, but my understanding was that orgs pretty much have to prepare for a pool large enough to give an IP to every device of every user online during the login timeout window. That more or less requires Wireguard IPs to be RFC1918 addresses and no university I know is having a shortage of those. Maybe I don't understand the problem.

jwijenbergh commented 2 weeks ago

That script indeed looks annoying to get right.

What my idea currently is, is to allow some configuration to "merge" NM profiles.

E.g. you would create a config in

~/.config/eduvpn/nm-overrides.conf

with the following syntax:

ipv4.dns-priority: 0

and it would override the property. Maybe having a + syntax to add rather than override

+ipv4.routing-rules: someroutingrule

Regarding preventing DNS leaks, indeed this is why it's done. See #566

That more or less requires Wireguard IPs to be RFC1918 addresses and no university I know is having a shortage of those. Maybe I don't understand the problem.

Some universities/NRENs also hand out public IPs with WireGuard profiles, which makes this IP reservation pretty annoying. Hence why I try to do my best to cleanup profiles.

Thoughts? Would the merging of NM configuration solve this issue for you?

tribut commented 2 weeks ago

Thoughts? Would the merging of NM configuration solve this issue for you?

That would be much better than messing with the connection post-hoc, yes.

Regarding preventing DNS leaks, indeed this is why it's done. See #566

I don't understand whats happening in that issue. NetworkManager should, in its default configuration with dns-priority set to 0 (or 50), give the DefaultRoute flag to the VPN connection and assign it the ~. prefix. Indeed that is what I am observing here.

I was thinking about a targeted attack by the DHCP server handing out a university domain or something common as search domain, which would "win" against the default ~..

Ensuring that DNS never leaks is certainly the more secure default, so I can't really argue against that.

Some universities/NRENs also hand out public IPs with WireGuard profiles, which makes this IP reservation pretty annoying. Hence why I try to do my best to cleanup profiles.

This seems unsustainable, but there may be reasons – ok.

I don't have any data how many people use the OS controls to toggle and are annoyed that they can't re-activate eduVPN, not even anecdotally from my users. Maybe that's just a "me problem". I can live with closing the GUI after activating the connection. From my observation, that's what most users do anyway.

The most consistent way to handle this would probably to make the linux client a proper networkmanager plugin, so the eduVPN-connection always stays in the list of available VPNs and everything else (Wireguard/OpenVPN, Profiles, ...) is handled inside that connection.

jwijenbergh commented 5 hours ago

I don't understand whats happening in that issue. NetworkManager should, in its default configuration with dns-priority set to 0 (or 50), give the DefaultRoute flag to the VPN connection and assign it the ~. prefix. Indeed that is what I am observing here.

See the description of https://github.com/eduvpn/python-eduvpn-client/commit/602c4351b6c6eef0ac5d255cd536e910dc97f1be

Ensuring that DNS never leaks is certainly the more secure default, so I can't really argue against that.

Exactly, IMO the client should be secure by default.

The most consistent way to handle this would probably to make the linux client a proper networkmanager plugin, so the eduVPN-connection always stays in the list of available VPNs and everything else (Wireguard/OpenVPN, Profiles, ...) is handled inside that connection.

I get that point, but I am not sure how much better that would be. I think it would also be really tricky to have everything in a plugin. In the future I would also like to support non-networkmanager folks