GNOME Bugzilla – Bug 748442
Only allow traffic through VPN
Last modified: 2020-11-12 15:45:26 UTC
Everytime I try to see if I can switch to Linux from Windows, I find too many tasks too difficult to do. On this particular occasion, it's using a VPN. On Windows, SW clients handle the connection details, not a huge deal. But they also have built in fail-safes for when a connection drops. Very few VPNs have Linux clients (I was able to find 3), and only one has this feature built in and working. Downside, they're expensive and their servers are painfully slow. Could there exist a way for NetworkManager to only allow traffic through a VPN? Then if that connection drops, the machine would still be "protected".
(In reply to sticky-mike from comment #0) > Everytime I try to see if I can switch to Linux from Windows, I find too > many tasks too difficult to do. On this particular occasion, it's using a > VPN. On Windows, SW clients handle the connection details, not a huge deal. > But they also have built in fail-safes for when a connection drops. Very few > VPNs have Linux clients (I was able to find 3), and only one has this > feature built in and working. Downside, they're expensive and their servers > are painfully slow. > > Could there exist a way for NetworkManager to only allow traffic through a > VPN? Then if that connection drops, the machine would still be "protected". Seems like, this only makes sense for the default route. At least it would be difficult to understand the meaning of such an option for non-default-routes. Guess this feature could apply to all types of connections -- though it makes more sense for VPN. A connection could have an option "ipv4.permanent-exclusive-default-route=BOOL". When NM activating such a (VPN) connection, it removes and blacklists the default-routes on all other active connections (permanently). If another connection activates while the VPN is still activated, their default route is ignored too (permanently). If the VPN disconnects, all connections that are activated at that point in time, are permanently blacklisted from obtaining the default route. Only connections that activate later, may again receive the default route. NMActiveConnection should have a flag to indicate whether default routes are permanently disabled. Not too hard to implement and a nice feature. But IMO not high priority.
Who am I to question the lead developer's prioritization on his project? I'm glad to hear you understood what I was referencing. Maybe adding this into NM will be easier as you begin tooling in support for multiple VPNs, a stated goal since early as 2014. On another note, NM was actually the reason I chose the Ubunutu Gnome distribution over any of the others. The polish on the application and its taskbar applet exceed all others. From the built-in VPN support, to listing the Network card name rather than eth0, eth1, to the profile and settings UI. It's miles ahead of other network managers. Also, would you mind if I forwarded your bug notes to a VPN provider who I'm trying to work with? I would of course credit you.
(In reply to sticky-mike from comment #2) > Who am I to question the lead developer's prioritization on his project? I'm not lead developer, this was just my opinion (should have made that clearer). Anybody who feels this is more important, is welcome to contribute this feature :) > Also, would you mind if I forwarded your bug notes to a VPN provider who I'm > trying to work with? Of course, it's public anyway.
(In reply to sticky-mike from comment #0) > Very few VPNs have Linux clients (I was able to find 3), Is there a specific VPN you're looking for which *doesn't* have Linux support already? From my standard Linux distribution I can already connect to more than the 3 that you've counted. I have fully-integrated support for using NetworkManager with OpenVPN, PPTP, L2TP, Cisco AnyConnect, Juniper Network Connect, Fortigate SSL VPN, as well as a bunch of IPSec VPNs. There are perhaps even more with badly-integrated third-party Linux clients provided by the vendor, but I'd recommend that you avoid those like the plague and stick with what's properly supportable under Linux.
(In reply to Thomas Haller from comment #1) > Seems like, this only makes sense for the default route. At least it would > be difficult to understand the meaning of such an option for > non-default-routes. Not necessarily. See also bug 767288 where we want to block all local traffic, not *just* set the default route to point to the VPN. Perhaps we actually want the physical network to *only* permit access to the VPN server, ever... although in a world where DNS and other load-balancing exists and I could be connecting to any one of *dozens* of IP addresses which provide my corporate VPN and which could change daily, it's difficult to know how we'd achieve that except by running the auth-dialog and the VPN client itself in a separate network namespace which *does* have routing to the outside world, while nothing else does?
Linux and GNM both handle the various VPN protocols rather well. This "bug", pertains to how GNM handles dropped connects. Default behavior of GNM when a VPN drops connection - returns to sending packets back through the LAN. As an end-user; a toggle to "only allow traffic through VPN" even in the event of a severed connection would be much appreciated. Configuring the iptables and handling conflicts with GNM is something most users would rather skip if a toggle option for handling dropped VPN connections was present in GUI.
This post was informative: http://joelslowik.blogspot.com/2013/05/setup-iptables-for-vpn-and-local.html #Allow loopback device (internal communication) iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT #Allow all local traffic. iptables -A INPUT -s 192.168.1.0/16 -j ACCEPT iptables -A OUTPUT -d 192.168.1.0/16 -j ACCEPT #Allow VPN establishment iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT iptables -A INPUT -p udp --sport 1194 -j ACCEPT #Accept all TUN connections (tun = VPN tunnel) iptables -A OUTPUT -o tun+ -j ACCEPT iptables -A INPUT -i tun+ -j ACCEPT #Set default policies to drop all communication unless specifically allowed iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP How to incorporate those rules into a toggle is beyond my knowledge...
Probably related: I would love to have a distinction between "logically up" and "actually up" for the VPN, with it re-establishing a lost connection until I actually *ask* it to drop the VPN. It would start by re-using existing credentials (in AnyConnect and Juniper NC, the auth cookie lasts longer than a single connections), and if the existing creds really *do* expire then it would bring up the auth-dialog again to reconnect automatically. Tie that with "do not allow anything but the VPN client and its authentication dialog to talk to the real network", and we have something close to what you're asking for, I suspect? Although you still might need to connect to a *different* VPN server if the reason for your disconnection was that the one you're using went down. So it's still slightly non-trivial. You can't just allow traffic to *only* the one server you first used.
(In reply to Mike R from comment #7) > #Allow VPN establishment > iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT > iptables -A INPUT -p udp --sport 1194 -j ACCEPT That's OK for OpenVPN. But switch to any of the fully-featured proper SSL VPNs which use TCP for establishment and as a fallback for the UDP-not-working case, and you'll find that you need to allow output TCP port 443.... which isn't much of a restriction at all :) We could perhaps have the auth-dialog and VPN clients themselves issue a request to NetworkManager for any IP address they want to access, before doing so? That might be easier than running them in a separate network namespace?
I am the last person to think anything machine language related is anything but non-trivial. I'm aware it requires a tremendous amount of abstract thinking and creativity. "...with it re-establishing a lost connection until I actually *ask* it to drop the VPN..." Does that accurately addresses issue? US and UK are beginning to further enforce torrenting. If a VPN connection drops and those packets are then sent out through the regular LAN, it could mean huge problems. If what you're proposing eliminates those packets leaking back out through the LAN, then yes. Is more required to accomplish that?
Setting the VPN to be persistent handles some of this. Once the connection is up, it does what you want if the underlying connection drops: the VPN remains logically connected and your routes to the VPN remain in place. Obviously the packets don't get through until the underlying VPN transport reconnects (er, which is actually never due to bug 794190). However, it doesn't cover the case when the VPN isn't up yet. And it doesn't cover the case when the session expires and the VPN does terminate.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).
(In reply to Thomas Haller from comment #1) > Seems like, this only makes sense for the default route. At least it would > be difficult to understand the meaning of such an option for > non-default-routes. > > > Guess this feature could apply to all types of connections -- though it > makes more sense for VPN. A connection could have an option > "ipv4.permanent-exclusive-default-route=BOOL". > > > When NM activating such a (VPN) connection, it removes and blacklists the > default-routes on all other active connections (permanently). > > If another connection activates while the VPN is still activated, their > default route is ignored too (permanently). > > If the VPN disconnects, all connections that are activated at that point in > time, are permanently blacklisted from obtaining the default route. Only > connections that activate later, may again receive the default route. > > NMActiveConnection should have a flag to indicate whether default routes are > permanently disabled. > > > > Not too hard to implement and a nice feature. But IMO not high priority. Hm, there's no need to permanently block other network connections, but there is a need to fail safe: that's a longstanding problem with NetworkManager's support for VPNs. IMO every VPN that has the default route should be fail-safe, such that if it disconnects, all other network connections disconnect as well at the same time. That way, the user will notice that the VPN is lost and actively decide whether to continue without the VPN or try to reconnect to it. Currently, that doesn't happen, and requests could be sent outside the VPN inappropriately. But I don't think it requires any new option, since this behavior should be desired for every "full tunnel" VPN. This would just force the user to decide what to do when the connection drops. Nothing would need to be permanent. It's a shame this issue wasn't migrated to GitLab.
> It's a shame this issue wasn't migrated to GitLab. I followed https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/376 ; anyone is very welcome to create this issue in Freedesktop.org GitLab.