On Fri, 2009-07-24 at 13:41 +0200, Henrik Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I guess i emailed before reading up in the bugzilla... > > http://bugzilla.gnome.org/show_bug.cgi?id=349151
Yeah, this has been brought up a lot before, and it's also on the list of stuff that should be done sooner rather than later. There are a few complications here. First, NM's architecture is not built to suppress announcement of "I'm connected to the internet" until the VPN is up; but often that's the wrong approach, because many VPNs only secure a *specific* IP route, they dont' secure the entire machine. So in reality, applications that care about security (say you don't want your IRC login details broadcast over a coffee shop wifi) need to be smart enough to know when the resource they need (ie, the server) is secure. As a concrete example, our work VPN at Red Hat does not route all internet traffic, thus only redhat stuff goes over the VPN. It's not possible to route all traffic over the VPN, thus it's up to the applications to ensure they use secure methods of connecting to their resources/servers. In this case, suppressing the "I'm connected to the internet" message that NM broadcasts until the VPN is also up would be useless. Next, we need to implement the config bits to tie the VPN connection and the "base" connection together, so that the VPN gets activated when the base connection does. I'm not entirely sure whether the VPN should contain the references to the base connection, or whether the base connections should contain the reference to the VPN. Next need the UI bits in the connection editor dialogs to let you pick what gets tied to what. A completely separate issue is making sure the VPN gets re-tried on failure. A complication with this is methods that have one-time-passwords or require further user input, because the user wont' necessarily be around to re-enter their password. We probably have to take the entire connection down (including the "base" wired/wifi/3g connection) if the VPN connection is tied to that base connection, because you're expecting the VPN to be up whenever that base connection is up, and thus we can't leave things connected when the VPN isn't working. Dan > > +1 for the "dial this connection first" as well. > > > > Rick Jones wrote: > | --On Thursday, July 23, 2009 15:04:13 -0400 Dan Williams > <[email protected]> wrote: > | ¦ > | ¦ Yeah, reconnect of a failed connection (as opposed to a > | ¦ user-disconnected one) is definitely on the list. I was planning on > | ¦ doing some of the work for that in the 'inhibit' branch in git, so you > | ¦ can track that there. It won't be VPN-specific at first, but the > | ¦ changes there will help out the VPN stuff too. > | > | A useful feature for VPN config which is kinda related, would be the > ability to define a preferred real connection to carry the VPN. Then you > would be able to just request VPN connection in NM and it would first > establish the underlying connection. > | > | Windows has a feature like this in the form of "dial this connection > first" in the VPN setup dialog. > | > | I'm just thinking that having such a mechanism might also help with > managing the VPN auto-reconnect case. > | > | Just a thought... > | > | ------------------------- > | > | _______________________________________________ > | NetworkManager-list mailing list > | [email protected] > | http://mail.gnome.org/mailman/listinfo/networkmanager-list > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkppneYACgkQXtSockw5x6yLtwCdHN3g89+0q1wmJvI3L/TvNBV6 > PXgAn1bknUV+KJeBaRz1XKOU/c9RUw0r > =9IG7 > -----END PGP SIGNATURE----- > _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
