Re: vpn pptp reconnect feature

[Dan Williams <dcbw redhat com>]

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 
> <dcbw redhat com> 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
> | NetworkManager-list gnome org
> | 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-----
>