GNOME Bugzilla – Bug 621698
VPN plugins don't obey server routing instructions.
Last modified: 2011-05-13 23:22:10 UTC
When using vpnc or openconnect, sometimes a server will provide a list of subnets which _are_ to be routed to the VPN ($CISCO_SPLIT_INC). And sometimes it will provide a list of subnets which are _not_ to be routed to the VPN ($CISCO_SPLIT_EXC). In fact, nobody who uses excludes seems to use anything more than a single basic one excluding 0.0.0.0/32 (a single invalid IP address, leaving everything else routed to the VPN). For this reason, the standard vpnc-script only actually looks at the $CISCO_SPLIT_INC settings -- if there are any of those, it'll route _only_ those networks to the VPN. If there are none, it'll set the default route to the VPN. Some VPN servers (berkeley.edu) have a choice between split-mode VPN and full tunnel when you log in, and their VPN server will then provide the routes according to the user's choice. However, NetworkManager doesn't get this right. It doesn't obey the VPN server's instruction about whether to set the default route to the VPN or not -- it _always_ overrides that decision with a boolean from its own configuration. This needs to be fixed -- we need to be able to just set up the routes that the VPN server asked for.
I caught somebody on IRC today trying to do an evil hack to send a dbus message to toggle the never-default option according to the instructions from the VPN server, rather than fixing this bug properly.
Created attachment 163734 [details] [review] Allow vpn to pass 'no default route' setting back in SetIp4Config This ought to suffice -- just let the VPN configuration callback indicate that it doesn't want the default route.
Created attachment 163735 [details] [review] nm-openconnect patch This shows how it would be used in the VPN plugin, to obtain the standard behaviour of the normal vpnc-script. The "never-default" option then lives up to its name, and ensures that the VPN _never_ takes the default route. But the VPN isn't _forced_ to take the default route when it doesn't ask for it.
This approach is acceptable, have Mercury attach an updated patch when done testing and I'll push to the repos.
Created attachment 163973 [details] [review] Allow VPN plugin to send 'no default route' back to NM. (Tested) This is a tested version of David Woodhouse's patch, extended with some additional logging and with fixes in NetworkManagerPolicy to check both the VPN's ip4_config and the settings. The check of the settings could likely be skipped, as the settings are merged into the ip4_config, however for the sake of paranoia I am leaving the old check. Zephaniah E. Loss-Cutler-Hull. (AKA Mercury)
Another example of a VPN that lets you choose at login time whether you want a full tunnel or split tunnel: http://www.nacs.uci.edu/security/vpn/vpn-lin.html
Some misc changes and cleanups done; int -> bool, formatting, etc. Main bits: d5468c85278a0f981a442f1a31791e413f839f76 (master) 84aa30472e744876c93fac5f9388c176e226c2bc (0.8.x) and the openconnect bit is: be42aae7a7cd0c48ef0fa39d69df3e92e8cc73df (master) 1f97cfe725b2bf1675aee69e72d243f330a0a479 (0.8.x)
Thanks. N-M-vpnc wants the same patch as N-M-openconnect got. Other VPN plugins may need something similar.
PPTP can't send routes at all, and I'm not sure that openvpn has the ability to exclude them either. If vpnc has the same capability as openconnect then we can/should do it there.
vpnc's interface to its vpnc-script is fairly much identical to openconnect's. To the extent that when I add something to openconnect, I look at adding to vpnc too. For example, I'm currently working on adding a textual 'disconnect reason' when we invoke the script at vpn shutdown time, and will soon be filing a bug asking NetworkManager to report that sanely.
Yay! Thanks :) I keep meaning to go clean that up but never get around to it. Here was my original plan... we can add more reasons to NetworkManagerVPN.h in the NMVPNPluginFailure enum, which we can then use in nm-applet to display translated strings to the user about what actually went wrong. We just never diagnosed what other failure reasons were and added those to the enum. The more complex way here is still to use the enum (so that we can translate the error properly) but add a "FailureEx" (perhaps a bit to Microsoft-y) or "FailureWithContext" or soemthing like that that takes one of the failure enums (uint32) and more context (char*) that can *also* be displayed by the applet or something. That gets the new stuff back to NM. We can then work out how to push that up to the applet; I can think of at least two or three ways.
tits, this still isn't fixed for vpnc; only openconnect. The openconnect commits mentioned in comment 7 need to be applied to vpnc (which has basically the same code in src/nm-FOO-service-FOO-helper.c).
To ssh://dwmw2@git.gnome.org/git/network-manager-vpnc 073c050..780ebe1 NM_0_8 -> NM_0_8 9383bc1..8d382a5 master -> master